I've been working on a space simulation game. The player can control a ship and fly through wormholes to get from one solar system to another. I would like the player to be able to switch the camera view between the different solar systems they own something in (world, factories, defenses, etc).

If am using just one component entity world then how do I tell the rendering system that looks for sprite components to only draw the sprite components of one solar system?

I could add a "solar system id" field to each sprite component and have the rendering system check each component before rendering to make sure it's in the "active" solar system. It doesn't seem like a good idea though. Mostly because I'd be adding another if case before processing every single sprite, at the very least (other components may need similar checks).

I could have the rendering system maintain an internal map of which solar system contains which entities, but then I have to write entity systems that keep track of all the entities, which is my entity system framework's job (Artemis for Java).

Currently I am planning on making all of the solar systems separate from each other. They wouldn't exist in the same coordinate system. I suppose I could instead put everything on the same coordinate system and just move the camera around based on which solar system the player wanted to view at that time. The problem with that would be that my sprite rendering system would still be looping through all the sprites in the game, instead of just the ones at the active solar system.

So, for lack of better options, I'm leaning toward using multiple component entity worlds. So each solar system would get its own set of systems (including the rendering system), and I'd set which one was active to enable the rendering systems for that solar system.

I didn't want to take this approach for two reasons. First, it adds another layer of complexity on top of everything. Second, it seems like it might lessen some of the performance benefits (caching) of looping through all the same types of components and running the same entity system algorithm. Instead of doing a breadth-first loop through all the components it would be more of a depth-first loop through all the systems' components.

So what is the best way to handle this?


1 Answer 1


That depends, like you pretty much said yourself, on how much change you are willing to make to your code base. I'll give you one suggestion I've used before and have liked. Some pseudocode:

class Sprite { ... };

// You can have several instances of this one
class World {

    SpriteList renderQueue;

    void DrawSprite(Sprite s)

// This one can be a singleton
class Renderer {

    void DrawWorld(World w)
        for each sprite in w.renderQueue
            // Perform draw calls to your rendering API. I.e.: OpenGL/D3D

// Then in the game code:

// etc...


One nice side effect is that you get a render queue for free, which can be used to sort your sprites/geometry according to some criteria before actually drawing. Better still, if you take some care, you can multithread your rendering by adding the sprites to the worlds in parallel, if the worlds are unaware of each other. Then you serialize when issuing the Renderer.DrawWorld() calls.


You must log in to answer this question.

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