To entity or not to entity?

Hey guys, I am typing this post on my mobile so I apologize in advance for any spelling mistakes :slight_smile:

At the current state I failed at the common pitfall of mixing Display and GameLogic. I have quite some code already but it is rather generic stuff. This leads me to the task of refactoring and properly implementing the games’ Features.

I think I might have trouble when trying to stream large worlds since just keeping the whole scenegraph somewhere in Memory is impossible for huge worlds, correct?

So now i am thinking about the best way to organize my game logic. I have skimmed over some articles regarding entity systems and they claim the Main Problem to be multiple inheritance.

Thinking about how I did my Code I partially avoided this by using one control per specific feature. Is this a bit like having an entity system?

How (apart from networking) could I benefit from an es and what are the drawbacks (Because I regularly read about people modelling their system wrong and have to start over and the most scaring thing: “Loosing OOP principles”. I was so proud that I could organize my game quite oopy so far :smiley:

Btw: I understand that you dont have the time to explain such a thing multiple times so links to good articles are welcome as well :slight_smile:


No. That’s more like having appstates.

OOP can work great until the complexity makes your code a complete mess… the only real drawback of ES is the learning curve.


After that it is quite freeing, though. The idea that concerns are completely separate is quite nice.

The flexibility is a bonus. I mean, if you decide you want to attach AI to a chair and have it walk around but otherwise be exactly like a chair… there is literally no new code to write in an ES system. Just add the right components to your entity. You quickly realize that this whole idea of “classes” as being something in the game world “Orc Chief extends Orc extends Mob” etc… is just a construct for humans as a way of kind of understanding things in a certain way. It does more harm than good in the end. It’s way better (in my opinion) to think about ‘entities’ as a collection of behaviors. The “Orc Chief” is such only because he happens to contain the components that give him AI, mobility, an Orc chief model, etc… Each new capability of your game is just a new set of systems and then figuring out which previous entity ‘types’ you might want to add those components to.

The best way to get a feel for it might be to look at some examples. I don’t know what you’ve already looked at. My Asteroid Panic example is pretty simple and non-networked. I believe it shows some of how an ES is wired up… but then I would because I created it for that purpose. :slight_smile:

My suggestion would be to hack a simple game the ES way. I took astroid panic from @pspeed to hack my own followed by a couple of stupid questions (where I got excellent answers btw).

Or take my invaders and work it through. Afterwards you understand quiet well @pspeed’s sample above. Before I did my first trial I had no clue how this magic works.

And your objects, logics you use in systems can be still OOP.

Well I don’t mean “Features” but I have classes like Damageable Explosive Control WalkableNPCControl etc and then I combine those Controls. I think this is something like Components?

What would I do if I wanted a Orc Chief which Grunts out of satisfaction after each thought (AI Calculation). The usual Behavior would be to subclass the AI Behavior but that is wrong I guess. Is it that “AI” would be a composition of “thousands” of individual components where one is the “OnAICalculatedComponent”? And then call this by Events?

I will look at Asteroid Panic more in-depth soon, I only saw the Mass class so far, but currently it looks like I would build everything from very very small components?

Does this mean like the Classes handling the Entities? The Entities itself shouldn’t have handling code as they are part of the “Model” Part of MVC?

And I guess I would be doomed if I subclass Entities? But what if there would be some evolvements not actually adding new behavior but changing the current? E.g. riding bikes vs. riding motorcycles (Okay, that is constructed but the animation would be different). I guess then I would add some boolean or enum or something and simply use an if?

Is a system basically a collection of Components?
If yes, then this is only a convenient way to add/manage multiple components to one entity?

Last thing: ES are regularly updated by itself outside of the Main Thread or do I have to build all that logic?

I will try to experiment with ES soon then, as soon as I get groovy to behave. It made me cry for the last two days though :smiley:

No! Only stuff like your modells your helpers what ever. So everything beside entities components or systems! But I mean your AI code can be OO as it is aside ECS. Never ever mix OO in ECS.

I once read that on a different abstraction level you can use OO, that is what I mean.


I don’t really want to address each of your points individually because I feel like these have been gone over before and are probably in the docs and mostly stem from a misunderstanding of what ES is.

Just remember that components are DATA ONLY. Just DATA. No code. So already systems are not “a collection of components”. “Systems” are the things that do the work in your game… usually by selecting a set of entities that has certain components.

Read the docs. See how Asteroid Panic works… look beyond the “Mass” component. The physics system is one of the better systems for seeing how ESes are wired, though.

The docs JME provides… written by someone else from discussions about entity systems:

There are also the Zay-ES docs which are a bit lacking except there are some case studies:

And then there is the Asteroid Panic example:

And for a not-fully-a-game but networked example you can see the SimEthereal basic ES example:

1 Like

kind sir, this extremely important subject/thread should be stickified, as the entitysystem explanation link “should too in some way”?

my pet project will have to be cured b4 it’s too late and it die “again”, as I (the developer) am already feeling it’s symbiotic symptoms :/, better sooner than later :>, and the possibilities and code decomplexifying promise are quite exciting! back to re-coding with a relieved soul, thx u sir! :smiley:

example project here:
GitHub - jMonkeyEngine-Contributions/zay-es: Zay-ES is a Java-based high-performance entity-component-system. (usage example)
JMonkey Entity System - #2 by mifth

I agree some of the docs should probably be easier to find but those with the motivation will find them I guess. :slight_smile:

Good luck on your conversion. In the end it will be much better.

1 Like

I actually found about it by pure luck.
Despite I was having the problem for a long time, never considered this could ever be possible b4 today.
Thx @Darkchaos for the Shakespeare inspirational thread title hehe…

One thing I could not find out yet (mainly due to the github search being “broken” since Event is mentioned in the BSD License):
Are there Events built into zay-es or should I implement them myself?

The background is that I have a Model Component/System which loads the Model and I have a system for name tags. Now in order to add the name tag to the model’s node, I have to wait for the model system to load it. That is why I wanted to send some event from the Model System to the TagSystem with some EVENT_MODEL_LOADED thing. Is there any code to look at? (I can’t find it since every file is listed due to the BSD License)

Events have nothing to do with an ES… so No, Zay-ES doesn’t include anything event related. Usually it’s not needed and definitely not needed inside the systems.

Even in your case there are easy ways around the event issue. For example, create the node and then attach the model to the node… then you don’t have the problem.

Or completely decouple the two and treat the name tag as completely separate from the model… they are just two different views of the same entity.

Or you can look and see how the SimEthereal example does it to show the name of the logged in player above their ship. The one already listed above.

I don’t want to argue on that point but I’ve read it on multiple pages including wikipedia and it definately could be that you need some inter-system communication. On the other hand I guess it is also better to call methods on the system instead of some event bus if it’s no kind of broadcast message.

Two different questions arose:
A) You have dedicated ModelStates which have a list of Spatials. Is there any reason (other than architectural preferences) for this instead of directly referencing the spatials in the component?

B) How would I model hiearchies? Best example:
The Weapon Entity has to be related to the Carrier. Now there are plenty of ways: treat the position as relative and add it under it’s parent to the scenegraph, implement something like the scenegraph (calculate the world translations for all those positions) and store it { in the component, recalculate it each time on demand}.

My problem with the first approach is that it does not decouple graphics from logic where however redoing all the work feels wrong and is actually twice the ressource usage as well… On the other hand I might need the positions for some systems and making them only work when you have a renderable component is wrong as well.

Needing events between systems is often a sign that there is a design problem. Systems are already communicating through components… it’s so very rare that they would also need to communicate through events. …but at this point I’d need a use-case to argue more specifically.

Why do you have dedicated model states? And if so, why do they need to communicate with each other?

Either way, Spatial in a component is definitely wrong. Think of a client server architecture where your server is highly distributed over a farm of databases. Why does that farm of databases need to know about a Spatial? Sometimes it helps when performing these exercises to think that way. It helps separate purely visual stuff from game stuff. A spatial is not a game object. Putting one in the ES is the equivalent of storing a Swing JTextField in a database.

Usual way would be to have a component that points to the parent.

But that doesn’t necessarily mean that the hierarchy gets reflected in the scene graph. That’s more of a byproduct of how you handle position then anything else. In your game objects, is the position also parent-relative? If so then yes you have something that points to parents and the game objects then inherit their positions from their parents… and it is proper to reflect that in the scene graph version of the visualization. It’s a game object relationship “this turret belongs to this tank”. “this sword is in Link’s inventory”… and so on.

1 Like

I meant one ModelState, actually that class. But it makes sence when talking about networking or databases.

Regarding the other issue: My question was rather to what degree should I implement that hierarchy into the components like having only the OwnedBy or CreatedBy reference like you provide that or also modify the Position to have a local and a world field to contain the values, worry about affine transformation, the order of transl, rot and scale and such or the third way: abusing the scene graph.

For example I could always have some “out of tree” scene graph which only consists of nodes, even on the server, just so I can rely on jme’s maths skills.

Or is there some clever design trick I am missing? What I want to avoid is that each system (AI, Render, Physics, …) all need some code and re-calculate the position each and every time, so I might have to go with method two (local and world inside of position).

Physics will have its own concept of hierarchy. AI probably won’t care most of the time.

You could have a separate ChildPosition if you want but it’s possible to do it all with Position and a parent component. If there’s a parent component then it’s relative. If there isn’t then it’s not relative. Your model system just has to be a little smarter about how it uses that.

But in the end, that’s kind of the point. Each system may do completely different things with that information. Some may build a scene graph hierarchy. Some may build some complex physics rigid body contraption. Others won’t care at all.

If we stay too long in the hypothetical then it’s hard to comment. So we should probably defer additional conversation until you have actual real use-cases in mind that you can talk about.

I also have only positions. I do the “hierarchy” with a link component where the child points to the parent and kind of an offset component to tell that child the distance and stuff. A follow system cates then for the right position (you then even can make that follow soft with a damping niche for the camera which is in my case also a child of the hero :smile:
With links you can have also hierarchy in hierarchy …

1 Like

Yep, that’s also a way to do it if you carefully order your game-level systems so that the ‘world’ Position gets resolved before anyone needs it.

1 Like

I might add, that I personaly found a ES system a bit harder in debugging, as it is multi-threaded, and you cannot simply follow a update() call in any of your game objects all the way, Because instead in dozen of systems a small snipped for it will be executed.

1 Like

I use the simpler way, of continually regenerating the world position via a system, so it is at most one tick behind, this does not matter for most game logic.

1 Like