Take the 2-minute tour ×
Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.

I am trying to set up a collision system for a tilemap in my component based entity system, but having trouble with figuring out how to do so.

Currently I have the following approach: My tilemap consists of a Tilemap_Component, which just holds the array, a Tilemap_Render_Component, which holds the Tileset image, and a Tilemap_Collision_Component, which holds the information which tile value is handled as a wall.

To make an entity collideable with the tilemap it needs currently the following components: Movement_Component, which holds the X/Y Velocity, Position_Component, which holds X/Y Position and Tilemap_Collider_Component, which holds the information if the object only collides with walls or as well with some other objects in the tilemap.

Now my problem is the following: It is very hard to determine what to do with an object which collides with the tilemap. If I set velocity to zero, it is possible to glitch through walls because Movement and Input are handled in other systems than the collisions. If I just change the Position of the object, there occur two problems: One is, that the object starts to flicker because it has moved a bit. The other is, that I would have to know how big the object is which is colliding with the wall. Now I could just say that a Render_Component is required for objects which can collide with the tilemap and then use the image information in the Render_Component of the object and the Tilemap_Render_Component of the tilemap to calculate collision, but I think this is a bit against the intention of component based system.

What would be your suggestions? How could I handle this problem? Or, as well: Was anyone of you faced to such a problem? How did you solve it?

share|improve this question
1  
Have a look at this question and this excellent article referenced within. The executive summary is that you find out which collisions occur first, compute the new movement, and calculate collisions again but from that point in time. Also, these problems are orthogonal to component based systems or tile maps so all that info is irrelevant in your question. –  congusbongus May 8 '13 at 23:26
    
Thanks for you comment. But: My actual problem is not how to calculate the collision. The problem is how to apply all these collision things in a component based approach. Because even with the information in the article: I still would have to know the size of my object. But I can only know that if I know the render_Component as the size of the object is the size of its image. But I do not know if that really fits into the idea behind component based architecture. –  M0rgenstern May 9 '13 at 12:05
add comment

1 Answer 1

up vote 1 down vote accepted

I do tiles collision in a dedicated TilesCollisionSystem where relevant objects register their TilesCollisionComponent.

The component contains a pointer to the geometry used for collisions. Some objects only register to the TilesCollisionSystem (some particles for example).

This way there is a dedicated system for tiles collision and it goes only through the list of objects registered with the system and for each object only the nearby squares are manually tested in the system. This is not the most flexible way but it works really fast in my case.

You could make it more flexible by adding geometries for the different tiles types as well.

I test the position of each object and if the movement since the previous tic goes into the tile I check the nearby tiles that have collided ad well and move the object out of the tiles using a vector which allows the most movement to the object without entering the tiles. Once the object is moved I go to the next object.

Of course the collision is applied after all movements have been applied (including other more complex collisions). And after input and AI scripts which could change the position have run. The movement vector (current speed) is set to the resulting movement (calculated from the tiles collision) adjusted by the delta time, this way gravity is applied on the next tick and cancelled in the same tick by the TilesSystem if the object is still touching a tile.

The display is synced with the simulation only at the end.

If your sprites define the size of your objects then, i guess, they can serve as "geometry" in your component.

share|improve this answer
    
That is nearly the thing I am doing now. I had to make sure, that my systems were called in a certain order. Otherwise the images flickered. I now use images to check collision as it does not make sense that things can collide which have no images to render. –  M0rgenstern May 10 '13 at 12:46
    
@M0rgenstern: If you use the sprites as geometry don't forget to not release them before you release all components that use them (display and collision). Or if you use a ref counting system retain your sprites in both and release them at the end of all involved components' life cycles. –  Coyote May 10 '13 at 13:33
    
I will make sure that this happens. But usually I hold all sprites until the program ends. –  M0rgenstern May 10 '13 at 13:57
    
@M0rgenstern: I added more details concerning the order of the collisions and other systems. –  Coyote May 10 '13 at 14:19
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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