Right now I am in between projects and have been trying to think of a game to make. I got an idea for a game that has two robots fighting in an arena. There weapons would be like hammers and mechanical saws and stuff. If anybody has seen battlebots it would be just like that. When brainstorming about how to do it, I figured out that collision detection would be a big problem. If one robot has a hammer that swings at 10 mph and hits the other one, how would I know how much force it hit it with. And detecting the collision would be very hard also. Does anybody have any ideas on how to go about this problem? *** Triality ***

Well god damn! That''s the kind of game I''m working on right now! It''s just like what you said,2 big anime style robnots fighting in an arena.My game revolves more around robot gladiators in the future.

Anyway,back to your question.The way I''m doing it is this way.

(1) I check if there is a physical collision between the 2 bots.
(2) If there is a collision (basic bounding box type collision) then I check to see which frame of which animation is running.Let me clarify this a bit.say that you and your opponent are colliding and you press the space bar to initiate an attack action.I check to make sure that your "swing hammer" animation is running and then I check to see if frame #24 (for example) of that particular animation has been reached.This means that you struck your opponent with your hammer and from there I take out health from the opponent (or whatever action you wish to happen) It''s pretty simple really. Hope that hjelps

You''re right to be primarily concerned about collision detection as it can make or break a fighting game.

Normally, there is no need to work on a polygon to polygon basis as the animations move so fast. As such, deal with some sort of heirarchy of bounding volumes attached to the skeleton of each character and the weapon.

This means that you have a character thats made up of bounding spheres or oriented bounding boxes. You can have as many as you want attached to each character and each bone, arrange them heirarchically if you wish etc, just make sure they are a close fit to the skin geometry. You''ll get a man made out of bubbles or boxes that represent the bulk of body mass and limbs. Of course, you can''t see them you still draw the soft skinned model instead. Draw the volumes just for debugging.

Think of it in terms of spheres where one sphere covers the entire area the character moves within. A simple trivial rejection can take place here - if the two parents aren''t colliding then go no further. If they are then one character might be hitting another and you can proceed to determine if any leaf spheres are colliding.

It''s best if a fighting game runs from a well supported modelling and data pipeline - remember, whatever character is modelled must also be represented by the spheres.

The next step is to determine which spheres actually cause or recieve damage. So your character with the hammer may have a sphere (or a cluster of them) around the hammer head. If those spheres collide with the other character then you can calculate damage.

You might want to make it so each sphere holds a variable for armor and one for damage. In this way you could compare the damage variable of the hammer head against the armor of the body. Of course, the body need not have actual armor on it, this would be just a way of making the damage different depending on what part of the body is hit. You could also make it so the shaft of the hammer could still cause damage but maybe less than the head.

As for measuring the damage the hammer causes depending on the power of the swing, or how far into the swing anim the character is. It shouldn''t be too hard to allow each sphere to have a different power level depending on the frame of animation. For instance when stood still or just beginning to swing the hammer the spheres around the hammer head shouldn''t be too potent even if they do collide with a vital part of the opponents body. Whereas later on during the animation as the hammer head is clearly moving fast it should obviously wreak havoc.

Failing that, when a sphere collides you could determine the distance it has moved since the last frame and that would give you a reasonable idea of the speed the sphere (the hammer head) was moving.

I mentioned about getting your modelling and data pipeline set up. Really the collision detection and animation is such a strong and closely tied part of a fighting game you might want to aim towards building the animation, sphere placement and damage variables into whatever modelling package you use.

Also, plan for many frames of animation and much blending between anims. In that way when you hit the hammer on the opponents head you can blend to a new anim or do something different other than continue to swing the hammer and have it pass through the body or do something else ugly.

Thanks for the suggestions, I got some really good ideas. I think I''ll use ellipses instead of spheres. And that will be easy to setup for the robot since I''m making the robot modeler myself so that the player can make his own.

*** Triality ***