# Entity-Component-System design

I read a lot about ECS (strategy) pattern and have a few questions. Consider simple space game.

1. We have stars there. Obviously star is an entity. What if I want to make a galaxy? It looks reasonable to make galaxy an entity. On the other hand galaxy is just a set of stars. In usual OOP design I would just made it a class which holds a list/vector of stars. Is it legial to make an entity which is just a container for other entities? Wouldn't it brake at some point?

2. Now consider planetary system. It looks like planet is an entity too. But it would be wise to link a planet to its parent star. May one entity refer to another (having pointer, or something like that)? How would you compose that?

This is an X Y problem. An entity component system is a sort of design pattern like you would find in typical software engineering. But entity component systems are meant to solve a certain type of problem. The problem is one of dealing with objects with many components with unbounded complexity, such as RPG items having different effects and abilities, where inheritence would result in potentially hundreds or thousands of classes in order to encompass the complexity/ and/or constant downstream client side updates to actual code in order to add new items.

ECS is not a system meant to be used in simulation systems or games with unbounded number of entities (say thousands) in play at one time, where the number of entities is the dominating factor in performance. Entity component systems have a very real, very significant performance cost compared to just simple inheritance or composition, and the decision to use such a large system should not be taken lightly. The cost of using ECS can be ignored when the number of entities is not the primary performance factor on your system. The use case for ECS is legitimized when you have a situation where "I need to be able to get a sword with 10 different elemental types on it and 10 other effects, or some combinations of a very large amounts of effects", not one where "I need to create a building".

This is a problem that not all games have, and given what you've said your problem is, is one you simply don't have. Additionally you can have ECS and not have every entity in your game live inside the ECS framework. Some entities may be inside of ECS, while other, less versatile entities can just be plain entities which exhibit normal inheritance characteristics.

Your situation doesn't call for any of this complicated ECS stuff because you have a very small finite amount of entity types and a known configuration for each entity (they don't have dynamic components).

You have stars, planets, planetary system, galaxies. Galaxies contain solar systems, solar systems contain at least one star and 0 to 1 planets.

Stars have certain characteristics, and the list of those characteristics never change (temperature, size, etc...), planets are likewise the same. You don't need ECS to solve this problem, simple OOP design and arrays will solve your problem.

So stay away from ECS for this part of your project, it won't solve your problem, and as you can see from even needing to ask this question, it will just make your life more difficult trying to fit it where it doesn't belong.

• Thanks for your brilliant answer. I upvoted both answers and accepted yours. – Jasper Dec 8 '17 at 19:41

Why not give each star a galaxyid? If the entity is not a star, but e.g. an astronaut, set it to -1.

To find stars in a galaxy, just iterate over all entities and check the galaxyid. If this is expensive and has to be done frequently per frame, then just cache that info.

Your array with entities/stars will remain flat this way, and there will be no need to iterate over containers.

This makes the membership by a star of a galaxy to be an attribute of the star, as opposed to actual container data structures.