Thanks for your time :D/
Sure. It just depends on what you need. It's quite common to run the physics simulation at one rate and the rest of the game (ai, game logic, etc.) at a different rate.
It’s also quite common that it is easier if some system is consistently run after another, in which case running them both from the same thread in the proper order may be best. (For example, Asteroid Panic does everything on the render thread, as I recall. Monkey Trap has one game thread separate from the render thread that runs all of the systems in order.)
What would be the advantage of running them in a specific order, deterministic physics ? less latency between events ?
This is all supposed to be invisible to you and is really just a performance optimization that Zay-ES does internally. Systems grab an EntitySet and can update it when they want a fresh view. They should not worry too much about how this happens as it isn't at all important to the system.
Think of systems like they are running a JDBC query just for the data they are interested in. You don’t really need to worry about how it’s getting you the data other than the results/performance. (Also its similar in that you have a cached view that may not represent current data until you reissue the query.)
I understand that it’s just your implementation but i’m just using it as a research matter to understand the big picture. I don’t plan to duplicate it, just have a basic understanding of it so that i can make my naive and probably inefficient implementation but at least based on the right logic.
For an array of only two or three elements (Entities hardly ever have more than two or three components) this sort of loop can be faster than a hashmap but moreover it's a _way_ smaller footprint. If you ever have more than four component types in an EntitySet then it's worth reexamining the design at least lightly.
Oh i see, thanks.
I'm not sure I understand the question about the trap system or why you would check every second.
Presuming that you even wanted such a system you could just check for an entity’s intersection when it moves instead of checking every second. Even more general, you could have a collision system that generates collision entities for moving objects (an entity created just to link to other entities together with a Collision component or something).
But the TrapSystem is a perfectly acceptable idea. I just don’t understand where the perceived conflict is. The naive implementation would have an EntitySet of traps and an EntitySet of mobs. When a mob moves, check it against the traps… and then do something.
I don’t understand this part, though: “wouldn’t the system process each of the cached positions and end up giving wrong behaviour”
Yeah it might not be the perfect system but i wanted to understand the queue thing, it’s implementation, alright, but it defines game-code as i (mis)-understand it at the moment.
You have a queue of events in your entitysets which i assume are there for thread-safety and/or performances. I assumed that when you applyChanges() you check if there’s a change, and if so, you process the queue.
I thought the queue would be a list of EntityChange each pointing to a component; the first change in the list would be PlayerPosition at 10,20, PlayerPosition at 10,30… and then you would filter this list whenever the system needs those datas.
Hence the fake scenario of having to process cached positions that the TrapSystem wouldn’t care between those 1second ticks…
I’m still in the mist with where the data comes from, it feels like you could load the datas just once and just pass around the components during the game without having to touch the db/map at all. =_=
To me one of the huge benefit of your architecture is that you don’t care about system ordering, which would mean that if a player dies from a spell, even if the DamageSystem says “player dead”, the AnimationSystem maybe didn’t even notice the spell action yet but will process it one or more ticks later and since this system is living in its own world, it doesn’t matter. (or does it ?)
I always had issues with triggers, chained events and just proper design :
Let’s say my player is casting a spell, not from inputs but by validating a certain amount of conditions to happen, and that when that happens, a X animation (not the spell one) is started at the position of the spell. Do you handle the trigger of the X animation in the source System, let’s say DamageSystem is triggering a spell (the real one) when life is under 10, or in the AnimationSystem when noticing that there’s a new Entity added with an AnimationComponent, i guess not the latter otherwise AnimationSystem would have to handle all the cases where something special is happening.
I guess what i’m asking is : would i need to send some kind of “createThisEntity” component and catching it in what sounds like the appropriate system, the AnimationSystem or just create the entity as soon as possible. I kinda used to do the first one but it never ended well.
So i’m following my gut thinking that you should create everything at the source, the spell is casted but this is a chained event so the spell entity actually have a ChainedComponent with a list of spell types that will be chained. The spell did his job and is removed, There’s a ChainedSpellSystem which is looking for ChainedComponent and whenever he sees that an entity having this component is going to be removed, spawn another spell entity looking at the next spell in the ChainedComponent list. and create a new ChainedComponent for the new spell entity with the left spells to process.
It means that this system is basically just handling the case where an entity having a specific component is going to be removed, is it ok ? Is it common to have some kind of filter systems ? It seems almost like the core of it but how fine-grained do you go ?
Let’s say i have an InputSystem which is feeding an inputComponent with appropriate states, now probably in the game, inputs are not doing the same things depending on the situation, so maybe you have a new field “inputMode” in inputComponent or maybe a new component InputModeComponent. So now an inputModeSystem is probably handling inputs as proper orders (could be handled in the InputSystem though), so if i click left in attack inputmode a startAttackComponent will probably be attached to my entity.
Then the AttackSystem will catch the startAttackComponent and depending on my class, level… will spawn the approriate spell entity.
But it could have been handled right from the InputSystem or InputModeSystem and to me it’s hard sometimes to see who should delegate stuff.
I can clearly see an attack passing through several systems. Which would mean that if all the systems are running at the same tickrate, an action would take as many tick time as the number of systems the event is going to pass through. Not a complaint about latency or anything just checking out if i’m right or wrong.
Do you dare handling GUI stuff or more accurately mouse events interaction with GUI & Map and units… in a ES ?
I’m doing an action strategy game and while i used to think it’s good to not make everything ES my whole game is basically mouse interaction with my game so it’s hard to dissociate.
Still in my game, my map is basically a big list with block IDs, i make quite a lot of flood fill so i can’t really make each tile an entity and i don’t think you would have recommended that anyway
But the interface can be tricky, i make a building, it has to be somewhere in my map(list) and in the meantime i need an entity to show it in my game with health and other attributes. The health being actually within an healthmap so there’s some synchronization to do that i’m not always comfortable with but there i have no choice. I might be overthinking this, it may not be that annoying in the end we’ll see.