Roguelike Celebration: Desktop Dungeon and ADOM architectures

in roguelikecel •  6 years ago  (edited)

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.

20181007_111543_HDR.jpg

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.

20181007_112111.jpg

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.

20181007_113549.jpg

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.)

20181007_115455_HDR.jpg

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.

Authors get paid when people like you upvote their post.
If you enjoyed what you read here, create your account today and start earning FREE STEEM!
Sort Order:  

I somehow understood some of the technicalities but I am not really the techie nerd. I wonder who were in the audience of the event? Are those system architects or developers to? Or are they plain gamers? I actually wonder who is the target audience of the games. Are those for adults and something is at stake as prize when someone wins?

The attendence at Roguelike Celebration is heavily slanted towards game developers, and many of the talks are oriented that way. But there is a healthy number of people like me who are just fans of roguelike games, and a few people who were just invited by their friends.

The games do not typically have any prize associated with them (though one of the developers did run a small tournament during the conference!) Roguelikes are still something of a niche market, but some developers are able to make a living from it, and many mainstream games have incorporated roguelike elements.

Many computer shops here in our country are operating just for those Roguelike games. Many children, including students, got addicted to the games up to the point that they cut classes in school just to play. That lead to authorities warning the computer shops not to allow students to play during school days and those who are still wearing their school uniforms.

I never played these games so I wonder what is so addictive with it?

Hi markgritter,

This post has been upvoted by the Curie community curation project and associated vote trail as exceptional content (human curated and reviewed). Have a great day :)

Visit curiesteem.com or join the Curie Discord community to learn more.

It is a nice presentation and that is good to get together and present the works. From my experience such presentation is one-way mostly, the observer are passive participants. I like more interaction, for such event, I prefer a gathering like workshops, so people interact, they still present but chat and stop and discuss then the ideas can be discussed in details and the decision for some changes done. I found it always more effective of course if the number of participants too large then it is not possible, but if not then this is the best and very productive :)

This was a fairly small conference (I'd guess about 150 people at most?) and there was plenty of time for informal discussion as well as the "formal" presentations. We had lunch on-site, frequent breaks, a Saturday evening dinner and arcade. So the audience had plenty of time to interact with the speakers and exchange ideas, not just listen to the talks.