Danny Day -- Dynamic Event-Listener in Desktop Dungeons
Danny Day is a developer on Desktop Dungeons, a "roguelite". They went through a long open access period while tuning the game, and made a lot of changes. While the code was initially polymorphic (based on inheritance), they noticed that game aspects like "gods" were spread throughout the code and very hard to change... but they were making a lot of changes.
They rebuilt using a dynamic event-handler method. All state change was moved to event handlers. For example, the game has events for PlayerThrowItem, QuaffPotion, or BeginLevitatingEvent which have handlers that implement the results of these actions (or in some cases, blocked or altered them.) God code became separate modules that listened for the appropriate events.
The system is "dynamic" because they can add new handlers on the fly to mediate input. Their UI events go through the same system, so after the user picks a spell, a new handler for the Click event can be used to accept targeting of the spell. When an enemy is damaged, they add a temporary EnemyRegenHandler to restore its hit points (rather than iterating over all enemies just to see if they're damaged.)
UI handlers (to show results) typically needed info from other events, so they were prioritized last in the chain of handlers reacting to events. Danny also talked about other prioritization mechanisms, or the ability to add events at the end of the queue so they were handled int he right order. UI was the biggest problem; they only had a singleton game state that was displayed on the UI. Having more than one game state would make it easier for them to "simulated" events on an alternate game state, in order to show the user the outcome of a choice they are considering. (The game shows not just the effects of the next attack, but also tick marks for the attack after that, etc., which is complicated to compute but simple if you could just run the same code.)
The event system was used for saved games too. Saved games were just a list of all the events to receive treasures, improve a building, etc. so they could just be replayed. Events no longer relevant were just skipped.
The event system didn't really cause performance problems; they typically have only about 50 events and about 20-30 handlers per event at worst. It might not work for everybody but it worked well for them.
Replays: just save the events! Then you can rerun the exact sequence to reproduce a bug or show a player their game.
Reversibility: could make events invertible, but probably better just to keep a stack of game events. You could checkpoint and keep the last N events if replaying everything is too expensive.
Keep game state separate from UI! This system allowed them to do "massive" gameplay changes with little code churn.
Thomas Biskup -- Entity-Component-System in Ultimate ADOM
Thomas, who was a sponsor for the event. He's the author of Ancient Domains of Mystery (ADOM) and is busy working on a new version, called Ultimate ADOM, which he demoed on Saturday. This talk was about some of the technology behind it.
The development team chose not to go with a "pure" entity-component-system model , but instead put some data directly in entities, and some simple behavior directly in components. Systems are reserved for complex and reusable behavior. Thomas felt this provided better modularization than a pure ECS model. (ECS was described in Bob Nystrom's talk on Saturday.)
Why ECS? Thomas really wanted a data-driven design, which allowed modding and easy content creation. ECS improved developer productivity, and provided a clean architecture for complex games. It permits a combinatorical explosion of possibilities for behavior through the addition of different components into an entity, leading to "emergent gameplay."
The Ultimate ADOM UI is purely event-driven and does not have access to the components at all! All information that needs to be shown on the UI is sent to it via a "signal layer."
The ECS model was also extended with
- "entity templates" (including multiple inheritance) to provide class-like behavior
- "flyweight pattern" for efficiency; each entity refers to its templates instead of copying all the components; only store the ones that have changed
- "is-a" and "made-of" relations using a mechanism called "slots"
- run-time type extensions, for example walls becoming beings when enchanted
The "slots" define categories, instead of being treated as a component. A slot is its own entity like "dwarf" or "warrior" or "iron", and the entities that have is-a or made-of relations reference those "slots".
Thomas showed a lot of JSON definitions and some code fragments as examples. The interaction with entities is actually event-based! The code queries to an entity "can you accept event X" and if one (or more?) of its components can do so, then send the event. Some of the event handlers can even be written in the JSON definition of the component.
Thoughts
These talks were interesting from a software-architecture point of view but I felt like I didn't get a clear picture of how the systems actually resolved the hard problems that arise.
In event-based systems, when you want to be able to interrupt or modify an event, handler order becomes very important. But that takes away from the clean abstraction of "broadcast the event and everybody who wants it can listen." How does such a system scale? Dan mentioned that in one case they had to split a handler into two different priority levels.
A similar problem occurs in the ECS-like system described, with combinatorial mixtures of components when the components may have the same or conflicting behavior. If a sword has both a "fire" and an "ice" effect/component, which wins? Is it always the same one? Policy rules and intent-based systems have to deal with this sort of inconsistency too, and I haven't seen an architecture I really believe in for how to design around conflicting rules or components or event-handlers, other than building sort of "meta-protocols" in which everything has a set order and priority.