I know this is another cheesy question, but I have to ask it. What is a good 3D animation format for a fighting type of game like Mortal Kombat? First, I chose MD3 because I figured they are pretty easy to load into Direct3D. Then, I changed my mine because of the whole physics thing. And MD3 is key framed and hence, not a whole lot of physics can be applied to them in realistic situations. For example, getting punched in the gut of kicked in the head. I know MD3s use several little models for parts of the complete model, but still. Second, I thought skinned meshes would work best. Because I can linear interpolate between the frames easier (I guess) and the physics can be applied easier via applies to bone. Also, the animation would run more smoothly and be able to adapt to the changes in the environment. For example, interpolate between standing to sitting & blocking. So I’m trying to figure out what would be the best format in my situation. Later, I will probably derive my own that conforms nicely to the engine. But I need something to get me started so that I have a base to expand on. What would you suggest? I get all kinds of things from Google, but I want someone’s personally advice with experience in the subject before I go off on my own.

Thanks for the information, but what I’m really looking for is a basic framework for that type of animation. The physics framework I would have to implement mostly by my self, the animation framework I may have to as well. Unless I can find a good framework that supports bone/joint (a.k.a. skinned meshes) type of animation.

I understand that all (or mostly) 3D formats are key framed. But, some make use of joints and bones that are usually used to predict at runtime how a specific part of a model should animate. In much the same way as vertex blending, except it’s not really that hardware dependant. I’m sure you know what I’m talking about.

You have clarified the topic of how each system (controller) should take over at a desired point in time based of the client’s (player) state. An interactive control, as I call it, is used to accept user input and guide the model in it’s animation from those triggers, i.e. client presses a key, etc.. A physics controller that implements simple rag doll type physics takes over when the client dies. It’s more or less a trade off in owner ship of the client’s state.

To make this more realistic, I would like this trade off to happen frequently; not just in dead or dieing state. For example, the physics controller should take over when a player is hit for a specific part of time. The problem I’m seeing here is that if the client is in a specific state, such as block-attack, the physics controller would alter the state so that the client’s state resembles impact of the attack. The two don’t mix too well. One obvious solution is to remember the client’s previous state, that way the logic would still be the same except the animation would only be different.

I’ve also considered using hierarchical FMS for this now. The parent controller would be the interactive controller that accepts user input. The physics controller would be more like a sub routine (in concept) that is called on special occasions. It would only effect the animation, not the logic. The parent controller would always have ownership of the client’s state, calling the physics controller when needed, but detaching from it when needed also. For example, (from the above example) the client’s state would remain in "show impact" mode until the user interacts. Then the physics control would be disengaged.

This pretty much leaves the client player as an object that can be affected in many different ways using a basic interface. The input (parent) controller and physics are the two forces directly affecting it. Sound easy enough right?

What I’m looking for through, is a 3D model format that supports the bones or joints.

These are the current client states I have thus far. Hurt and dead states are physics affected states. All others are input affected. I will add additional states that handle action recording for combos and other special effects. But for the most part, those are it.



The main controller uses DirectInput8 to retrieve the input from what ever*. The physics controller is allowed to modify the client when needed. It's job is to try and interpolate between physical damage states and match them up as best as it can with the parent's state. It's pretty much filling in the holes and attempting to make things look more realistic.

I took an idea from a compiler book and used a transition diagram for the FSM. The main states (starting points) are those the client can invoke, the several children states are those the controller invokes then needed.

Cool, thanks for the help dude!