During Coffee Break last week, I demonstrated an aspect of a programme I have been writing for Dungeon Masters. This programme will allow a group of DMs to build a world together, which is stored on an SQL Server.
Imagine a ttrpg; we have the Master and the Players; sometimes this is division aided by the presence of a screen or divider. But, away from the actual session, isn’t the Dungeon Master is playing another game in themselves? For each Master, they play a different game; what we call ‘DM’s prep.’ We could say the type of game the Master plays has some relationship to the level of indeterminancy the Master is comfortable going into the session with.
However, there is something isolating about this solitaire.
Obviously, the Master cannot share too much information with the players. Indeed, it is in the Master’s best interest to present a particular, even blinkered, version of their world to suit the player-characters’. From my experience, opening up the backstage to the players is good; but even when it is done, players want it to be done in a gameful way and with the main responsibility still with the Master. At the end of the day, the work of the DM and the PC’s is different and that makes them different classes at the table.
This construction of the DM as an isolated creative is not entirely true either; when I began to put this programme together, I was inspired to play with the ‘stolen’ nature of Dungeon Master’s content. The most common advise peddled by veteran masters online is “steal, steal, steal.” Indeed, Dungeon Masters share, and steal, now more than ever before. But whilst some types of resource (like /r/dndmaps or /r/unearthedarcana) are easily shared, other aspects of the session are not.
What my programme (“Excel DM”) does instead is network together Dungeon Masters and their common text descriptions into a simple, standardised User Interface.
The aim is a ultimately a teleprompt, or hyperprompt, navigated by means of a map, that offers the Dungeon Master during a session the ability to have a structured and considered description to create a scene, and bring their players into that moment in a way that readily offers them agency. This prompt can be anywhere between an actual script written out by the Dungeon Master ahead of time and accessed when needed; or, as I will show below, an entirely ‘borrowed’ sequence of descriptions taken from common entries.
The important thing to underscore is that this is not intended to be a game for players; this is a game for Dungeon Masters.
Currently, different User-DMs share a common server. This is organised of Global/Local/Dungeon scales. Each Global cell contains local cells equal to the square of the number of global cells, and each dungeon cell equals the square of the number of local cells or the number of global cells cubed. It is within this structure that Dungeon Masters create their descriptive objects. I have chosen taverns as the example because they are a strong motif of ttrpgs, but as you will see the system works for any scale of objects. At the global, cities, towns and villages; at the dungeon level, statues, chests and wall bas-reliefs.
The lack of graphical sophistication is a deliberate design choice, since I believe the Dungeon Master is at their best as an oral storyteller. Other softwares iritate me when they push too strongly an aesthetic onto ‘my’ world. Rather, inspired by Dwarf Fortress, the minimal intrusion of graphics invites the imagination of the user.
More widely in ttrpg publishing, writing practices and published texts are not arranged, like ‘Excel-DM’, in a mode overlapping with the psychogeography of player-characters. Instead, we have the frustration of writing and reading in a linear manner and then transforming that into a gameful space; in which the party want to go from Room 4 (p.3) to Room 12 (p.45) which are both next to one another within the gameful space but a faf and a flip through the book to combine; furthermore, the map, wandering monsters, and other aspects are similarly scattered. This is all labour intensive for the Master to haul around the decisions of the party, and needn’t be. Through a hyper-textual arrangement of textual data this labour of transposing linear text into non-linear adventuring is removed. Masters are able to navigate the world in the same way as players; moving North, South, East or West within the three scales of Global, Local, and Dungeon.
Notes on User Interface
When playing a session, I have two windows open within the application’s desktop; Mapper and Storyteller. I can click on a cell in the mapper to bring up the saved descriptions in the storyteller. The storyteller is also a readily editable text box, which can be exported at any time to a .txt file. There is one other window relevent here, Location Editor, which is how Users save descriptions within the Mapper Cells.
Category is: Tavern
The demonstration I brought to Coffee Break was one in which we, together, would create a series of Taverns and watch for the borrowed descriptions generated to recycle some of our prior entries.
Every Dungeon Master worth their salt has a tavern; by this I mean a fourty-second description that takes the audience from the outside of the tavern to the bar in a way that incorporates all five senses, people, objects and animals into an evocative description of not only a place, but a moment and a feeling. A tall order? Perhaps, but I didn’t say mine was any good. Furthermore, this description should use the fresh ingredients of players’ already stated interests and juxtapose them with familiar non-perishables. The resulting diegesis should present at least two options for further navigation besides the entrance/exit; commonly found either within the hooded, mysterious stranger in the corner; or the drunken jailor slamming pints at the bar with the cell keys dangling from his belt and happy to complain about the various characters held behind bars.
When we want to add a description to a cell, the User-DM opens the ‘Location Editor.’
The first thing to do is give the cell a unique name. Let’s say “Gretel’s Kneipe.” Then, think about a category and start typing it into the category box. For us, “tavern.” You will see that it begins to autocomplete against the list of existing categories.
When the User-DM is happy with the category, then simply hit [tab] and this will then ‘borrow descriptions’ from other entries under the same categories to fill any blank spaces. Each of the blank spaces is titled with a question, or prompt; these are editable just like the contents, but are returned the same every time we return that category. Prompts are supplied by yourself or other Users, to mark out what kinds of descriptions should be put into the box. As DM-Users work to keep their responses within the constraints of the prompt this has the effect of standardising the data entries; which means that the descriptions returned have the potential to be congruous with one another within a structured framework; but the design of that framework is equally malleable to the DM-Users. The congruence of descriptions is higher when prompts are followed and textual descriptions avoide specifics. So, instead of “Cut-throat Tim drinks hear with his gang,” write “A notorious criminal has made this tavern his hang out.”
The effect, as we discovered during Coffee Break , was an ability for prior reponses to be recycled and place themselves in novel ways. Sometimes furthering our intentions in a suprising fashion; sometimes bringing up other possibilties our tavern idea was lacking, but once incorporated brought new possibilities to bear.
Excel-DM is still just a project, but the principles of networked DM-ing are exciting and something I will continue document as the year goes on. Feel free to reach out to me @matthewkeracher on Twitter for discussion.