I have done a bit of reading on the topic, including two projects here. I get the general idea of how the system itself works, but I’m not sure what is the best practice to link it with rest of the application.
My main question is how should the application-level rendering objects be linked with entities. It seems to me that I will anyway need to create some kind of class like ‘Monster’ which will be aware of the both enitity and rendering details and bridge updates from entities to 3d models. But this gets bit ugly - I will, for example, have ‘position’ in entity. But when position changes, I actually want monster to walk to there, using proper animations. So probably, instead of coming from entity itself, there will be some kind of WalkTo cinematic/action which gets distributed across network, which will have side effect to updating the Location component…
But then, I want to have static components which can be positioned in the world. They still can be animated, but will lack some other components monsters have. Should I reuse same ‘Monster’ handler to translate these components into 3d world, just being dynamic dependent on what aspects entity has or doesn’t have?
But then I have spell effects, which are generally transient, but can travel… and possibly can stay in the world for a long time. Again, perfect fit for same entity system and some reuse of my visualisation code.
If I add all these things together, it seems that I will end up with very nice and modular entity system and a monstrous ‘Monster’ class, which will try to convert all possible combination of components into visual representation, listen to all the changes to update correct things, etc etc. I will avoid having a all-encompassing ‘Model’ class (as in MVC), but end up with huge, expotentially complicated ‘View’.
Any hints here? Do you have some kind of simplified class hierarchy for world objects on top of Entity system (Mob, Tree, QuestMarker, ZoneTransition, whatever) and just be happy that things are flexible within their own supertypes, or are you trying to get a true unification with completely generic renderer on top of entity?
I didn’t even get all the way through and I see you are getting ahead of yourself.
Changing position and walking may or may not be the same thing. Animation and walking may or may not be the same thing. The truth is, you have several aspects here.
-movement
-position
-animation
…each are probably their own component but it depends on how you implement movement. For example, a physics engine might take position, mass properties, and some set of forces and apply them to change the position. In the mean time, the entity also has an animation component that tells the animation system which animation to play. Meanwhile, the node has a control that adjusts the node’s position based on the entity’s position. (Though personally I prefer to let a parent node manage all of the entity children… but it kind of depends on how many mobs you will have.)
If you are thinking “MVC” or “class hierarchy” then you are probably already thinking wrong. No where in your system will you ever have a “Monster” class. A Monster is just an entity with a bunch of components on it. The components define what it is.
I understand that I won’t have ‘Monster’ as a class representing properties. But I need something which will keep the handle to root node of the monster spatials and map entity to all the 3d children nodes for resolution/collision purposes. Let’s call it ‘VisualEntity’. It is not a entity component - it is something which is aware of root scenegraph node, asset manager etc.
And regarding MVC - I think that that entity system is MVC, just with many-to-many relationship and non-OO, component-based model. All the things you have mentioned above listening to changes are kind of ‘views’ of particular component, with physics part being also possibly a controller. But thats just the vocabulary, let’s not make the issue out of that.
I can image ‘Health’ visualtion as a bar over the model being quite independent of everything else (and that it will appear over the stone or tree as soon as I put ‘Health’ on it). But this has to be added to certain position in model, in billboard node (which might be shared with other, billboard-like properties like name). So there has to be a class which manages the existence of billboard node for the model, attaches detaches special effects from it, handles animations (they have to be blended from separate subsystems like walk, fight etc), knows how to react to ray picking to propagate resolution further, etc, etc - VisualEntity I have mentioned earlier.
And my question is - do you propose to have a single VisualEntity for everything in the game, be it player, monster, house, bag of loot, skybox, river, terrain patch, HUD? Or do you suggest some kind of split - Players, Monsters, Houses and Bags of loot go into one, skybox has it’s own handling, river and terrain patches another and HUD yet another? And I end up with having something like InteractiveObjectInTheWorldVisualEntity, SkyboxVisualEntity, TerrainVisualEntity and HUD? These VisualEntities are NOT Entities/Components from entity system - they are translations from ‘business entity’ world into jme3 nodes and spatials.
You completely misunderstand it. Lets look at it another way round: Why do you want to use an ES? If you don’t see how you can communicate to the existing code then that already shows your misconception of the whole ES as data storage and communication is basically solely what its about. If you think in terms of MVC just use jME Controls, they work fine in that context and the code layout you get when using Controls and AppStates should easily transfer to an ES if you get to that some point.
I want to use ES because I don’t want to handle every ‘business’ aspect of the object in the world in same class. I want to have ‘combat’ component, which will be used in combat resolution without involving anything else unrelated. I want to have ‘movement capabilities’ component, which will be used in movement planning mode, giving distance you can move in single turn and possibly terrain modifiers. Etc etc. I don’t want to have a class called ‘Monster’ which contains all these things explicitly, I want them to be kind of ‘aspects’ of the object, which can be queried and maintained independent from each other.
Sounds like ES to me - and I think that I GET this part of ES.
What I don’t get is how to tie ES with core visual part of the system. Not the optional parts (like movement planning, which is perfectly modular to other parts), but the most core ‘this is the node in jme3 scenegraph’.
Can you tell me what is the route between ES and jme3 mesh in your system? There is a new entity in the world spawned, with 10 components in it. You need to show the item in rendering. Do you just have one component which handles details about visual layer (model name, texture override, etc)? Is it the same type of component regardless of ‘type’ of object, or you have different ones to represent monsters and doors?
That s not a es,
a combat componet does not exist, its way more atomic,
eg a health component, a position component, a rotation component. Now the animation could be done by having a rplicated entity set on the client, that uses the difference in position to play the proper walk/run/jump animations.
My usual approach for mapping is a hashmap that maps the id to the node in the system (so to not bloat other stuff) The system then has a model component that in turn references in the end the modelfile. If new entity added or modelid changed, update spatial, update always rotation translation.
Now my models are categoriezed, eg i know if a model represents something bipedal, and always have the same animations there that in turn aare choosen by transform changes. For normal movement this works beliveable (note not everyone will see it 100% identicall, but always believable and the difference is very minimal)
@abies said:
I understand that I won't have 'Monster' as a class representing properties. But I need something which will keep the handle to root node of the monster spatials and map entity to all the 3d children nodes for resolution/collision purposes. Let's call it 'VisualEntity'. It is not a entity component - it is something which is aware of root scenegraph node, asset manager etc.
And regarding MVC - I think that that entity system is MVC, just with many-to-many relationship and non-OO, component-based model. All the things you have mentioned above listening to changes are kind of ‘views’ of particular component, with physics part being also possibly a controller. But thats just the vocabulary, let’s not make the issue out of that.
I can image ‘Health’ visualtion as a bar over the model being quite independent of everything else (and that it will appear over the stone or tree as soon as I put ‘Health’ on it). But this has to be added to certain position in model, in billboard node (which might be shared with other, billboard-like properties like name). So there has to be a class which manages the existence of billboard node for the model, attaches detaches special effects from it, handles animations (they have to be blended from separate subsystems like walk, fight etc), knows how to react to ray picking to propagate resolution further, etc, etc - VisualEntity I have mentioned earlier.
And my question is - do you propose to have a single VisualEntity for everything in the game, be it player, monster, house, bag of loot, skybox, river, terrain patch, HUD? Or do you suggest some kind of split - Players, Monsters, Houses and Bags of loot go into one, skybox has it’s own handling, river and terrain patches another and HUD yet another? And I end up with having something like InteractiveObjectInTheWorldVisualEntity, SkyboxVisualEntity, TerrainVisualEntity and HUD? These VisualEntities are NOT Entities/Components from entity system - they are translations from ‘business entity’ world into jme3 nodes and spatials.
Just because it “kind of looks like MVC if you squint your eyes right” does not make it MVC. MVC typically has events. It has a specific view. ES does not have events, does not have a specific view. It has a loose idea of “systems” which might be views. But you already try to limit your understanding by basically saying “Here is a whole paragraph about how I misunderstand things still but ignore that…” If you keep trying to make an ES look like other things that it isn’t you will stunt your growth.
A monster, a bag of loot, etc. can all be represented by the same “thing” in JME. They are all spatials. They were probably loaded as models from the asset manager. In the most naive implementation you could have some kind of AssetName component. Then you have a control or an app state that iterates over all entities with an AssetName and a Position component. If it hasn’t seen it before then it loads the asset and places it. Otherwise, it moves the spatial to the latest position. My ES makes this easy because you can reissue the query and it will tell you what has changed from one frame to the next.
You might have another component (again in the most simple implementation) AnimationName. Every frame you query the entities with an AnimationName and start that animation playing for that spatial. If the AnimationName component disappears then you stop playing the animation.
You don’t have to do skyboxes and stuff as entities… though you can. The scene is the world and not necessarily an entity… but the container for the entities. Your app can set that up specifically for the entities to play in. With the components above, you basically have everything you need to implement 90% of the scene graph parts of a game. The rest is the systems that manipulate those components… but the visuals are basically done.
Thank you Empire, thats the kind of detail I was asking for (and regarding Combat component - it really depends on game, I was just giving an example; if I’m implementing HeroQuest which just has attack and defense stats, probably it is good enough granularity, with Health being other matching component).
I would like to go more into ‘RenderSystem&Animation System’ and ‘my models are categorized’ parts. Let’s take monster and door example. Both are objects in the world. Both have animations, even if different ones. They will have very different user interaction modes. Is you entire system completely agnostic of difference between monster and door as far as rendering is concerned? Are you categorizing models purely on their animation sets, or is there some extra logic which makes a difference between monster and door, outside of ES? If I add door-related components (whatever they might be - KeyLockable, MovementBlocker, etc) to your monster entity out of the blue (and assuming that for kicks, it has ‘open’ animation) will player be able to just come to it and ‘open’ it with a key?
I suggest you simply regard it as a database as that is the part of the ES you seem to have understood and want to use. Components and how they are used (as well as the ES rules list that we posted) in itself answer some of your questions already so if you want to solve them else you are just using a database and don’t need to call it an ES. I think that will be more appropriate for you. Note nothing much changes except you don’t confuse yourself and others with the mixed in ES terminology.
@normen said:
I suggest you simply regard it as a database as that is the part of the ES you seem to have understood and want to use. Components and how they are used (as well as the ES rules list that we posted) in itself answer some of your questions already so if you want to solve them else you are just using a database and don't need to call it an ES. I think that will be more appropriate for you. Note nothing much changes except you don't confuse yourself and others with the mixed in ES terminology.
Yes, but I would like to understand how you use it - think about it as a personal growth project on top of everything else.
Do you really have a system where anything can have arbitrary mix of components and will be rendered/interacted with (ui-wise) properly?
@abies said:
Yes, but I would like to understand how you use it - think about it as a personal growth project on top of everything else.
Do you really have a system where anything can have arbitrary mix of components and will be rendered/interacted with (ui-wise) properly?
I thought you said you had read the threads on it… In almost all I link the base example as well as the list of “rules”. Heres an unfinished game I started some time ago that where I extracted that barebones ES example code from: Dropbox - PowerMonkey.zip - Simplify your life
Edit: Also its not a good idea to try and disprove experts on the matter if its really about learning this.
@normen said:
I thought you said you had read the threads on it.. In almost all I link the base example as well as the list of "rules". Heres an unfinished game I started some time ago that where I extracted that barebones ES example code from: https://www.dropbox.com/s/7ywpto8cghmzboj/PowerMonkey.zip
Well, I have read _newest_ threads on that and some things on the net - but I have missed that one. Thanks for the pointer, this should give me something to mull over.
Update on my self-education project about understanding ES. Main problem I had with understanding what you all meant was that I was too focused on ‘Entity’ part of the equation and somehow have skipped over the ‘System’ part. I was reading about the combat system, movement system etc and I was visualizing them as variations of what I have currently, just accessing different data structures, rather than the core of the processing.
To rephrase my original question - from PowerMonkey example, I was asking about something which is implemented as ‘EntityControl’ there. It is being triggers out of the rendering loop, rather than entity processing loop and it is accessing few components of the entity for needs of visualisation (in this example VisualRepComponent, PositionComponent and MovementComponent, which as result also affects animations). This is the simple example and I was wondering if this class would not grow to be too complicated in real world usage.
From what I understood after rereading your answers, way to avoid complication is to communicate with that visual interface (it is called EntityControl in PowerMonkey example, I was calling it VisualEntity for extra confusion) in low-level data - (position, animation, base graphical effects), rather than game-logic data (being wounded, traversing path, attacking enemy). To achieve that, I should use various systems which are working on small set of component types each, updating few other components in the process. In some way (and I will probably get slapped again for making bad analogies) it reminds me a bit of expert system working with rules and events, but instead of transient events, we have persistent component data.
Am I on right track or have I misunderstood something basic again?
Kind of. It’s definitely closer. Though I would still caution you that trying to fit it into “looking like something else” is going to hurt you more than help you. Just accept that it is a different pattern and try to learn it without being saddled with trying to make it fit a different pattern.
In the T-systems articles (where the comment threads were more important than the articles actually) the thing that really made it clear for me was the thought that an entity system could be a bunch of separate server processes iterating over database tables. A process would just pull in the tables and records it needed to do its job and it wouldn’t so much worry about what the other processes were doing. In its next update loop it would see new data and operate on that… regardless of where it came from.
Regarding the implementation detail that my ES has some events, it is an unfortunate issue that it is easier for certain types of networked server code to watch the whole ES in this way. It allows the server code to be more generic and not require that a networked version of every system get implemented. So on the server, I can watch for all entity changes and then forward them to the relevant clients based on other factors. The pure side of an ES does not have events.
Doesn’t that mean iterating over every record over and over on each update (where update loop can be independent for each system, possibly considerably throttled), even if there is nothing to do? I suppose it might be not a big problem for games, because generally you will have things to do and reevaluate constantly, plus you probably anyway want to have power capacity for worst case scenario.
I’m coming from business where concepts are bit similar - multiple aspects of single entity, updated separately from each other by independent processes and shared between processes/machines - but due to capacity/time demands it all has to work on events/notifications about changes, to avoid constant reevaluation. Seems that current implementations of ES are a lot more tailored to areas where ticking time is major influence factor (which games are).
Regarding events - let’s forget about notification-about event change events at the moment (this is just implementation detail, which indeed is non-critical). I’m now wondering about game-logic type of events - message passing. It could be achieved in ES by attaching some component (let’s say WallHit, with extra paramters for speed/ram damage/whatever), which will then play ‘ouch’ sound somewhere, start ‘bang head’ animation somewhere else and stop movement in yet another place (and maybe deal damage to player/wall). All that maybe not directly, but by spawning other updates. At this moment WallHit would get removed, as it has done it’s job. With that approach, WallHit is not really a ‘true’ persistent component - it is kind of message (or event, but this word is overloaded), disguised as component.
Is passing such ‘messages’ common practice in ES?
If yes, isn’t it slightly arbitrary to decide which system actually removes that component after it is seen by everybody? How to make sure it was already seen by everybody interested? Won’t it end up with having separate component type targeting each system, to avoid ownership problem?
@abies said:
Doesn't that mean iterating over every record over and over on each update (where update loop can be independent for each system, possibly considerably throttled), even if there is nothing to do? I suppose it might be not a big problem for games, because generally you will have things to do and reevaluate constantly, plus you probably anyway want to have power capacity for worst case scenario.
It’s a conceptual way of looking at it. There are ways to make it perform well and that’s an implementation detail. But thinking of it in this way will prevent you from making mistakes like later in your post.
@abies said:
I'm coming from business where concepts are bit similar - multiple aspects of single entity, updated separately from each other by independent processes and shared between processes/machines - but due to capacity/time demands it all has to work on events/notifications about changes, to avoid constant reevaluation. Seems that current implementations of ES are a lot more tailored to areas where ticking time is major influence factor (which games are).
Regarding events - let’s forget about notification-about event change events at the moment (this is just implementation detail, which indeed is non-critical). I’m now wondering about game-logic type of events - message passing. It could be achieved in ES by attaching some component (let’s say WallHit, with extra paramters for speed/ram damage/whatever), which will then play ‘ouch’ sound somewhere, start ‘bang head’ animation somewhere else and stop movement in yet another place (and maybe deal damage to player/wall). All that maybe not directly, but by spawning other updates. At this moment WallHit would get removed, as it has done it’s job. With that approach, WallHit is not really a ‘true’ persistent component - it is kind of message (or event, but this word is overloaded), disguised as component.
Is passing such ‘messages’ common practice in ES?
If yes, isn’t it slightly arbitrary to decide which system actually removes that component after it is seen by everybody? How to make sure it was already seen by everybody interested? Won’t it end up with having separate component type targeting each system, to avoid ownership problem?
“Passing messages” is another form of event and is anti-ES. You are still thinking of it as something else. “WallHit” is not a component… and it definitely wouldn’t have all of those things in it since they are probably separate components/entities on their own. WallHit might be an entity. More likely that the thing isn’t even needed as it’s way too specific. The physics engine might kick out a bunch Contacts attached to the player. Some other systems might do something with that… apply a damage entity, run some animation, make a sound… etc… The physics system produces data and other systems operate on that data. In this case, the physics system probably removes the contacts again later.
While you are grasping to call an ES other things, you might say that it’s still message passing but it will hurt your growth to think of it that way. One system produces data output. Other systems may use that data to do stuff. If you loosen the definition of message passing to cover this case then all programming is message passing and the pattern name is meaningless.
Also, components don’t have to be persistent. I used the database as an example. Whether they are persistent or not makes no difference to the users of the ES. But it’s useful to think of them that way from a wrapping your head around an ES perspective. The ES is just a database… whether all in memory or not. You iterate over it periodically to do stuff in systems.
I have read your idea about damage resistance in one of other threads. Something was producing damage with the type, other system was reducing this damage based on resistance and another system finally interpreting result further. Now, after reading it again, I have noticed my misunderstanding - you proposed creating damage entities, rather than attaching damage components to the entity.
So, let’s stay on this Damage entity example if WallHit is not good. Same story - we want ‘ouch’ sound for getting hit, stop current action because of being distracted and finally reduce current hp. I create that damage entity and broadcast it to the ‘bus’. Every system interested in the component it happens to carry (let’s say Damage) can perform it’s action. How do I know that every system had chance to see it and entity can be deleted? (or probably, in ES-speech, Damage component removed from it and as it is the last one, it virtually stops to exist). And how do I know that I have already produced ‘ouch’ sound for that particular damage if it stays there for longer time?
And now assuming that we want to add damage resistance system on top of that - I understand that instead of adding Damage type to that entity in first step, I would add UnresistedDamage, then resistance system would process it, removing it and adding normal Damage and rest of the system would run without any code changes?
We don’t broadcast things to the bus. No more than saving data in a database is broadcasting things to a bus. We produce state. Other things see that state if they care. This game grows tiresome.
If your systems don’t poll the data often enough to see the changes then they don’t really care about seeing all of the changes. You can interleave them and let everyone get a chance at the latest state or if you are on separate threads you can leave this sort of transient state around long enough (two frames maybe) for everyone who cares to have seen it.
But if you keep insisting on making an ES look like other things you will limit your understanding. So I start to sound like a broken record and I will let others help you now because I don’t need the frustration of repeating myself 50 times.