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.

comm 1

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.

comm 2

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:

comm 3

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?

comm 4

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?

comm 5

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:

comm 6

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

comm 7

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?

comm 8

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.

comm 9

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?

comm 10


Diagrammatical languages are revelatory and they do some work.

Blame my patrons.