Hi,
I’ve read many introductory articles to entity systems and is convinced that I need this for my game as well. However I’m not able to comprehend how exactly I can use one in jMonkey. I’ve not found some good real code examples. It would be great if someone can guide me regarding the architectural aspects and some real code examples of entity system code in jME.
@simar.i3r :
Zay-es is the Entity system which is open sourced and maintained by @pspeed . For architecture information don’t know he going to make a detailed one, but I have a short interview with him recently and will add very detailed question & answers about “Entity system” - “Pure data entity system” and his approaches in Zay-ES. The link will be appear here when I finish:
https://wiki.jmonkeyengine.org/legacy/doku.php/jme3:contributions:entitysystem
The part I made for the interviews information is Approaches and interviews, detailed implementation and design in Detailed
Cheers,
By the way the orginal topic for Entity system quesions and answer is: http://hub.jmonkeyengine.org/forum/topic/entity-system-topic-united/
@atomix said: By the way the orginal topic for Entity system quesions and answer is: http://hub.jmonkeyengine.org/forum/topic/entity-system-topic-united/
Thanks for the much needed help.
Pspeed has done some example projects for writing jME3 games using zay-es as well.
Hi, I’m actually confused whether I should go with entity component systems or not. My requirements engenders one to think that most obvious approach is entity component. Considering the fact that zay-ES is just a baby yet, Is it stable enough to work on?? I’m ready to get my hands dirty and report fix some bugs if they come across. Is it in active development??
How does it differ from existing ES projects like Artimis and other listed here ES Approaches - Entity Systems Wiki.
Zay-ES is a baby in the open source world but it’s been at the core of Mythruna for about 2 years or more. It differs from Artemis because it’s less upside down. It doesn’t force any particular “system” model on you.
I consider it “pure” because it lacks any of the things that are arguably “not an ES”.
My current thinking is that the core driving force for an ES is adaptability.
An OO class hierarchy is relatively rigid, which is good if you want to nail down some semantics, but not so good if you need to adapt to changing requirements.
For myself, I have decided that an ES is the right choice for the part of the program logic that the player sees, because that’s the logic that might have to change. So I’m planning to put AI logic (say, what makes an NPC attack you), player interaction rules etc. into an ES, and the underpinnings (physics) will be OO.
This decision is based on a few decades of general programming (no ES experience) and a few months of reconsidering the ES literature. So, take this more as a starting point for your own considerations, not as a readymade advice to follow.
@toolforger said: So I'm planning to put AI logic (say, what makes an NPC attack you), player interaction rules etc. into an ES, and the underpinnings (physics) will be OO.
Teasing this out a little… is that because you’ll be using bullet or other reasons?
If not because of bullet, which part of the physics:
-where you iterate over the same physics-related data structures over and over to “integrate”?
-or where you generate collisions and have to handle them somehow?
Can you describe the OO approach you will take for this?
@pspeed said: Zay-ES is a baby in the open source world but it's been at the core of Mythruna for about 2 years or more. It differs from Artemis because it's less upside down. It doesn't force any particular "system" model on you.I consider it “pure” because it lacks any of the things that are arguably “not an ES”.
I did not knew that. Then its not a baby actually.
I would be really grateful if you can give me inputs on how should I proceed in particular to my design. I want to make a simulation where the player can pick and place meshes using ray casting. The way things get picked and placed will depend on:
These meshes can change afterwards as requirements changes. How exactly should I go with this type of design. I can add components like display, headphone jack and do stuff but how should I have different types of pick and place which are triggered by input events. Should I add different appStates for these? Does your model allow me to add behavior code in components as well (although I know this is not recommended in ES but my design is not exactly a game but a different thing). I’m currently evaluating which design could be best for my different requirements.
@pspeed said: Teasing this out a little... is that because you'll be using bullet or other reasons?If not because of bullet, which part of the physics:
-where you iterate over the same physics-related data structures over and over to “integrate”?
-or where you generate collisions and have to handle them somehow?Can you describe the OO approach you will take for this?
The reason is that physics is a constant. Any conceivable change in game logic isn’t going to change the in-game physics, so the OO approach is good for guarantees like momentum conservation.
I guess I’d start moving physics to an ES as soon as the rules of physics themselves are subject to game rules.
Bullet itself is not a factor. It could be used from an ES or from an OO system.
If I were to do a collision detection lib, I’d probably do all the geometry calculations with an OO hierarchy. Mostly because the contracts around collision detection aren’t subject to change due to game rules.
The game ES would tie to that library just like it ties to the scene graph.
Not sure whether that’s answering your question. Feel free to ask more if it didn’t 
@simar.i3r said: I did not knew that. Then its not a baby actually. I would be really grateful if you can give me inputs on how should I proceed in particular to my design. I want to make a simulation where the player can pick and place meshes using ray casting. The way things get picked and placed will depend on: 1. Mesh that we pick. eg - picking a heavy object may do something that light can't 2. Mesh where we place eg - Place on a surface or I place on a drawer 3. I want meshes to have capabilities like a phone have display or a phone can attach headphones to it.These meshes can change afterwards as requirements changes. How exactly should I go with this type of design. I can add components like display, headphone jack and do stuff but how should I have different types of pick and place which are triggered by input events. Should I add different appStates for these? Does your model allow me to add behavior code in components as well (although I know this is not recommended in ES but my design is not exactly a game but a different thing). I’m currently evaluating which design could be best for my different requirements.
You “can” add behavior to components BUT a) you shouldn’t, and b) the desire to do so points to a design problem.
For example, display and headphone jack are not components. They are entities. The properties of how things are picked and placed could be components… but I’d have to know more details to offer better advice than that.
@simar.i3r :
in my personal pov, Zay-ES are quite advanced and integrated tightly with JME3 (it still have the needed level of abstraction)
If there chance that you still consider choices of Entity system, i want to notice you that seem like Artemis’s author eventually ‘abandoned’ it, but build another one toward java 1.5+ with anotation, injections and stuffs…
I’m also on my way to review all the avaiable options in this area, so questions are welcome.
@toolforger said: The reason is that physics is a constant. Any conceivable change in game logic isn't going to change the in-game physics, so the OO approach is good for guarantees like momentum conservation. I guess I'd start moving physics to an ES as soon as the rules of physics themselves are subject to game rules. Bullet itself is not a factor. It could be used from an ES or from an OO system.If I were to do a collision detection lib, I’d probably do all the geometry calculations with an OO hierarchy. Mostly because the contracts around collision detection aren’t subject to change due to game rules.
The game ES would tie to that library just like it ties to the scene graph.Not sure whether that’s answering your question. Feel free to ask more if it didn’t
Well, how/where do you intend to interface the OO with the ES? And what kind of physics you will be doing is definitely a factor.
If you start to unravel it, Position is probably an ES managed property. It’s possible that Acceleration and Velocity are also… or at least Acceleration. The mass properties that the physics engine uses for an object are probably also ES properties. Whether physics is run at all for a particular entity is likely some concert of components on an entity.
The physics engine likely has some OO stuff internally to manage its own book keeping. (RigidBodies, CollisionShapes, whatever). That would be quite common. This would even work with more of a bullet-like black box physics engine. On the other end of the spectrum, a simple physics loop like in Asteroid Panic could just be a regular ES loop that takes position, velocity, acceleration and produces position.
Then does it also handle all of its collisions internally or does it also produce some kind of ES friendly collisions that other systems could use? For example, some kind of collision sound system could detect collisions and produce sounds based on certain factors (sounds themselves being entities with some components: position, sound type, whatever). Or maybe a damage system could damage the entities based on the collision properties.
…and so on. All of those things could be added or changed later. Asteroid Panic took a shortcut here and just had a collision listener on the collision system that just did the game logic. I was trying to keep the example simple but I may swing back and make a more elaborate version some day. Especially if I want to have power ups and enemies someday, it will require a little reworking of that system.
Still not sure what you’re aiming at here, @pspeed.
The OO stuff is a service layer for the ES in my book. The ES keeps references (i.e. pointers or handles or whatever) to the service in a component. This sounds rather unremarkable to me actually 
ACtually you should od it the other way around, the es describes what i needs of the other modules in a component. (Eg box, 1meter sides 100kg) then a specific system makes sure this is done in the external module, and a hashmap using the entitiy id is used to link both. That way you don’t get dirty components, that contains non es stuff. (eg a physicrigid body is not a data part, it contains way to much internal state and logic)
Some general remarks:
There’s always the tension between decoupling (flexible, less guarantees) and guarantees (rigid, more coupling).
The right balance depends very much on details: Where do you need guarantees (and do you really need them), where do you need flexibility. The problem is that you don’t know upfront where flexibility is going to be needed, but make everything flexible and you get a huge blob of globals and no guarantees at all. (“Guarantees” in the sense of you look at the code and know what data may be modified by what code, in what ways.)
So I wouldn’t say that one “should” look at things in a particular direction; depending on circumstances, one or the other way might be appropriate.
The only exception is where some guarantee has ALWAYS been necessary. Or some kind of flexibility has ALWAYS been required.
Re the concrete issue: I don’t really care whether the connection between physics simulation data is grouped together with some other data into a single component, or in separate components.
I think how to group stuff into components is a decision that should be easily reversible - some stuff you absolutely need in a single object because they are tightly coupled and have a fragile interrelationship, for others, it might be more important to mix-and-match freely.
I wouldn’t necessarily want to expose physics objects as a component. Essentially, the ES establishes flexibility; it’s the API for the scripting language where you do the game logic. Anything below that doesn’t really belong into the ES layer - at least that’s what I’d try first when doing an ES for real (I’m still just theoretizing and applying design rules that I absorbed through the decades, this would all have to be verified through practical experience, so it’s all theories that are still in need of testing).
@pspeed said: You "can" add behavior to components BUT a) you shouldn't, and b) the desire to do so points to a design problem.For example, display and headphone jack are not components. They are entities. The properties of how things are picked and placed could be components… but I’d have to know more details to offer better advice than that.
But my gut feeling wants to make a complete mesh as single entity and place the entity object in the mesh’s custom data. I may be heading in the wrong side altogether. How should I integrate mesh and entity?
@simar.i3r said: But my gut feeling wants to make a complete mesh as single entity and place the entity object in the mesh's custom data. I may be heading in the wrong side altogether. How should I integrate mesh and entity?
The mesh is visualization data. Associate it with the entity in the visualization layer.
I have provided a fully working example that illustrates this. Just hit the Zay-es links page and look for Asteroid Panic.