more diagrams so sue me

Data Flow Diagrams are fun for highlighting all kinds of design problems and then fixing them. It’s intuitive: when there are tons of overlapping arrows you have a problem. When you have an arrow entering or exiting a resource but never the reverse, you missed something. When you have two process bubbles talking to each other directly you are implying synchronous behaviour. This lets you untangle, rethink sources and sinks, and wonder if there’s value in asynchronicity since you can see how to implement it.

As a cheap example let’s look at a simple synchronous conversation between four people.

Instantly we see that synchronous communication between people gets complicated fast. Now fortunately at a game table most of that conversation is casual — it’s not part of the rules, per se. For example, while all the players can and do communicate with each other, the rules might specify a stricter relationship.

Back in the Old Days we recognized that even this was messy and that, since it happened anyway, we’d formalize the idea of a Caller — a player who was authorized to do the mechanical communication with the ref, neatly gating the interplayer communication off. Again taking the inter-player communication as non-mechanical and not part of the diagram:

One might feel that this an artifact of old school game design and one would be right. This is partly because many of the moves (which were not yet recognized as codifiable as Moves) were group moves: we go south, we go down the stairs. But since someone was gating group moves anyway, and since it cut down the confusion of crosstalk (the person being confused being the ref mostly), whoever was coordinating group moves was also summarizing individual moves:

ABLE: We should listen at this door before we go in.

BAKER: I want to just kick it in and charge.

CHARLIE: We will pause at the door and ABLE will listen.

DOG: [dice] you don’t hear anything.

CHARLIE: BAKER kicks it in.

Partly this is because there’s a lot of other things competing for the attention of the ref and this simplification is valuable when you’re running a secret dungeon map with wandering monster tables and trying to remember what’s even on anyone’s character sheet let alone where you put the stat blocks for those aboleths. Simplifications in this environment are going to happen anyway — might as well codify them.

When we really want to break things down and listen to everyone specifically, we went to a turn based system: the ref asks “What do you do, ABLE?” and then “What do you do, BAKER?” and we of course didn’t interrupt each others’ turns. A classic multi-tasking solution — we time slice the incoming events and give every pending interrupt its own little slice of the ref’s attention. The turn.

In deciding to treat role-playing as a conversation we don’t really solve this problem, we just agree that it’s more fun as a human problem than a mechanical one and it’s fine to just broadcast “What do you do?” to the whole table and handle interrupts as they arise. It’s a little weird to me that this is the modern development, when way back in the turn days we were trying to solve the problem of spotlight sharing and had a pretty good solution (time-slicing) and lo and behold, now we have the problem of spotlight sharing again. This seems backwards — it seems like in the bad old days we should have been shouting over each other with the loudest attended to and in the newfangled design-aware world we should have a mechanism to guarantee equal access to the ref. But whatever.

Anyway that’s sort of a digression. What I wanted to get to was asynchronicity. What if we did this instead?

This is an asynchronous model of play, where everyone talks into some store of messages and pulls out the latest one. Rather than talking to each other we talk into the data store. You might recognize this as the play by mail or play by forum model. It’s even, really, the play by chat model, it’s just that we tend to use chat (like Hangouts or Discord or whatever) as an immediate communication technology, but there’s a back end store and you could come and go as you please and still pick up the thread from the store.

An interesting thing about this model is that it invites us to consider adding additional processing. What if we had another node that wasn’t a person at all, but that changed the content of the store or that listened and added its own content?

Now we have text formatting, dice bots, directed communication (tagging something such that it also notifies a recipient), and potentially other assistance! And really nothing restricts us to one store — one might have another store that’s private:

Yup, direct messages. These data stores are powerful!

So let’s look at another data store that we all use: character sheets. Ignoring the rules reference, our traditional play actually looks like this (at least):

Everyone is maintaining a store containing their character information and the ref needs to see it. In fact it’s worse than that if you want to huddle together over tactics: everyone needs to see everyone elses sheet as well as talk to each other and that’s a lot of arrows. One of the things that happens in the real world when a social model like a game has a lot of arrows, is people stop using some of them. If they are necessary to the game then necessary parts of the game start getting stripped away. People stop doing stressful things eventually and this is how rules get pruned.

But what if we just put all our characters in a shared document?

Our diagram now has way fewer arrows and still has the same capabilities (though I had to move things around to make the arrows not overlap, the topology is the same). It has more even. Practically speaking this means that the ref is probably going to pay more attention to what’s on your character sheet. And if the system is designed such that there are important things there (plot hooks and mechanical advantages) that’s a really good thing to preserve. In the previous spaghetti of communication, those are things that will get dropped to cut the stress down.

You can already see other parts of your game that can be diagrammed like this and then adjusted to reduce complexity. If everyone needs their own copy of the rules, that’s pretty terrible for example. If everyone shares a book that’s still cumbersome.

But put essential rules on the character sheet and things simplify. You already knew THAT would happen but are there other things you’ve missed?

Probably.

Diagrammatical languages are revelatory and they do some work.

Blame my patrons.

diagramming play as conversation

Recently a friend (whom I respect and who is not Wrong — that’s not what this is: it’s a divergence not a rebuttal) posted a revelation inspired by a symbology for interactions in an RPG. They posted this:

…and noted that since each node is apparently equal (and certainly equal as humans ought to be) then the nodes were in fact interchangeable, allowing this:

EDIT: turns out I misinterpreted my friend’s diagram and conclusions. Not all that uncommon for me! Anyway, the following is still fun and relevant, it’s just that the above is hypothetical and not necessarily something anyone anywhere has actually concluded.

I think that while this is true, it’s trivially true because of the simplicity of the symbology. That is, it implies a truth that is in fact only revelatory because the symbology ignores so much that is interesting in the ref-player relationship of a traditional game. It’s revelatory but it doesn’t do any work for you. Let’s revise this diagram a little in order to understand the true design cost of implementing the egalitarian structure implied above.

My first cut would be to recognize that while this is a conversation, it’s a conversation with privileged roles. Rather than a simple two-way discussion, what’s really going on is this:

That is, the player offers narration until an action triggers the ref’s response, and their response is to inform the player of an update to the shared world’s state. This might be as simple as:

PLAYER: “What colour are the walls?”

REF: “Orange.”

Until this exchange, every player and the ref have a different colour or no colour in mind. It’s not until the ref updates the formal state by declaring it that the walls resolve to a particular colour. So this implies that the ref is storing some state:

We obviously need to do a bunch more work to make it as symmetrical as we want! Migrating the ref role is going to need some design work, even if it’s just a declaration that we are not going to care about this stored state beyond agreeing that everyone’s internal idea of what has gone on before is considered equal. When inconsistencies arise, perhaps the current declarator of the state is always considered correct. Or perhaps there’s a physical annotation of state that’s literally handed over. Whatever we agree, it’s necessarily part of the design and this richer symbology reveals that that work is necessary.

For example, if we wanted to imply that everyone’s internal idea of the world state is equal until revealed, we might diagram like so:

This choice of diagramming scheme, this symbology, encodes the fact that each player has a different state stored. That’s something you need to deal with (however easily — I’m not saying it’s hard or easy, just that it’s a design decision) and the symbology has made it absolutely clear: those are not the same state storage boxes.

And then, it’s not that simple. Nothing ever is. Let’s say everyone has an idea of what colour the walls are and it has not been declared. Now it may be the case that a current ref not only has an image of the walls as orange, but also has a reason for this. One that implies some future conflict or interesting reveal. If the ref role is handed over before that can be brought into play, and the wall colour is revealed to be green, then that future state (plans) would be obviated. So what we really have in trad ref structure is this:

Again, this is not an argument against ref migration but only that too simple a symbology will fail to reveal the work you need to do. The minimum work here would be to say that everyone’s plans are irrelevant until reveal: there are many possible future universes but only the current ref role (even if this is as simple as whoever declares a fact) gets to pick which one resolves as real and current. It also, happily, reveals alternate design possibilities: is it possible to somehow communicate future state ideas between people and therefore preserve some of the planning that naturally takes place as people converse about this fiction? Let’s say you note an exciting future state idea and put it on an index card in the center of the table and when someone takes a declarative (ref) role, they draw a card and decide whether or not to incorporate it. This implies further mechanism that might be fun — do you destroy the card or return it to the pile? Is there a reward for using it and how gets the reward? Is there a penalty for refusing it? Or even for using it? Again, a choice of meaningful symbology reveals the design space. Gives you clues.

While a simple symbology can be creatively stimulating, revealing (or more realistically suggesting, since it works because the symbology is incomplete and therefore possibly incorrect in practice) unexpected space on the map of all game design, it doesn’t really capture the work that needs to happen to open up and explore that space. You can do it by trial and error — just try sharing the ref hat around and see what happens — and that’s actually pretty good methodology for an RPG since testing is play and play is fun. But you can also extend the symbology and find out beforehand what the design work is going to be. Existing process diagramming tools are good for this (what I’m using here is a bastardized form of Data Flow Diagram or DFD (https://en.wikipedia.org/wiki/Data-flow_diagram) but any logical system for diagramming can be put to use to map for game design. I think the DFD is at once simple enough for anyone and also rich enough to be revelatory.

My patrons make these happen.