Jump to content
  • Advertisement
Sign in to follow this  
justcolorado

At what point in the loop should I put collision detection?

This topic is 2552 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

I need to check for the following types of collisions.
  1. Player collides with impassible wall
  2. Player tries to eat food, (is she at collision with food?)
  3. Player collides with trap
  4. Enemy collides with trap
  5. Enemy collides with player
  6. Enemy collides with wall
My plan is to
test #1 when the player moves (although I am not sure which of these is better: "before moving and preventing" or "after moving then bouncing back" )
test #2 when the player presses the eat button
test #3 whenever the player is in a tile which is adjacent to a trap
test #4 whenever the enemy is in a tile adjacent to a trap
test #5 whenever the enemy is in a tile adjacent to the player (this can be quite often though, as the enemy will be a chaser)
test #6 I was hoping to program in enough brains to the AI so she doesn't try to walk through walls (but maybe I should test this anyway)





Does this sound like the right way to do it?

Share this post


Link to post
Share on other sites
Advertisement
It would make sense for you to check the collision while doing physics (motion) because when your object is stationary, nothing interesting happens, and if something else collides into it, then you can send a "collision event" to the object it collided with.

Share this post


Link to post
Share on other sites

It would make sense for you to check the collision while doing physics (motion) because when your object is stationary, nothing interesting happens, and if something else collides into it, then you can send a "collision event" to the object it collided with.


You mentioned the word "while" did you mean:
Test before movement and see if they can move without a collision to prevent a collision with a wall
or test after to see if they have already collided and then move them back.

Share this post


Link to post
Share on other sites
I personally do it after I move the objects, but if you've ever messed around with Game Maker, you have the option to check if the space where you're moving is empty. I don't think this makes that big of a difference really, since both ways you should end up with the same result.

Share this post


Link to post
Share on other sites

I need to check for the following types of collisions.
  1. Player collides with impassible wall
  2. Player tries to eat food, (is she at collision with food?)
  3. Player collides with trap
  4. Enemy collides with trap
  5. Enemy collides with player
  6. Enemy collides with wall
My plan is to
test #1 when the player moves (although I am not sure which of these is better: "before moving and preventing" or "after moving then bouncing back" )
test #2 when the player presses the eat button
test #3 whenever the player is in a tile which is adjacent to a trap
test #4 whenever the enemy is in a tile adjacent to a trap
test #5 whenever the enemy is in a tile adjacent to the player (this can be quite often though, as the enemy will be a chaser)
test #6 I was hoping to program in enough brains to the AI so she doesn't try to walk through walls (but maybe I should test this anyway)

Does this sound like the right way to do it?


Simplify..... :)

Don't group those items together. Do #1 first and only, i.e. simply move the character accordingly to actual physical constraints. Do "nothing else" at this point. The before/after bit is a hell of a big topic which usually leads me to suggesting things such as Box2D or Bullet to do it. Not to be an ass, but they can save you tremendous amounts of debugging. (As always though, if you just want to learn it, sure thing, if you want to make a game, don't do it yourself.)

All the other items are (assuming) not actual collision items that you would bounce off of, you just care if they are close enough to eat/trigger etc. This is the job for an awareness system or if there are few enough objects in the system, just iterate and get distance, then answer 2-6 via queries as to the current state of the object "after" doing its motion.


Unless you are shooting for 100% determinism, there is no reason to keep the steps together. If "after" you are moved in a physics world you are or are not in the range of something that is easy to determine.

Share this post


Link to post
Share on other sites

Simplify..... :)

Don't group those items together. Do #1 first and only, i.e. simply move the character accordingly to actual physical constraints. Do "nothing else" at this point. The before/after bit is a hell of a big topic which usually leads me to suggesting things such as Box2D or Bullet to do it. Not to be an ass, but they can save you tremendous amounts of debugging. (As always though, if you just want to learn it, sure thing, if you want to make a game, don't do it yourself.)

All the other items are (assuming) not actual collision items that you would bounce off of, you just care if they are close enough to eat/trigger etc. This is the job for an awareness system or if there are few enough objects in the system, just iterate and get distance, then answer 2-6 via queries as to the current state of the object "after" doing its motion.


Unless you are shooting for 100% determinism, there is no reason to keep the steps together. If "after" you are moved in a physics world you are or are not in the range of something that is easy to determine.


Thanks, that is a very helpful answer. I will get number one out of the way first. I do want to learn it, but I also want to finish my game. I guess I will try it on my own first and if it really really sucks, then I will go with a physics library and also try to understand how they got it right and I didn't.

I didn't think I would need a physics engine for this project. But from browsing the sites of those two you suggested, it seems like it would make this a heck of a lot easier.

Share this post


Link to post
Share on other sites

[quote name='AllEightUp' timestamp='1324441059' post='4896029']
Simplify..... :)

Don't group those items together. Do #1 first and only, i.e. simply move the character accordingly to actual physical constraints. Do "nothing else" at this point. The before/after bit is a hell of a big topic which usually leads me to suggesting things such as Box2D or Bullet to do it. Not to be an ass, but they can save you tremendous amounts of debugging. (As always though, if you just want to learn it, sure thing, if you want to make a game, don't do it yourself.)

All the other items are (assuming) not actual collision items that you would bounce off of, you just care if they are close enough to eat/trigger etc. This is the job for an awareness system or if there are few enough objects in the system, just iterate and get distance, then answer 2-6 via queries as to the current state of the object "after" doing its motion.


Unless you are shooting for 100% determinism, there is no reason to keep the steps together. If "after" you are moved in a physics world you are or are not in the range of something that is easy to determine.


Thanks, that is a very helpful answer. I will get number one out of the way first. I do want to learn it, but I also want to finish my game. I guess I will try it on my own first and if it really really sucks, then I will go with a physics library and also try to understand how they got it right and I didn't.

I didn't think I would need a physics engine for this project. But from browsing the sites of those two you suggested, it seems like it would make this a heck of a lot easier.
[/quote]

FYI, take a look at my blog (in my sig), and go to some of the earlier entries. I detail adding a 2d physics library into my game (chipmunk-physics, which I whole-heartily endorse). Physics engines do make things so easy.

For you, hitting walls will happen automatically (assuming the walls and your player are in the same layer), and collision detection is simply a matter of registering a callback for 2 collision types.

And, for knowing if you are over an object you can eat, you'd basically want the edible objects to be defined as "sensors", and you'd get a callback when you start to collide with them, then a callback when you separate from them. So, the simple way of deciding if an entity (player or enemy) can eat an object would be, when the callback begins, have a field in the entity pointing to the edible object, and when it gets separated, remove that object from the field. When the user presses the "eat" button, if that field is filled, then that object is eaten.

Anyway, 2d physics libraries have made my life so much easier as far as making games go.

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.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!