Game Development Stack Exchange is a question and answer site for professional and independent game developers. It only takes a minute to sign up.
Sign up to join this community
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?
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.
