3
\$\begingroup\$

I'm working on a relatively generic 2D AABB collision detection system for a game engine, and I've re-written it more times than I'd like to admit, due to not calculating or recording specific details of each collision. Right now, this is what I'm collecting:

  • Collision time as a fraction of an update cycle in the game loop.
  • Location of the collision.
  • ID of the colliding object.

Each object has a Set that holds this data for each collision (I'm working with a component/entity system) so other systems can use the recorded data. The problem I just ran into was that I needed to know which side of the object the collision takes place on.

What other values or points of interest should I calculate or record, per collision? What do you look for in a standard collision detection system?

\$\endgroup\$
0
3
\$\begingroup\$

It depends.

What factors into the collision resolution? Depending on how sophisticated you want the engine to be, you may want to know the velocity at time-of-impact, which objects were involved in the collision, as well as many other factors. This is where I would give you the advice to write games, not game engines.

If you write a game, you can know what you need to support. If you write a game-engine, you have to make decisions like these, on what you're going to support and what you're not going to support.

If you're creating a game like Braid, where you can manipulate time, you might need to know everything you did, in order to undo the collision.

\$\endgroup\$
1
  • 1
    \$\begingroup\$ Great answer and blog post. The advice, I feel, has a lot of crossover value to framework design in all fields of programming. +1 \$\endgroup\$ Jul 30 '12 at 5:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.