Skeleton Animation & Collision Detection in 3D Fighting Game,
Members - Reputation: 124
Posted 16 June 2006 - 12:54 AM
Posted 16 June 2006 - 01:29 AM
You should connect the input to the skeletal animations, the mesh really shouldn't know anything about the game itself. The skeleton(s) should be generic for all(most) models, that is to say the same rig is used for each mesh. This is how most fighting games set it up, allowing you to mix an match 'moves' for all the characters.
Also, you might wanna connect the input to the 'combo' handling code that'll then pick the right animations.
Members - Reputation: 115
Posted 16 June 2006 - 10:57 PM
Having 2 block buttons is sure going to piss off players, especially if it's going to be fast paced and reflex based. I can assure you, although it may sound good, it just won't work (gameplay wise).
As for the collision, scrap the whole sword against sword collision. As well as it will probably be a nightmare to implement, being so exact will frustrate players and in most cases the collision will appear broken. One example, what if the attacker is slightly in the air (jumping), the attackers' sword may hit the defenders head instead, bypassing the sword vs sword collision ie, unblockable attacks.
An easier and most common way, is to test 'Normal Attack'(standing) against 'Normal Block'; 'Low Attack'(Crouching) against 'Low Block'; 'High Attack'(Jumping) against 'Normal Block'; (those are just examples of successfull blocks)
Each player should have 3 collision boxes (High, Mid, Low) depending on how you want it, and test attacks with another bounding box around the weapon.
-*Polygon vs polygon precision will completely dammage gameplay, all I can say is use bounding boxes*-
For the rest, I guess the AP said it better, connect the controls to a skeleton, which will then animate the mesh. As most human skeletal animations only modify bone rotations, scale and size it (programically) to fit each model (if need be). If using maya, it will be easier to write a script to export your skeleton seperate from meshes.
It will be best to keep each part seperate from each other, only the engine should know what each thing does. ie, the mesh shouldn't know anything about collision detection; the collision detection shouldn't know anything about the animation system; etc etc, let the engine handle it all seperatly.
blah, I guess that's it, just ask if I missed something, or you need more info. Sorry if any of it sounded harsh or a bit matter of a fact, just there's quite a lot going on here, and if it's not completely thought out and planned, it will all fall apart :D.
Although you've played fighing games before, I suggest replaying them all again, and pay more attention to what going on under the hood and not just the pretty models and effects ;)