Virtual Dungeons & Internet Dragons

I started playing Dungeons & Dragons in college.

D&D is great fun. I could spend a whole post singing the praises of tabletop role-playing—but this is not that post. Suffice it to say that I played (and still play) the game with a group of my high-school friends—geeks and techies, all. Of all my hobbies, D&D quickly surpassed all others in importance; it became my main creative outlet. I started running games myself; designing adventures; creating worlds.

Now, if you don’t know anything about Dungeons & Dragons, these are the key points: it’s traditionally played by a half-dozen players, sitting around a table, armed with paper and pencils, some oddly-shaped dice, books of game rules, and overactive imaginations fueled by fantasy novels.

(In actual play, D&D bears a striking resemblance to “a bunch of friends excitedly talking to each other about orcs and wizards”.)

The problem was, my friends and I were scattered across the country (and, at times, across the world). How do you get together for a weekly game when you live in different cities?

What makes an RPG?

We can boil tabletop role-playing games (TTRPGs) like Dungeons & Dragons to three (technical) elements.

One is communication: the players have to talk to each other.

Another is dice-rolling: each of the players has to be able to roll dice (and not just the usual six-sided dice, but various other kinds), and all of the players must be able to see what any player has rolled.

Finally, the third element is the most broadly defined: the players have to be able to consult various shared media (rule books, sheets of character statistics, maps, images, etc.), and modify some of these media as well. (All of this has to happen in real time.¹)

Well, online chat programs can let you communicate in real time. Sharing media online is practically the purpose of the internet, and collaboratively modifying things in real time is also a reasonably well-explored domain. And what is a die but a random number generator? Surely, in this modern age of computing, an RNG (plus a decent UI for it) shouldn’t be hard to rustle up.

In short, online play is clearly possible in a technical sense. How does that possibility translate into practice?

If you want something done right…

My friends and I started playing D&D online in the early 2000s, when the practice was still new; the fancy, specially designed apps and tools that now exist—“virtual tabletops” and so forth—had not yet been created. We had to roll our own stuff. We didn’t use IRC, then; we used a (now largely forgotten) chat program called Hotline.

My friend Oliver wrote a “dicebot” program that could connect to a Hotline server and respond to special die-rolling commands from other users (you could, for example, type in “/roll 2d6”, and the bot would “roll two six-sided dice”—that is, generate two integers in a uniform-random distribution within the range (1,6)—and print the results of the rolls to chat). Oliver also created a web app (called “Hugin”, after one of Odin’s two magical ravens) which worked as a “shared whiteboard”, which we used as the game’s combat grid.

These things—Hotline, the dicebot, and the shared whiteboard—accounted for the aforementioned three technical elements of online TTRPG play.

Chat protocols & set mappings

When you play a TTRPG online, via text chat or a similar medium, one of the issues that arise is: what is the mapping between:

1. individual players (as in, the actual, live humans, sitting at their respective keyboards);
2. “users” of the communication system (however that system defines and treats the concept); and
3. characters within the world of the game?

And how is this mapping implemented and interacted with? This may seem a trivial matter, but it has non-obvious implications.

Consider how this works in the traditional (“live”) sort of TTRPG session: each player is (usually) mapped to one player character, and vice versa, while the Dungeon Master² (or “DM”) is mapped to, quite literally, every single other character in the game world. Sometimes the DM must play multiple characters within the same scene; sometimes different characters the DM plays must speak to each other.

Some DMs use different voices, or employ other such crude devices for differentiating between different characters. And, of course, there is the “character” of the DM himself—the Voice of God, so to speak; by this I mean the DM speaking in his capacity as arbiter, as “fictional physics simulator”, or as narrator.

The most important thing, for our purposes, is that in live games—where the players are all sitting around a table in someone’s living room—the mapping is 1-to-1, directly between players and characters. Playing online introduces a third, intermediary entity: the user.

(For the purposes of this topic, I don’t use the term “user” to refer to the person sitting at the keyboard; I mean the user as seen by the system; the virtual, protocol-dictated representation of a user of the text chat system.)

Some illustrative examples are in order. Consider case 1:

Bratislaw

I attack the demon!

Bratislaw

“Die, evildoer!”

DM

The demon cries out in pain and rage as your holy weapon pierces his fiendish flesh…

DM

The demon says, “You’ll rue the day you raised your sword against me, puny mortal!”

(Imagine that this is taking place via some text chat system. We won’t specify which one, yet.) Here we have two people, a player and the DM. Each is logged into some chat server; as far as the system is concerned, there are two users here. How many characters are there? Two, right? No, in fact there are three: the noble Bratislaw, the vile demon, and the DM-as-arbiter. To make this point more clear, consider the following version of the above (we’ll call it case 2):

Bratislaw

I attack the demon!

Bratislaw

“Die, evildoer!”

DM

The demon cries out in pain and rage as your holy weapon pierces his flesh…

Demon

You’ll rue the day you raised your sword against me, puny mortal!

We can imagine that the DM has opened another instance of the chat client—perhaps on a different computer, even—and has logged into the chat server a second time, this time with the user name “Demon”. As far as the system is concerned, there are now three users here.

In case 1, there’s a one-to-one mapping of players to users, but a one-to-many mapping of users to characters. In case 2, there’s a one-to-many mapping of players to users, but a one-to-one mapping of users to characters.

In my experience, the latter form is superior. It contributes noticeably to a sense of immersion on the players’ parts, which greatly enhances the role-playing experience, and improves gameplay in many ways. The problem is that it’s unsustainable; in many cases, the DM has to play the part of several characters at once, like so (case 3):

Bratislaw

I attack the demon!

Bratislaw

“Die, evildoer!”

DM

The demon cries out in pain and rage as your holy weapon pierces his flesh…

Demon

You’ll rue the day you raised your sword against me, puny mortal!

DM

Your trusty pixie sidekick appears nearby. She begins casting a spell of warding.

Olesia

Get him, Bratislaw! I’ll protect you from his evil magic!

DM

Suddenly, another demon bursts into the hall! Your ally, the celestial warrior Anait, sees this and moves to engage the new enemy.

Anait

I’ll hold this one off. Keep fighting!

Now the mapping goes like so: one player to one user to one character (Bratislaw), and one player (the DM) to four users (“DM”, “Demon”, “Olesia”, “Anait”), each of which maps to one character (the DM-as-arbiter, the demon, the pixie Olesia, and the celestial Anait, respectively). And this is a fairly straightforward scenario; the DM might have to play the part of five, six, or more characters; sometimes the other players must take on multiple roles as well. Most chat systems make it quite unwieldy to log into the same server five times with five different identities; they’re simply not designed for that purpose.

Compromises exist; for example, the DM could prepend identifiers to lines of “speech” (case 4):

Bratislaw

I attack the demon!

Bratislaw

“Die, evildoer!”

DM

The demon cries out in pain and rage as your holy weapon pierces his flesh…

DM

[Demon] You’ll rue the day you raised your sword against me, puny mortal!

DM

Your trusty pixie sidekick appears nearby. She begins casting a spell of warding.

DM

[Olesia] Get him, Bratislaw! I’ll protect you from his evil magic!

DM

Suddenly, another demon bursts into the hall! Your ally, the celestial warrior Anait, sees this and moves to engage the new enemy.

DM

[Anait] I’ll hold this one off. Keep fighting!

This is a much less satisfying solution. For one thing, it requires extra typing on the DM’s part, and anything which increases cognitive load for the already-burdened DM (who has many things to keep track of as it is) is bad.

Here I must digress to say a bit more about the “cognitive load” thing. This may seem trivial; an extra word, really? What sort of nonsense complaint is this? But every little thing builds up. It cannot be emphasized enough that running (that is, playing the role of DM for) a tabletop RPG game is a tremendously demanding task; it will push your faculties of concentration and attention to their limits and well beyond. You will miss things, forget things; it’s just a question of how often. Trivial inconveniences will become the difference between doing something one way or another way (or not doing it at all), with unpredictable and far-reaching consequences for player immersion, engagement, participation, and satisfaction. To be the best gamemaster you can be, to present a smooth, satisfying play experience, you must be relentless in optimizing your technique, your organizational practices, your habits. (And when you do this successfully, the players will notice, and they will eagerly look forward to the next game every time. That’s the payoff: the joy and excitement you give your friends. It’s well worth it.)

The “prepend identifiers in chat” solution has other flaws besides: it’s less visually clear and less aesthetically pleasing. It precludes the use of “actions”, which the better class of chat systems allow.³ To understand the latter, consider case 5:

 

** Bratislaw attacks the demon.

Bratislaw

Die, evildoer!

 

** Demon cries out in pain and rage as Bratislaw’s holy weapon pierces his flesh…

Demon

You’ll rue the day you raised your sword against me, puny mortal!

This is now substantially more immersive than case 1. The format of the chat in case 1—where the demon’s words and actions are embedded in chat lines that are explicitly marked as belonging to the DM—calls the player’s attention to the formal, artificial structure of the game; it points out that this is a game, that it’s unreal. The chat format in case 5, on the other hand, obscures the game world’s unreality under the illusion that the demon (one of many fictional constructs created by the DM) is just as real as Bratislaw (a character who, though he is also fictional, is uniquely identified with a single player, who makes decisions on the character’s behalf by imagining himself as the character—by role-playing, in short; and who thus feels, to the player, intimately real).

Finally, having a one-to-one mapping between users and characters means that the chat room (an abstract, virtual space) now takes on the function of a representation of a (fictional) physical space. The list of logged-on users gains new meaning: it is now also the list of exactly those characters who are present in any given scene within the game. As characters enter a scene, users representing them join the chat room; as characters depart, their users leave the chat room. This allows the players to instantly and at a glance be aware of who is present around them (that is, what other characters are present around their characters in the game world)—just like people are able to do in the real world. This, too, improves immersiveness, with all the salutary effects on gameplay and enjoyment.

An elegant chat protocol, for a more civilized age

Now, the Hotline protocol has an interesting trait: it is implemented such that it does not require each logged-on user on a server (note that HL servers have a single “public chat”, and therefore are more akin to IRC channels than IRC servers) to have a unique nickname or a unique username. I could be logged into an HL server five times as user “obormot” with nickname “Obormot”, with all five Obormots chatting simultaneously, with no difficulty. This makes it very easy to bring in new characters to participate in any given scene in the game; I can do this quickly, on the fly, with no delving into configuration screens or any such nonsense. (Recall that bit above about cognitive load? That applies in full measure here, as well as the fact that slowdowns of the DM’s workflow are more noticeable and more detrimental in online games than in live ones, where the players can seamlessly fill the gaps with banter.) Of course, I’d have to launch five copies of the HL client app to do so; not a great inconvenience, but one nonetheless.

Once more, Oliver stepped up to the plate, writing a Hotline client with a unique feature: the ability to connect multiple times to the same server, using a single window for all the connections. With a single click, you could add a new logged-in user to the chat, or remove any of the users you logged in; another click switched between users, letting you chat as any of the users you controlled. Called “Master”, this program was ideal for the Hotline-using DM, and let me run games in the style demonstrated in case 5 above, with as many characters as I wished, all barriers to a seamless workflow removed.

But Hotline died years ago.⁴ We switched to IRC as the chat protocol of choice for our gaming needs. In most ways, this was an improvement, but not in all. IRC—both due to the protocol’s design, and the UI design of available clients—makes it very unwieldy to sign on to a channel as multiple, differently named users. Doing so quickly, on the fly, without interrupting the flow of a game scene, is next to impossible. Certain inelegant hacks exist, such as using various web-based clients (open a new web page for every new sign-on), but these are kludges at best. Certainly none approach the old way’s ease of use (Hotline, with Master as the client app).

What is to be done?

So now it’s my turn to do something about this. Meil will have Master-like functionality, while also serving as a good, solid IRC client in all the usual ways. I will have much more to say about the details of this aspect of Meil’s design in posts to come. Stay tuned.

ACTION
======
This is used by losers on IRC to simulate "role playing" games.