I'm working on an entity-component-system based 2.5d game. That is, entities are groups of components that are processed by systems. I am having a hard time seeing how a sprite rendering system, that targets entities with a "RenderableSprites" component, can effectively manage components when processing so that only sprites that are on screen are iterated and subsequently drawn. I can see various solutions with LINQ etc. but they all require iteration through the collection of components whether explicit or not.

What is the common practice to deal with this problem, even if not in the paradigm of entity component systems?

To solve this problem with my tile based "floor" entity, it was best to group the floor tiles into one entity whereas before they were separate. This allows indexing of tiles by position in a tilemap so that every update step (to be later limited to updates where camera movement is detected), tiles are methodically selected rather than filtered via iteration and propagated to the "RenderableSprites" component, hence tiles that are not on screen are not processed in the draw step.

I am now adding scenery entities, but it doesn't scale particularly well when each tree is a seperate entity. Any suggestions as to whether scenery should be grouped into one entity? This seems to defeat the point of an entity component system and my spidey senses tell me this will lead to difficulty calculating collision etc.

Any feedback much appreciated! I am working in XNA but I don't consider this a very language specific question.

To anyone interested: I'm in the processing of working around this; I am constructing an entity manager storing entities by ID, something I should have done earlier. This will allow me to maintain some spatial indexes against entity IDs that the sprite renderer can reference before selecting which entities to process from the manager. This is as opposed to each System holding concrete references to its target components. I will maybe post some code when I'm done.


1 Answer 1

  1. Keep list of compatible components in each system. This way you don't have to iterate over every entity. Your entity manager can take each new entity, and dispatch its components to the correct systems.

  2. IMO tiles shouldn't be entities. It's just too memory expensive. Also, as you noticed, tilemap needs special treatment in rendering (also physics), where you want to select some area of tiles, instead of iterating over each tile.

  • \$\begingroup\$ Thanks for the answer krzat. Each system already stores lists of compatible components. My problem lies in the fact that the system must iterate all 5000 compatible RenderableSprites components regardless of whether those RenderableSprites contain any sprites that are on screen or not. I want to reduce this iteration to the say 200 components that are actually relevant to the draw step as i believe this is the source of the performance cost. \$\endgroup\$
    – user25127
    Commented Jan 14, 2013 at 11:16
  • \$\begingroup\$ If you don't want traditional tilemap, you can implement spatial partitioning, for example grid: link \$\endgroup\$
    – szotp
    Commented Jan 14, 2013 at 11:32
  • \$\begingroup\$ A tilemap is fine for tiles but for entities that sit on top of the tiles, e.g a tree which may occupy 2x2 tiles, 4x4 tiles etc. how would a map or spatial partitioning be implemented on components? \$\endgroup\$
    – user25127
    Commented Jan 14, 2013 at 12:10

You must log in to answer this question.

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