You are probably right and I trust your words, Paul. I’m not gonna argue with you since I don’t have any experience or a firm grasp of what I really talk about in this case 
Thank you sploreg and paul (I may call you by your first name?^^). I was thinking about something that was similar to an entity system before when I asked myself how I could enable myself to integrate new entity-types - maybe made by other people - more easily. To know that there is something like I wanted to build makes it much easier. And your answers will help me implement it very much. 
Hello monkeys,
I’m trying to build a network game, with an entity system.
The network part is heavily based on MonkeyZone… and currently only supports a couple message types linked to login. So the hard part is clearly in front of me XD.
I’m currently thinking about the entity system.
I’ve read the monkey threads about that and read the links you peeps posted. Wonderful read btw.
Sooo, following what you people posted, I’m leaning towards:
- Using HSQLDB for persistance.
- no entity table… just a field in the components table
Now, I’ve checked sploreg’s example code and wondering how would you store such a component in a db (the hp component)?
I’m leaning towards:
- one component table that would only contain an entity id field and a component id field
- a component values tables that would link multiple name/value pairs to their component
- the entity class would contain components that would contain a list of name/values
Also, pspeed was (if I’m not wrong??) speaking about caching at the java level, so was wondering if Hibernate could be used for that or should I program an entity manager myself?
I’m also thinking about how to store templates for building entities versus actual entities?
I mean, I enter a sector… therefore, I need to load the pirates. Pirates would use the Basic Entity Pirate template that would be used to get their components (such as hp, armament etc). An entity system would use one or more of it’s components to determine what model to associate to it.
But:
- wouldn’t it be easier for me if an entity had a name (on top of id), in such scenarios, because an id isn’t too talkative?
- should I differentiate between templates/generated entities/temp entities/players (although players would be generated entities and temp probably don’t need to be stored)?
Also, someone said a sword should be an entity. I guess it means a component of the entity should be linked to that sword entity?
Again, how should I persist that link? Should the components_values tables have an entityId field?
Should my components have a type field (linked to an enum) so I can find the correct component easily? Or is that an awful way?
And last, I’ve read the GOAP stuff and wondering: should goals be components of an entity?
Trying to verify that I’m not going straight for the wall. Although I’m pretty sure we will meet, I would like it not turning into a crash contest :D.
I would love to have your opinions on all this :).
Each component type gets its own table. So if the Hitpoints component only has a numeric value then you end up with a table “Hitpoints” with fields “entity_id” and “hitpoints”.
HSQLDB already caches. In fact, the tables can be create in such a way that they are fully cached… but I don’t recommend it.
An entity name is just another component. An entity type is just another component… though I don’t have an entity type component personally. You can usually tell by the components that it has.
Some entity that is held by another entity can be done with something like a HeldBy component that has the parent entityId as a field.
sword.setComponent( new HeldBy(player) );
3 Likes
You are on mostly the right track. But may I suggest taking a quick stab at an entity system without a database or anything, just use a HashMap, to see how it works. Everyone ends up re-writing their ES at least once, and you don’t want to get bogged down in sql semantics getting in the way of implementing the ES the first time.
A component could have several values, so one column in a general component table might not be enough. You will no doubt need different tables unless you do force each component to have only one value (which I think could make things a little cumbersome, but is an option).
I have two indexes to find my component data so I can run the following queries quickly:
- es.getAllEntitiesWithComponent(DeathComponent.class); // every entity with this component
- es.getComponent(entityId, LocationComponent.class); // that component for the entity
I’m also thinking about how to store templates for building entities versus actual entities?
I mean, I enter a sector… therefore, I need to load the pirates. Pirates would use the Basic Entity Pirate template that would be used to get their components (such as hp, armament etc). An entity system would use one or more of it’s components to determine what model to associate to it.
This really depends how you want to configure your game. I use groovy scripts, so does Paul. Everything for the entity is built in that script in my case (you can of course import a standard template).
My entities have a user-friendly name, used for debugging in the scripts when the entity is created, and for logging in the java code: NameComponent. They still use an integer ID however.
A component should not have a type field, the "type" is the component class.
es.getComponent(entityId, LocationComponent.class); where LocationComponent is essentially the type.
For GOAP, I have many components that build up the whole GOAP AI.
My GOAP components:
* interface GoapAction extends Component // has preconditions and effects
* class AttackActionComponent implements GoapAction // has real data for the action, knows what animation to play
* GoapAISystem: solves the goal for the entity if it has an OrderComponent (given by the player or an overarching AI), produces an action queue
* ActionSystem: goes through each entity's action queue, checks if the current action is done, and if so pops the next one
* Specific action systems: AttackSystem (actions AttackActionComponent)
6 Likes
The other thing is that if you don’t have a table per component then you may have missed one of the key points of the entity system.
1 Like
Thanks ALOT, pspeed and Sploreg for those awesome answers :).
I’m going to re-read them again and again until the images get printed on my cornea.
That was exactly what I needed.
Sorry I can’t post more… I got some re-reading to do :D.
Sorry, I have to dig up this old thread, but I have a few questions about “use controls as systems” and the concept, the systems communicate with the actual engine.
1.) I understand the concept of how the entities are created and managed. But where does the actual “create node, attach model and add to the scenegraph” happen? Is this a system on its own (that handles e.g. the VisualComponent (Only the modelPath in my system)) - Although this would make sense, I don’t get how the other systems like animation-handling would get access to the node (and then to the AnimControl). I would like to seperate the systems entirely, so they only communicate over the components and not like getSystem(VisualSystem).getNode().getWhatever() - This would break the modular concept I think.
2.) Where do I create the systems? At the moment, I check all the entity’s components when adding it to the world and create a system for each one. There has to be a cleaner solution (without if(component instanceof VisualComponent){ … } elseif, elseif, elseif, …)).
3.) I don’t really see, where controls are needed in this concept. If I manage all systems in one place (e.g. the world) and update them properly each frame, then I don’t need controls or? (If I can access the node properly from each system, I still don’t how to do that as described in 1.))
I think, an entitysystem could be really useful but there are a few things in my OOP mind, I have to overthink - I hope, you can help me. 
@destroflyer: Simple code example of a full ES with one control as a system here: http://hub.jmonkeyengine.org/forum/topic/entitymonkey-a-simple-entity-system-for-jme/#post-186678
The control is part of a system, “system” is anything not component or entity So you wrongly separate between “system” and “control”.
@destroflyer said: Sorry, I have to dig up this old thread, but I have a few questions about "use controls as systems" and the concept, the systems communicate with the actual engine.1.) I understand the concept of how the entities are created and managed. But where does the actual “create node, attach model and add to the scenegraph” happen? Is this a system on its own (that handles e.g. the VisualComponent (Only the modelPath in my system)) - Although this would make sense, I don’t get how the other systems like animation-handling would get access to the node (and then to the AnimControl). I would like to seperate the systems entirely, so they only communicate over the components and not like getSystem(VisualSystem).getNode().getWhatever() - This would break the modular concept I think.
2.) Where do I create the systems? At the moment, I check all the entity’s components when adding it to the world and create a system for each one. There has to be a cleaner solution (without if(component instanceof VisualComponent){ … } elseif, elseif, elseif, …)).
3.) I don’t really see, where controls are needed in this concept. If I manage all systems in one place (e.g. the world) and update them properly each frame, then I don’t need controls or? (If I can access the node properly from each system, I still don’t how to do that as described in 1.))
I think, an entitysystem could be really useful but there are a few things in my OOP mind, I have to overthink - I hope, you can help me.
Entities. Components.
Literally, Everything else is a system. It’s either one giant system, or part of a system, or whatever. If you get hung up on this idea of “where’s my system” then you will always go down wrong paths. Especially the idea of automatically creating a system for each component… it’s kind of ridiculous for a few reasons. Some code will write components,
many things will read components, some components are general and used by everything. For example, what “system” would handle the “Name” component? I don’t mean to be insulting by the word “ridiculous”… but when you “get it” you will see that it is.
The idea that the visualization systems will operate independently of one another is also kind of erroneous. They will share spatials, it cannot be otherwise. Spatials are not components. Spatials are not entities. Therefore, an animation system will share data with a “visual” system outside of the entity system. It cannot be otherwise. You gain almost no benefit by trying to shoehorn these things into components but you gain a lot of trouble.
Sometimes it will make sense for controls to use components. For example, the system that sets up the spatial could add some controls to it to manage the other things like animation. It comes down to personal preference at some point. But if you are constantly trying to figure out where one system ends and another begins then everything will be endlessly confusing.
Ok, thanks for your answers. Anyway, I still have a question.
I guess, entities can change their components at runtime. So there has to be an event-like mechanism that is called when a component is added/removed or? (Things like loading another model - I don’t want to add/create all possible systems and check in their update loop if they’re needed or have changed)
At the moment, I only check the components when adding it to the world (and adding a few systems, e.g. controls for movement, animation and so on).
@destroflyer said: Ok, thanks for your answers. :) Anyway, I still have a question. :PI guess, entities can change their components at runtime. So there has to be an event-like mechanism that is called when a component is added/removed or? (Things like loading another model - I don’t want to add/create all possible systems and check in their update loop if they’re needed or have changed)
At the moment, I only check the components when adding it to the world (and adding a few systems, e.g. controls for movement, animation and so on).
Yeah, components can be changed all the time. It’s sort of the whole point. There a couple ways to do this but from the ‘systems’ perspective, it should look like reissuing the query. I’ve written about this a lot already so I won’t rehash it here.
I can say that you do not want to expose change events to your systems. It breaks the ES model.
Ok thanks, I think I understood how systems work that are initialized once and then are updated each frame. (They search for entities with the required components and do their thing)
The last thing remaining would be systems that are used e.g. in controls (=> one individual system for each entity that has the according component) - I’m wondering where to put the .addControl/.removeControl when a special component is added/removed (Creating systems at runtime caused by component changes).
Or is this a bad practice and all systems should already exist at the beginning? (I can’t really imagine that case since Normen used a control as example in his code)
I’m still waiting for the final click in my mind, sorry if I bother you. 
There is some more central thing that will be adding or removing the controls. We are getting so abstract now that it is hard to comment more specifically.
In the example theres one system (the appstate and its controls) that manages all that, the control that is part of that system doesn’t really need to know anything but what the entitys comoponents tell it to. Like the control can detach itself and the spatial it represents when theres no VisualDisplayComponent anymore. So the base system (the appstate) doesn’t even need to store a reference.
The content of this post is meant to be read as a straight information or question without an implicit dismissive stance or interest in having the other party feel offended unless theres emotes that hint otherwise or there’s an increased use of exclamation marks and all-capital words.
As I’m getting closer to implementing a database, I started working on an ES of my own.
The idea is to try to keep the ES disconnected from game core completely.
So far I’ve only implemented one system, the movementsystem, and the core of the ES
seems to run pretty quickly.
I’m using the concept normen wrote an example of earlier. But also some influence from the Artemis system,
where I keep track of added/removed/updated entities. All these entity changes are applied to the systems.
I’m keeping one system only interested in one component, but can operate on other components also.
For example, the movement control relies on the movement component, and only keeps track of a list
of entities which has the movement component. However it also uses PositionComponent in order to
update the position of the component. It can and will not move entities which does not have this attribute.
Furthermore I will keep the game project not interfere with the ES systems, but rather have its own controls.
For example the movement control (NOT system) which is within the game package, will only manage updates
occuring for the entities with the movement component.
In conclusion, my current approach is to have a system where I have these components:
ES: Keeps track of entities and components
ES Systems: Updates components
Game controls: Updates nodes using the ES components
As I havnt thought through all of the game logics, how they will be handled I’m still a bit uncertain
in what degree this is implementable throughout the game, but I will try to use this structure wherever possible.
Its very likely that some ES systems need to be merged with game controls.
One of the reasons I don’t like Artemis is because they have the idea that a “system” is a specific thing. To solve one small problem they throw out half of the flexibility. It’s unfortunate and unnecessary.
In general, I think if an ES has some kind of System interface then it is kind of a broken design.
1 Like
Well define specific, my interface is as specific as a public void tick() call on the most abstract level. What the system then does it its own problem.
@Empire Phoenix said: Well define specific, my interface is as specific as a public void tick() call on the most abstract level. What the system then does it its own problem.
Well, a “system” is “anything that uses the ES”. A Control that uses the entity system every frame is a “system”.
Several off-the-shelf Entity Systems, go with the System.updateSomeEntities(…) approach which is the sledge-hammer approach to solving the query update problem and means you have to jump through hoops to use the ES in many situations where it would otherwise be a natural fit. (For example, displaying players inventory, etc.)
Not to criticize your approach but I wonder why even bother to have a special System interface if all it has is a tick() method on it. Wouldn’t Runnable do the same thing and be just as clear?