Jump to content
  • Advertisement
Sign in to follow this  
THACO

collision / who goes first

This topic is 4814 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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

Share this post


Link to post
Share on other sites
Advertisement
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.

Share this post


Link to post
Share on other sites
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.



Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Quote:
Original post by Daniel Miller
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?



He described one physics update cycle. What frames are you talking about?

Share this post


Link to post
Share on other sites
Original post by Anonymous Poster
Quote:
Original post by Daniel Miller
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?


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

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!