collision / who goes first
Author
My project is a multiple player fighting game with other objects / interactive parts of the level(powerups/items/entities). How should I go about deciding who to test for collisions first?
I was thinking check to see if any of the items / entities hit/damage any players first. Second check to see if any player to player collisions / hits. Also should I randomize/flip between which player I test first? I want to make it fair so player1 does not always have the same advantage over player 2 (if player 1 and player 2 attack at same time then player 1 always wins) while I doubt this will happen to often I should consider it. Is the best way just to alternate who I test first? and should I test the entities/items see if they hit/damage the players first, or update the players first then the entities?
More info. Currently I am thinking for the most part entities could do damage to players and/or be picked up by players but not actaully damage and will be more time based (in terms of life).
-THACO
If its a single player game you're worried about. Tilt the collision in favor of the player. Its better to have near misses that were "close calls" than hits that "didn't even touch me"
If tis multiplay, however, seperate the collision and the action that follows. Check to see if player 1 hits player 2. Then check to see if player 2 hits player 1. If they both hit each other, have them both take damage. Just structure your code so its possible for multiple collisions to happen in the same frame, and you should be all set.
If tis multiplay, however, seperate the collision and the action that follows. Check to see if player 1 hits player 2. Then check to see if player 2 hits player 1. If they both hit each other, have them both take damage. Just structure your code so its possible for multiple collisions to happen in the same frame, and you should be all set.
The object in question moves, checks for collision, if collision -move back or explode/bounce whatever. You do the same logic on every object in question. It doesn't matter if the object is a player, a missile, a ball or whatever the same logic should apply to all.
Move();
if(Collision())
CollisionResponse(); // move back, explode, bounce etc.
Move();
if(Collision())
CollisionResponse(); // move back, explode, bounce etc.
Basically, unless your granularity is too high, it doesn't really matter. Things will more-or-less hit each other the way they should :)
One idea for you, though. If any weapons are near a player (on the computer where it matters; server for multiplayer, I assume), do the check with double/triple/quadruple accuracy.
One idea for you, though. If any weapons are near a player (on the computer where it matters; server for multiplayer, I assume), do the check with double/triple/quadruple accuracy.
Just because the detection process is serial doesn't mean the results have to be serial.
Detect all of the collisions before responding to them. Instead of reacting to each collision as it is detected, just record the fact that it happened. Later, sort through the set of collisions and determine how to respond to them. If two players hit each other on the same frame then have them both do their hit reactions.
As a side effect, I bet your collision detection code will become much more organized and cache-friendly because it isn't bouncing in and out of the hit reaction code.
Detect all of the collisions before responding to them. Instead of reacting to each collision as it is detected, just record the fact that it happened. Later, sort through the set of collisions and determine how to respond to them. If two players hit each other on the same frame then have them both do their hit reactions.
As a side effect, I bet your collision detection code will become much more organized and cache-friendly because it isn't bouncing in and out of the hit reaction code.
To elaborate -- first, move everything. Don't collide in this step. Next, detect all of the collision events and generate collision pairs. Third, make the collision pairs behave as appropriate.
Quote:Original post by Promit
To elaborate -- first, move everything. Don't collide in this step. Next, detect all of the collision events and generate collision pairs. Third, make the collision pairs behave as appropriate.
Should you wait until next frame to test whether objects are still inside of each other?
Quote:Original post by Daniel MillerQuote:Original post by Promit
To elaborate -- first, move everything. Don't collide in this step. Next, detect all of the collision events and generate collision pairs. Third, make the collision pairs behave as appropriate.
Should you wait until next frame to test whether objects are still inside of each other?
He described one physics update cycle. What frames are you talking about?
Original post by Anonymous PosterQuote:Original post by Daniel MillerQuote:Original post by Promit
To elaborate -- first, move everything. Don't collide in this step. Next, detect all of the collision events and generate collision pairs. Third, make the collision pairs behave as appropriate.
Should you wait until next frame to test whether objects are still inside of each other?
No, it is done in every frame. So to say it all at once, in each frame, first move stuff, detect collisions, do collision response, render, and go to next frame (repeat).
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
