I am pretty impressed by the advantages of an entity component system such as Zay-ES and I really enjoy working with it now. However, I came across a (little) problem. How do you handle entities or components which have visual dependencies? I mean, the basic idea of ECS is to separate game logic and visualization. But there might be cases where things depend on “visualization”.
Example 1:
A pathfinding control for an enemy using NavMesh. Sometimes you want your enemies find their way through the game world but when it comes to things like pathfinding where you need something like a NavMesh it becomes difficult to integrate this in an ECS, or not?
Example 2:
Imagine a player with skeleton and animations who can equip items like a sword to his hand. In this case the animations of the player would modify the Transform component of the sword entity. Here you also depend on visual components.
I would handle pathfinding this way:
You have a world model like a terrain this belongs to the view. At the beginning of the game I would create a NavMesh based on this terrain. This belongs to the ai. If the enemy needs to follow a path the ai computes the best one (no need to use an ES here) and then only sets a target location as component. This is a point on the path. Now you have a system which takes the position of the enemy and the target point and computes the next step of the enemy. This is the new position (spatial location). Now the view takes this location and moves the spatial. I guess you are trying to use an ES to often. The ai is a system which has other datastructures which are way more appropriated. This special structures shouldn’t be replaced by the ES because they are only interesting for your ai and not for the whole game.
Regarding the sword:
I would add an EquippedByComponent. This component points to the player. Then the view looks for the bones of the arm and changes the transform to fit with the arm. If I understand you right you want to set the transform afterwards on the entity so that the other system knows where the sword is. The only possibility I see here is to set it from the view but I ask myself why you would need it? Is it important for the game state to know where exactly the sword is? I doubt it. It is important to know that the player has a sword armed, the enemy is near enough, the player looks at the enemy and the player is moving the sword. Then I know he will hit the enemy. No need to know the exact position if you don’t make a very realistic game. Prove me wrong if you have another opinion.
I think you should not try to find the one way. Look at each case individually. This makes things much simpler. Do you have more examples?
Hi Jan, thanks for your quick and informative answer!
This is a pretty smart approach in my opinion. Thanks, I am starting to see what should be handled by ES and what is the task of the system.
No, actually not. So I would basically just “override” the spatials location with my “EquipmentSystem”. I am using this approach for something different already. I’ll transfer it for this as well!
Hmmm… No, sorry. That were the only two which came into my mind.
Yeah, for the navigation you basically just need a system that looks for “IWantToGoThereComponents” and puts in “ThatsTheWayThenComponents”. For the sword position you seem to have some things backward. As Jan said, the system that decides the sword is in the hand doesn’t really have to deal with the actual position, that should be another system I suppose.
Two helpful things to help deciding whether you want x as components or not:
A) is it always the same, no matter if the game is displayed in maxed 4k, mobile Phone and even the ASCII Terminal? Then its really a game object
B) should its value be constantly synced with the server?
The latter could be both for AI but most probably you dont want that, you only send the transform changes since you dont have a deterministic ai anyway
Hmmm as far I know in multiplayer online game only the server sends you entity updates not the other way around. That leads me to the question of how do you hold that nav mesh thing on the server, sounds like a visual thing to me?! As well I think AI should be on the server not on the client. But maybe I wrong…
Yes AI should be on the server but you could run it locally as bad interpolation.
The Server also has to know the map at least for colission and the navmesh can be generated from the collissionshape.
It is in this case a logical thing. And the client sends Input.
However this thinking also applies to Singleplayers. If you dont have to Share Data inbetween Systems you dont Really Need an entitysystem
It all depends on the scale of things actually. I mean you might want to give your players ability to design their own units look and behavior by providing their own meshes, paths, even AI algorithms, why not. But all this will have one restriction - this virtually can’t be done in “real time” for the whole game world, just due to transmission load and bunch of latencies here and there. So, for this, you’ll have to implement some “exchange session”-based mechanism that will define how all this client-generated data will be uploaded, processed and then broadcasted. So this is something not to be done via ES normally. However, there’s also a possibility to update clients (hardly server, but clients) “on-the-fly”, like new model downloads to the client only if it has possibility to become visible to this player. This doesn’t look like an easy-to-implement task, but formally, if clever and carefully designed, is possible… not in real “real time”, but close enough to that to look transparent to the player. You’ll have to make lots of assumptions, and higher requirements to players’ connections though.
It’s really similar to the way Mythruna deals with terrain and custom blueprints, etc… these are not “ES” things. The terrain is just flat out not covered by the entity system at all. There is no “terrain entity”.
The blueprints do have an entity associated with them but the block data itself is stored in a separate database. So the world knows that the “chair” entity is here and it has blueprint 125136. The client asks the blueprint database for the block data so that it can create the mesh for it. That part is separate from the ES.
The game logic doesn’t particularly care about the block data for the chair… and if it did then it would go to the blueprint database for it. (Edit: note that this is exactly what the physics collision system does to check block-accurate collisions with objects.)
If your game requires this kind of dynamic content then it needs to design for it. It can’t just be slapped on after the fact. It has to be built that way from the ground up and it will infect every decision.
