0
\$\begingroup\$

I'm developing a 2D game engine and right now I'm designing the collision system.

I've read about space partitioning and quad trees, and I understand that only the objects that are in the user's view need to be drawn and checked for collision.

All the objects, regardless whether or not whether are in the user's view, need to updated, but what's happen if an object out off the user's view collide with another object? I mean:

Should I check all the collisions in game world, even if the objects are not in view?

\$\endgroup\$
5
  • \$\begingroup\$ Think about it: Player drops a bomb at coordinate X, and run. 2 seconds later, the bomb explodes, but since it's no longer in view, the physics are not applied to the objects around. It's ok if the player never comes back to X, but if they do, how do you manage it? Apply the action of the bomb at that moment? This will look odd. Just make as if there has never been a bomb? This will also look odd (Oh, I though I had dropped a bomb in here...). You should check all the collisions in the game world. \$\endgroup\$
    – Vaillancourt ♦
    Commented Jun 5, 2016 at 22:07
  • \$\begingroup\$ One way to reduce the cost of collision resolution is to automatically disable objects that have not moved for a while and reactivate them only when they get a new contact. \$\endgroup\$
    – Vaillancourt ♦
    Commented Jun 5, 2016 at 22:09
  • \$\begingroup\$ @AlexandreVaillancourt - Haha, your first comment was very fun, thanks :) \$\endgroup\$
    – Beto
    Commented Jun 5, 2016 at 22:25
  • \$\begingroup\$ Assuming you are using the same space partitioning structures for the scene culling and for the collision system. Only the culling depends on what the player can see at a given time. The physics still must be computed. If you want to optimize physics again the player view, then make all enemies stop moving when they are too far away from the player. If you are 100% sure that an entire chunk of the map won't have any collision, you can save a lot of collision checking. Worry about it when the times comes (maybe your game never reach the stage at which worrying about this makes sense). \$\endgroup\$
    – Hatoru Hansou
    Commented Jun 5, 2016 at 22:38
  • \$\begingroup\$ It is not the law that you have to simulate physics outside of player view. Yet, not doing it makes for bad games. Although, this is not a dichotomy. You can selectively simulate things outside of player view. For example, simulate anything in a given radius out side of view, or allow actions that may have large impact on the world or that the player initiated to continue to work. It also depends on game genre, and how important are physics for the gameplay. \$\endgroup\$
    – Theraot
    Commented May 30, 2017 at 15:57

1 Answer 1

Reset to default
4
\$\begingroup\$

Generally game mechanics should not behave differently depending on whether or not the player observes the event. The player expects that the game mechanics outside of their field of view behave exactly as those inside their field of view. It is very immersion-breaking when they leave an area, enter it again shortly afterwards and apparently in the mean-time something happened which actually shouldn't have been possible according to their understanding of the game's collision rules.

However, for larger game worlds it can sometimes be too performance-intense to do so. There are different methods to deal with this:

  • Freeze the game world in areas where the player is not present. This includes updating. Continue the simulation where you left off when the player comes closer again.
  • Discard the state when the player leaves and initialize it as if they had never been there when the player enters again (a lazy but actually very common solution)
  • Simulate far-away areas with a simplified model of your game mechanics which is less accurate but still results in the things happening as the player would expect them to happen.
\$\endgroup\$
0

You must log in to answer this question.

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