Jump to content

View more

View more

Image of the Day

Boxes as reward for our ranking mode. ヾ(☆▽☆)
#indiedev #gamedev #gameart #screenshotsaturday https://t.co/ALF1InmM7K
IOTD | Top Screenshots

The latest, straight to your Inbox.

Subscribe to GameDev.net Direct to receive the latest updates and exclusive content.

Sign up now

Appropriate place for collisions?

4: Adsense

Old topic!

Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
2 replies to this topic

#1 malignant   Members   


Posted 06 July 2014 - 04:09 PM

Hi I'm not very familiar with the standard structure of how things are usually set up.  I'm wondering where do people normally handle collisions, within each object or outside of the objects and just checking if each object in a list comes into contact with anything?

#2 BeerNutts   Members   


Posted 06 July 2014 - 04:16 PM

Collision check is usually done after an object moves.  So, after an enemy moves, you'll run collision check on that object against the other objects it might have collided with; check if it hit the player, hit the wall, etc.  If it does, then you do the appropriate response.


After you move the player, you do the same thing.  Same with bullets.


Of course, if you use a physics engine, then all you do is give the physical objects a location and some velocity or force, and say "go" and it does everything for you every game loop.

My Gamedev Journal: 2D Game Making, the Easy Way

---(Old Blog, still has good info): 2dGameMaking
"No one ever posts on that message board; it's too crowded." - Yoga Berra (sorta)

#3 SeanMiddleditch   Members   


Posted 06 July 2014 - 05:44 PM

Typically structure is something like:
  • Apply physics integrations (velocity, acceleration, etc.)
  • Find all collision pairs (including contact manifolds and so on)
  • Resolve collisions and constraints (collisions are just a non-penetration constraint)
  • Generate events from new collision pairs, maintained collision pairs, and expired pairs (you need to keep last frame's list of collision pairs)
  • Process events either in systems or in individual game objects/components (which makes the most sense is dependent on your game)
The key bit that answers your question, I think, is the last one. Your physics module will generate events. These events look something like:
struct CollisionEvent {
  ObjectHandle firstObject;
  ObjectHandle secondObject;
  Point        contactManifold;
  Vector       relativeVelocity; // first-to-second
You could let your game state class handle it. You could let individual game objects or components handle them. E.g., something like:
// this could be a GameState or PlayerEntity or BulletComponent or whatever
class Object {
  void HandleEnterCollision(CollisionEvent const& ev) {
    log("I collided with something");

  void HandleMaintainCollision(CollisionEvent const& ev) {
    log("I'm still in contact with something");

  void HandleLeaveCollision(CollisionEvent const& ev) {
    log("I'm no longer colliding with the thing");

  void Initialize() {
    phyicsSystem.OnEnterCollision(this, &Object::HandleEnterCollision);
    phyicsSystem.OnMaintainCollision(this, &Object::HandleMaintainCollision);
    phyicsSystem.OnLeaveCollision(this, &Object::HandleLeaveCollision);

Game Developer, C++ Geek, Dragon Slayer - http://seanmiddleditch.com

C++ SG14 "Games & Low Latency" - Co-chair - public forums

Wargaming Seattle - Lead Server Engineer - We're hiring!

Old topic!

Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.