Hey guys, I am typing this post on my mobile so I apologize in advance for any spelling mistakes
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
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
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.
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 ControlWalkableNPCControl 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
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.
@pspeed
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!
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.
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
With links you can have also hierarchy in hierarchy ā¦
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.
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.
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.