Ok, so I’ve been rereading the “rules of thumb” for an entity system and I am slightly confused by one of the rules: Never modify the same component from different systems. I’ve been trying to rewrite my systems to apply this rule (because past me didn’t know better apparently) and was unsure of how to take certain usecases.
For example, I have a system called HealthSystem that takes care of setting the health of my entities as well as processing any damage that they take. This system also sets a death component to any entity that reaches the health of 0 or lower.
I also have systems that take care of the entity behaviors (e.g. MonsterBehavior) that, by my original design implementation, could set any types of components as it saw fit (like a death component if the entity reached a certain state). Now obviously this pretty much breaks the rule of only one system should modify a certain type of component, because the behavior system and the health system would be both writing death components. So my question is; how would I go about implementing my systems so that they respect that rule while keeping my game logic decoupled?
In your example my question would be why your health system doesn’t know about other things that apparently influence the health of a character so much that it can die
Right, that’s a good point . I guess the logical answer here would be to separate the death logic into its own separate system. However, what I don’t like about that is that my game logic becomes more scattered. So like, my death system would have to check if an entity contains a health component and if its health is equal or lower then 0, as well as check any changes in its behavioral state. This seems to me like a bad implementation because the more the game logic is spread out the harder it is to maintain and track.
At least that is my reasoning. Am I right to think this way?
Hm… Why don’t you just have the health system check for some component that other systems can add to indicate that they want the character to lose all its health? Anyway, its hard to say exactly what you should do not knowing about the rest of your game.
But in general the “rules” we set up for entity systems are a good way to check back if the whole game logic is still intact. And don’t worry about having to rewrite stuff here and there if you coded yourself into a “dead end” - thats a normal part of coding extensive software (such as games).
Hmm, not sure. Because let’s say the request to drop all of the entities’ health is denied, there would have to be some sort of callback so that the entity knows that the request got denied. And potentially why so that it doesn’t ask again or something. I’ll think about this further and see how it would turn out.
And yes I totally understand that since you don’t know the rest of the game it’s hard to give a more precise answer. I’m not sure what exactly to say other then the game is an mmorpg, so client server based. The server is authoritative.
Yes, well that’s exactly why I’m trying to now respect this rule. Because I’m starting to realize that my game logic was not as organized as I thought. I currently have multiple systems that can assign the same component, so I find that my code is hard to keep track of and its also hard to track down the source of a bug.
The hard thing right now is that I’m trying to have my game logic more maintainable and easier to keep track of and still be the least scattered as possible.
Well effectively your previous way would have decided that it has to be so (that the character is dead) so that component from my example could be imperative - if its there the health system has to let the character die. But anyway, I guess the best way is for you to try and make sense of it - it should all “click” at some point - entity systems can be confusing at times but if you get to that point it all will fall in place and you’ll follow the rules automatically. As pspeed indicated - if something doesn’t make sense in that context you’re not quite there yet. But the ES rules make you come up with the right questions I suppose.
Well in some cases if an entity reaches a certain state in its behavior, it needs to set a component. In this particular case, when the MonsterBehavior can’t find a walkable path to a certain location, it kills itself, thus assigning itself a death component.
Hmm ok yes I get what you are saying about the component being imperative. It could work but not completely sure yet if this is the best way. Like you said, I think its a matter of me trying to make sense of it.
If you need it not to fire any effects then that’s a special damage type.
Edit: or you could even have a special kind of damage type that was effectively “infinite” no matter what the amount is.
Edit 2: and I still don’t buy it… you might want to ‘delete’ the entity in some case but that’s not at all the same as death. So you may need to be more specific to your intent.
Hmm ya, which goes on the same line of thought as normen.
Death isn’t a deletion of the entity (at least not right away). On death, the entity does a few more things such as play a death animation and sound. After a few seconds the entity is then deleted.
Hmmmm I would just place a damage entity at same position of that monster with enough damage point/whatever to let that monster die by your healt system.
I just picture this creature going down the wrong path… then…
“Hmm… I seem to be lost.”
Grabs chest. “Erk!”
“Tell… my mother…”
Collapses to the ground like a rag doll with a thump as dust plumes around him.
Then slowly his body fades to the lootable corpse model that now has his skin, 3 gold pieces, and a flawless garnet.
I would not involve damage entity with its own position component in this case at all. Just whatever system controls if the creature is lost assigns proper damage component to that creature… which is then processed in health system accordingly…
Just being pedantic, but this would really be attaching a damage entity to the creature.
An entity may acquire damage from lots of places during a ‘frame’ and so damage should be modeled as separate entities attached to the target of the damage.
This made me laugh . Its true that it sounds a bit out there for an entity to kill itself when he only can’t find a path somewhere but its what I made him do.
I also agree. And the more I think about it, the more I think that simply giving the entity infinite damage and letting my health system kill it is the most viable solution.
Thank you all for the suggestions and the enlightenment on the subject.
. I guess the logical answer here would be to separate the death logic into its own separate system. However, what I don’t like about that is that my game logic becomes more scattered. So like, my death system would have to check if an entity contains a health component and if its health is equal or lower then 0, as well as check any changes in its behavioral state. This seems to me like a bad implementation because the more the game logic is spread out the harder it is to maintain and track.
. Its true that it sounds a bit out there for an entity to kill itself when he only can’t find a path somewhere but its what I made him do.