Im currently developing a game with the entity-component system of Ashley in Libgdx (Java).

In the game you would be able to walk on planets (2D not 3D), fly in the star system and traverse between systems. These are all different types of levels that all need to be handled and rendered differently.

So my question is, how would you differentiate between these types (for example in the renderer), should I add a case for every type in the renderer or split it up somehow?


1 Answer 1


I don't think there is a completely correct answer to a question like this, but I'll take my best shot at it.

As I'm sure you know, one of the key ideas behind the entity-component architecture is that entities have data but not functionality, and systems contain functionality but not data. There are exceptions of course, but this is the general rule of thumb. As such, let's think of this in terms of data, then functionality.

The way you describe "types of levels", it sounds like these aren't levels in say a platformer sense (i.e. different locations) so much as different levels of abstraction (When I walk on the planet, I'm concerned with the terrain and features of that planet; when I take off, I don't care about the things on each individual planet as much as the relationships between the other stellar bodies).

What this means then is that from a data perspective, you're working with the same set of planet entities at each level of abstraction, you just care about different levels of depth. For example, when I'm walking on the planet, I need to know a lot of detail about that particular entity, and almost no information about the other planet entities (maybe you can see them on the horizon or something). When I take off, I'm concerned with the NameComponent and the IconComponent (or equivalents) associated with each entity.

As such, I would argue that whatever we do, we don't put level-type information in the planet entities themselves. Instead, you'll probably want to include some sort of state information like location (e.g. "Hoth VI", "Hoth System", "The Galaxy") or location type ("Planet", "System", "Galaxy").

Now from a functionality perspective, it sounds like you want to render the world differently depending on the "level-type" the player is in (i.e. you render a 2D side view when they're jumping around on the planet, a top-down view when they're navigating the system)- in an ECS this implies that you have separate rendering systems for each view type (or if they are 80% similar, a case statement in your rendering system).

I tend to use Artemis rather than Ashley, but I think one way you could solve for this issue would be to add a listener that fires whenever the player entity changes level types and adds/removes renderers from the world.

Alternatively you could have the renderers look up the player entity and check its location to see whether they should be rendering anything or not.

  • \$\begingroup\$ Alright, thanks for the answer, Ill think about and try to implement it as it sounds very reasonable. Btw, do you think Artemis is better than Ashley? If so, why? Im interested because I just started using the ECS approach and dont know whats better and whats not. \$\endgroup\$ Commented Mar 27, 2017 at 9:49
  • \$\begingroup\$ Well, I admit I just picked it because I liked the syntax better- didn't feel like I was writing as much boilerplate code. It has some more tangible benefits though in that it is more actively maintained and faster. You can take a look here: github.com/junkdog/artemis-odb \$\endgroup\$
    – John
    Commented Mar 28, 2017 at 4:34
  • \$\begingroup\$ Cool, I think artemis really means less boilerplate, thanks. I will use it! And I'll get around to implementing your approach. \$\endgroup\$ Commented Mar 28, 2017 at 13:50

You must log in to answer this question.

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