2
\$\begingroup\$

Currently I am writing a litte 2D engine for training purposes. Some time ago I had some thoughts about good ways to implement and handle collision. (Not about the particular algorithm, but about how to notify collision in a general engine.)

I came to the conclusion that setting a flag and then resetting it in another place isn't a great way since I don't want to touch collision at two points in m game loop in general so I decided to go with an event based collision system which is also more easy for concurrency if needed since I can change the event type to an asynchronous model.

Basically each collision would trigger an event which contains the 2 colliding GameObjects/Actors and the collision direction for each of them as information to deal with the physic calculations which will result from the collision.

This approach creates the need for a proper event - dispatch system which also would have to be implemented

Now I wanted to ask if that is a valid approach in general or if there would be a better way dealing with collisions?

Basically event based collision allows to get easy customizable onCollision function calls for different GOs/Actors, on the other hand if one consider to create async events there would be much effort to make the whole system thread-safe and I would have to deal with the event implementation.

What would be a "best practice" approach for a collision system for a game engine considering the ways the industry is dealing with it? (I can imagine that there are several approaches but which would be the most popular ones)?

\$\endgroup\$
  • 1
    \$\begingroup\$ Asking for opinions on a general approach is, well, pretty opinion-based, and better suited to a discussion forum than the Q&A format that we use here. You can refine this question by outlining a more concrete problem - eg. are there specific risks that you've identified with this method that you need help evaluating? Are there specific needs your project has that this method might not fulfill? Basically, what's leading you to suspect that this is not a good solution? if we have those specifics, we can evaluate whether it's a real problem or suggest alternatives that better solve those cases \$\endgroup\$ – DMGregory Aug 2 '17 at 8:04
  • \$\begingroup\$ You could also handle like Game Maker Studio does: bind an event handler to an instance of one type of GO colliding with an instance of another type of GO. \$\endgroup\$ – clabe45 Aug 2 '17 at 14:52
  • \$\begingroup\$ I think your edit actually takes this further off-topic, changing from "judge my loose proposal" to "list popular solutions to the general problem of collision response" which is even broader. Again you can narrow this down by focusing on your game engine's specific needs: "what is a solution that meets criteria X, Y, and Z" helps cut the personal opinion and unbounded list aspects out so we can judge a correct answer. If you just want to implement something popular, go look up how big 2D engines like Box2D do it. If you want to invent a solution, then you need to be explicit about the problem \$\endgroup\$ – DMGregory Aug 2 '17 at 16:32

Your Answer

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

Browse other questions tagged or ask your own question.