Gameworld and Collision management

Newbie & Debugging Questions
#1

Hello,
for a new game i am thinking about to create i need a Gameworld, which contains all the entities and manages the collision detection between them.
The game is a 2D Tile-based game and contains 3 entity types:

  • Type A: Static/Non-moving entity (“Blocks”)
  • Type B: Controlable entities (Player and NPCs)
  • Type C: Other moving entities like projectiles, which are not controlled by AI or Input

The entities cannot collide with other entities of the same type. That means, Type B entities cannot collide with other Type B entities, Type C entities cannot collide with other Type C entities.

Therefore i thoguht the Gameworld should have:
A 2D Array of Type A entities, as the game is Tile-based and the Type A entities won’t move,
A List of Type B entities and
A List of Type C entities.

Then i could cycle through the Type B list and for every Type B check:

  • If the 2D Array of Type A entities contains a value at my new position
  • Cycle through the Type C list and for every Type C entity check if it collides with my Type B

Also for every entity in the Type C list i would need to check, if it collides with one of the Type A entities.

The advantage i see is, that i don’t need to check every entity-combination, but only the combinations, that can collide with each other. Also the check between moving entities and “Blocks” should be quit efficient this way.

What do you think about this method? Is it good practice to sepperate the different entity-types in different lists?

#2

Only one way to find out: what happened when you implemented this to test it out? Maybe create a small prototype MCVE just to try it out?

#3

Thanks for your answer :slight_smile:
Well, the question was not actually, if it will work, but more if thats a clean solution for the given problem.
It should work, if the collision detection itself is implemented correctly, i am just not sure if it is the best and cleanest solution to seperate the entities into different lists.
But to me it seems pretty clean and it shouldn’t be hard to implement, i guess.

#4

The standard way physics engines handle this is to use layers and bitmasks. Every physics object has a layer mask on it, the engine iterates over all the objects, checking the mask, to see whether it should be checked for collision or not on a layer. Although this system checks for items on the same layer, and yours checks for items on a different layer, you can still use the same system by changing the bitmask compare function.

Your suggested way will be fine. However, if you were to start increasing the amount of types of objects you have, you’d need a conditional block detecting collision for all other objects, for each object. It may get a bit messy, but it’s nothing to worry about or to change at the moment.

Remember not to check for the same collision twice. If you check collision A with B, you shouldn’t check collision B with A.

Whichever way you decide to do it, you will have the same run time complexity.

#5

@Husk Thanks for your answer.
The system you mentioned sounds interesting, i think it’s the same as the collision-filters in Box2D.
Also you are right, that if i add new Eintity-Types it could make things a lot more complex, but in that case, i guess, i could change the Gameworld to use one list only.
So i guess my approach isn’t as bad and i will try using it :slight_smile:
I also won’t check the same collision twice, i plan to use a nested for-loop. The outer cycles through the B-Types, the inner cycles through the C types. The outer checks collision between A and B, the inner between B and C as well as A and C.
Well, i will see if it workd.
Thanks for your answers!