4
\$\begingroup\$

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

\$\endgroup\$
4
\$\begingroup\$

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.

\$\endgroup\$
  • \$\begingroup\$ I understood everything but the stacking thing, what do you mean by stacking? Stacking entities wouldnt mean intersecting them? Why would that be an option as a collision response? Or am i misunderstanding? Anyway your idea of creating a class that handles the collision of the entity lists separately doesnt sound like a bad idea indeed, i might do that as it separates the collision logic from the rest of the game's object oriented architecture (: \$\endgroup\$ – Xkynar Sep 15 '13 at 5:54
  • \$\begingroup\$ Please answer, im interested in your answer (: \$\endgroup\$ – Xkynar Sep 15 '13 at 19:02
  • \$\begingroup\$ By stacking I mean entities resting on other entities in a stable way like this image. \$\endgroup\$ – ClickerMonkey Sep 17 '13 at 15:29

Your Answer

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

Not the answer you're looking for? Browse other questions tagged or ask your own question.