Heya guys, I'm starting to design my new 3D Fighting Game, which will be unique in that it will be a fast-paced sword fighting game and not the regular Mortal Kombat clone. Now: My needs are as follows. I need 8 basic fighting animations: Attack left, attack right, attack down, attack bottom-left, attack bottom-right, and block up, block up-left, and block up-right. The game will feature a basic reflex-based sword fighting scheme which goes as follows: If I attack to the left, my enemy must block to the right, in order to successfully block. If I attack and my enemy doesnt press anything (doesnt block), my attack will connect, and I'll win. Here's what I want, tell me how best to achieve it: I have a mesh of a human being. My brother imports it to Maya and creates a rig / skeleton for it, which animates it. He creates one animation, a kind of swipe-sword-to-left attack animation. Then he exports the mesh and rig data (containing the animation also) to a certin format. I import the mesh, rig info, and animation to the game. Now in-game the rig should control the mesh, just like in Maya. So when I press left, it activates the rig's attack left animation, in return controlling the mesh. I can basically import any mesh to fit onto my rig and animation info. How do I fit the rig onto the mesh in-game? If I also implement moving, how do I keep the mesh and rig together? Alright, that's one. Next up: I'll tell my bro to make the rig be made up of a bunch of 3d boxes, IE bounding boxes. So the rig will also act as the collision detection bounding boxes data. The sword will be represented (as opposed to what I originally told you) by a long thin box. So sword vs. sword (to know when to stop the animation, play a sound, for example) and sword vs. body (to know when someone was hurt) will be made up of the same technique - 3d box vs 3d box. The way I see it, a 3d box is made up of 3d lines. I can check each line against the other box's lines for collision, just like in 2d algebra if I represent two 2d lines as y = ax + b it's very simple to check if they have collided, simply by comparing their equations and retrieving a joint x, y point. If there is no joint point, they have not collided. What do you guys think? Game design aside, I'm talking about what I wrote in this post. How do I "rig" a mesh in-game, assuming I have both mesh and rig info? Is there a tutorial for this? I mean how do I make the rig control a mesh? Does the collision detection solution sound reasonable, or is there a simpler method to achieve a 3d box vs 3d box detection? I need it to be exact and "real", no fake (if attack left and block left, then block successful) kind of crap. Because that wont help me with knowing WHEN to stop the animations, when the opponents connected so I can play a sound, etc etc. Thank you for taking the time to read my questions. What do you think will be the best solution to my specific needs? I would appreciate any help you can give, and if more information is needed please do tell. [Edited by - Bagheera on June 17, 2006 7:37:38 AM]

I've only read half your post, and just a quick reply before I go out.

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.

bye.

wow, you've asked a ton more than 2 questions, and there's a bunch of other stuff that needs even more attention. ummm..in no particular order...

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 ;)

Good Luck!