Melee combat ala Zelda
by James Petruzzi · in Torque Game Builder · 03/09/2007 (7:25 am) · 8 replies
Hey guys,
I'm working on a game kinda similar to zelda: link to the past. I'm trying to come up with a decent real-time combat system to use. I was thinking of creating the sword and mounting it when the attack button is pushed, then rotating the sword via code for the swipe. Is there a better way to do this?
Theres also the obvious of just using different character animations with the sword already in them but it doesnt seem like it would be very accurate. Can you change collision polygons on the fly to follow the sword animation?
Thanks for the help :)
I'm working on a game kinda similar to zelda: link to the past. I'm trying to come up with a decent real-time combat system to use. I was thinking of creating the sword and mounting it when the attack button is pushed, then rotating the sword via code for the swipe. Is there a better way to do this?
Theres also the obvious of just using different character animations with the sword already in them but it doesnt seem like it would be very accurate. Can you change collision polygons on the fly to follow the sword animation?
Thanks for the help :)
#2
Mostly true... you can get an onFrameChange callback for animations, so if you wanted to script the collision poly change you could (would be a pain working up the collision poly data to change). Wouldn't be too bad to do it once (you can edit the collision poly in the Level Builder and then echo back the poly data in the console for each frame) though changing it would require re-doing most of that.
As David said the rotating sword sprite would be a possibility, in fact not all that different than what the sword looked like in the zelda games, though as David said it would require a lot of trial and error. Of course once you get it, it wouldn't be too hard to change it.
David's last suggestion is a good one... another idea might be to mount some basic Scene Objects to your player representing the sword's position in each of the frames, then in the onFrameChange callback for the attack just do an enable + castCollision on the proper "collision box". You could then alter it in the level builder to tweak it fairly easily.
03/13/2007 (2:24 pm)
Quote:Collision poly's can not be altered on a per-frame basis for an Animation, I know, that sucks ... but at current, thats what we have to work with ...
Mostly true... you can get an onFrameChange callback for animations, so if you wanted to script the collision poly change you could (would be a pain working up the collision poly data to change). Wouldn't be too bad to do it once (you can edit the collision poly in the Level Builder and then echo back the poly data in the console for each frame) though changing it would require re-doing most of that.
As David said the rotating sword sprite would be a possibility, in fact not all that different than what the sword looked like in the zelda games, though as David said it would require a lot of trial and error. Of course once you get it, it wouldn't be too hard to change it.
David's last suggestion is a good one... another idea might be to mount some basic Scene Objects to your player representing the sword's position in each of the frames, then in the onFrameChange callback for the attack just do an enable + castCollision on the proper "collision box". You could then alter it in the level builder to tweak it fairly easily.
#3
Where can I learn more about this "vector math" you speak of? I wasn't aware you could do such things. Of course, I'm a self-taught programmer so there's a lot i don't know haha. Sounds like I'll need a calculus book ;)
Thanks for all your help guys! :)
03/13/2007 (8:45 pm)
So I ended up trying my original idea, rotating the sword via code, and it works pretty well. I don't have a character animation for it yet, so who knows what it'll look like when i get some actual artwork in there.Where can I learn more about this "vector math" you speak of? I wasn't aware you could do such things. Of course, I'm a self-taught programmer so there's a lot i don't know haha. Sounds like I'll need a calculus book ;)
Thanks for all your help guys! :)
#4
All you need is a stationary box in the direction of the swing for the appropriate frame(s) of the animation. Unless the sword swipe is extremely slow, nobody will ever know the difference and your gameplay will be much more consistant.
03/13/2007 (9:08 pm)
If you're doing a Zelda-style top-down game why would you possibly need such precise collision detection? Not to seem negative, but I think you guys are overcomplicating things quite a bit. All you need is a stationary box in the direction of the swing for the appropriate frame(s) of the animation. Unless the sword swipe is extremely slow, nobody will ever know the difference and your gameplay will be much more consistant.
#5
03/19/2007 (6:37 pm)
Thomas, that's a really good idea. I, like James, have been fighting on the best way to do the Zelda-style combat...it never even occurred to me to do it that way. You could have a bounding box in the general direction and area the sword would swing, and just test the collision during the swing itself. I think I'm going to give that a try. James, let me know how yours turns out too...this is quite interesting...
#6
03/19/2007 (11:05 pm)
Another way would be to have the sprite as its own object, with its own collision polygon. I have played a Zelda clone that solves it that way... this would give you more precise collision detection aswell if you really wanted it. Secret of Mana does it this way too by the way.
#7
03/28/2007 (1:23 pm)
I don't think I've ever used Caculus in programming, but I use a lot of trig. Vectors are more of a Physics thing and if you end up doing much of your own Physics, they're hard to live without. Basiclly you'll want to know vector math if you need to take polar movement to the next level.
#8
04/19/2007 (12:37 am)
I would mount a seperate object to your main character and when the player's state is set to attack, turn on this objects collision and set a collision callback. And yes, as Matthew Langley stated, you can easily create frame-by-frame animated collision polygons via script. I have used both in two projects with good success.
Associate David Higgins
DPHCoders.com
As for rotating the sword sprite to simulate an animation ... that might work, but be prepared to go through alot of trial and error testing, and A LOT of code ...
As for the Animation ... you could, in your onCollision callback, check the current frame of the sword animation, and do some vector math to see if the collision is 'true' or not -- which might be a cleaner solution, allowing for less of a 'goof' in the animation (opens the door for some goofs in the collision, but its better to miss or hit too much then it is to lose your sword in a flurry of rotation goofs)