tonihele
commented
6 years ago That would certainly be a better way to go. I'm indeed a little bit struggling to decide how to pass this data. On the other hand I want to mask the ECS design with listeners/events, but on the other hand why? ECS system we are currently using offers quite a handy way of setting up a change listener to any class that wants to do so. But also this comes with the downside that they need to be added to game logic to be updated. There might be duplicate type of listeners, I'm unsure how heavy overhead this causes, in general should be very little.
And I think only a handful of these events we actually need to propagate to the client. I was thinking that the client can also most of the time leverage the ECS directly. Like the creature card UI component, just hook on to ECS like the general rendering stuff I already have for the entities. So many of the events we currently have, we wouldn't need anymore.
The map tiles an such, rooms and what not. Player data (Keeper.java) I was thinking that they should be also of the type RemoteObject (not related to ECS, but the SimEthreal I think). We would then be free of those events as well. As they would have similar way of subscribing to the entity changes.
In a way, the EventManager in the link is what we already do with our ECS when we create those filters.
But yes, I have no clear plan on this. Now I've been doing both. Mostly going with creating those ECS listeners where ever needed.
ArchDemons
I think we need to add an event manager. It will receive events from various components of the game and send them to listeners. For example, the OnTileChangeEvent (x, y). And the listener will determine how to process it. And then we have a real horror with the event Creatures.onSpawn, Creatures.onDie, Creature.onStateChange.
I have already made some prototype. But I'm waiting for the merger with the feature-263 branch.
Some interesting link https://tsprojectsblog.wordpress.com/portfolio/entity-component-system/