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

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .