Play-by-Post and Procedure

(I’m on painkillers. You may notice.)

On rather short notice, I find myself gearing up for a play-by-post game. Originally, I was gearing up a tabletop Exalted campaign. I had some neat house rules and introductory plot hooks. And then it turned out one of my players would be moving across the country.

Rather than lose her and her character, I’m going to experiment with running a play-by-post game again. PbP is a wonderful way to play. You get a bit more time to consider your responses, and each character gets a nice share of spotlight in each post. Running characters in multiple locations simultaneously is also a lot easier.

Craig Oxbrow sets the gold standard for play-by-post. My character from one of his Buffy series is my favorite character I’ve played. I’m rather hoping he’ll have some comments on this post. Meantime, the best PbP I’ve run was Good & Evil, Incorporated, an action-procedural about corporate hitmen who hunt down sorcerers.

Let’s look at what I’ve learned from those games, and what can be applied towards running and designing play-by-post games.

Asynchronous Play

Players post when it’s convenient for them. Usually, this isn’t consistent. Some days, I’ll have a chance to post at lunch. Others, when I get home from work. I’ve even written posts from my phone while waiting for a drink.

Classic RPG mechanics require a fair amount of synchronization. Since Dungeons & Dragons, most games have relied on making sure each player gets their turn. In PbP, however, it’s sometimes impractical to wait for every player to take an action before resolving them. And any system that requires players to act (post) in a particular order is pretty much impossible to keep running in PbP.

However you handle resolution in a play-by-post game, traditional initiative has to go out the window. Assume that a player gets to take an action whenever they have the chance to post.

Data Locking

At a table, the GM can provide an instant response to each player action. In play-by-post, the GM probably only posts about as often as the other players. This changes how mechanics play out.

A lot of systems effectively “lock” the state of entities in the game while the player waits for the GM to respond. This isn’t so bad when I’ve made a Lock-Picking roll and I need to wait for the GM to tell me what happens. More of a problem when the party’s fighting a giant monster and any attack might kill it or provoke a special response.

Whenever one player’s action locks a part of the game world such that other players can’t decide their actions, you’ve got a problem. This rules out most tactical combat systems, and can even make traditional “I hit it with my axe” pretty awkward.

There are a few solutions to this problem. One is to make data like hit points available to the player. When my axe does four damage, I know whether that killed the eight hit point ratman or not, and other players can respond appropriately. You can take that a bit further, and let the player resolve their own actions.

The other solution is to give each player something different to do. This is what Craig generally does; each character in a scene usually has a different part of the scene to interact with. The almost-Slayer fights the monster, while the musician tries to herd the civilians out of the club and the medium tries to talk the poltergeist out of “helping.” So while each player might lock waiting for a GM response, they’re not blocking each other.

And Now Let’s Talk About Computers

In programming terms, each player’s experience is a task. Traditional games expect tasks to run alongside each other both cooperatively (that is, one thread yields to allow another to run) and pre-emptively (a higher authority allows one thread to interrupt another). Whatever data one player’s task is operating on is guaranteed to be unlocked (that is, resolved by the GM task) whenever that task gives up control.

Play-by-post is entirely cooperative multitasking. The end of a player’s post effectively yields the narrative to the next player’s task. But a player task yielding control doesn’t necessarily mean its data’s unlocked; the data isn’t truly unlocked until the GM task pops back in to operate on the data and report relevant events to the other tasks.

If that last bit confused you, well, pester me to write that post on narrative algorithms and data structures.

So What Should a System for PbP Have?

Ideally, players should be able to know the results of their actions when they make their own posts (and rolls). Allowing players to narrate for NPCs and the environment can keep a game running much more smoothly.

Wushu is beautiful for this, since players actually get rewards for describing both their own actions and those of characters around them. At the same time, most dangerous situations in Wushu use the Mook (or Threat) rules, which allow a player to know whether or not they took damage at the time they roll for their “turn.”

In addition, making as much mechanical information available to the players as possible speeds things along. So your system shouldn’t rely too much on hidden or surprise mechanics that require a GM post to manage.

When GMing, try to keep players engaged on multiple fronts. Also, scene framing is your best friend: a well-framed scene gets the players bouncing off each other and making their own fun. Cutting in and out of scenes artfully can be a powerful tool for keeping a coherent and well-paced narrative.