Collision Code Organization

Question

Im making a game in java as a hobby and ive reached a part where i have a few game elements which i want to have collision. Since im using a tilemap, the collision with the wall tiles is pretty simple and since every game element has a pointer to the tilemap, the tile collision code can be placed in the game element class itself, so that every game element collides with the map, at least.

but as for the collision between the game elements themselves, which im going to do with separate axis theorem, i dont really know where to place it. the objects of each level are created on the said level class, since im using a game state manager and each level has a separate class (everything is a state basicly, lets say menu, level1, level2 etc)

So i COULD put the collision code in a, lets say, superclass of Level, but it sounds kinda wrong to put collision code on a class like that, and i dont really have any ideas.

So i would like to know how you organize your collision code in your games, i appreciate any kind of technique or simple architecture

Answer 1

Create a separate class that has reference to the list of entities in your world. The entities should have metadata on them which dictates the type of entities they can collide with. Your new class should do two things, determine all possible collisions (this is called broadphase in the game-physics world), and then handle those potential collisions.

The first step could be a simple loop through every entity and check for collision with every other entity, OR you could use a spatial database to make this part quicker (like a grid, quadtree, etc). If you haven't used a spatial database before, just do it the former brute-force way.

The second step involves the actual collision checking.

There are SO many things that could change the way you handle collisions between entities. If you wanted your entities stackable for example, you would have to handle it a different way: You would loop through each entity, determine it's future position... and then check if it's future self would intersect with anyone else... if it does then don't move to the future position (or move it close enough so that it's not intersecting). Note the difference here, one just blindly updates position of all entities then tries to resolve collisions (like most physics libraries) and one carefully moves one entity at a time... which enables things like stacking and it avoids crazy intersections between multiple entities.