My first Cortex Prime build was a hard-boiled/noir novel emulator, with a short but satisfying test run—also, my first-ever play-by-post (PbP)—but after the initial enthusiasm, the game lost momentum, and eventually entered an indefinite hiatus. Since then, all my PbP experiences have been similar: initial enthusiasm, satisfying run, loss of momentum, and indefinite hiatus.

So far, I have not thought twice and worked, instead, to substitute other modalities for PbP with folks I really wanted to play with. Unfortunately, Russia took that solution off the table for one special friend. Even with a military rotten to the core, whose officers’ apex skill is lying to their teeth, they somehow managed to make Ukraine’s power grid incompatible with VTTs.

Playing with that friend is pretty much the only positive impact I can have on their circumstances at the moment. It’s not much, but it’s something. And so I’d rather avoid the “initial enthusiasm/satisfying run/loss of momentum/indefinite hiatus” gameplay loop.

Now, the game we’re planning builds on the Cortex Prime engine, but today’s post will remain by-and-large system-agnostic. I’ll list what I consider constraints on PbP, then suggest tweaks, but I’ll leave out the mechanical details.

And before diving in, I claim no particular expertise other than a well-honed analytical mind (after all, I’m a logician) and experience with PbP projects, both successful and aborted. And also, fuck Russia.

A Trinity of Troubles

Let’s clarify: by “PbP” I mean “asynchronous PbP.” Synchronous PbP is not much different from in-person: a session starts with everybody logged into a chat interface, similar to meeting at a table, and real-time course correction is possible—only by text chat, instead of voice chat.

Neither applies when players contribute in sequence, possibly without real-time communication. Crucially, participation is always conditional on players not having anything more pressing to do, and course correction is post hoc only. Splitting that hair, here’s a short list of issues.

• Structure. Everybody can in principle branch off at any time leaving the game moderator (GM) to juggle with unconnected threads later.
• Tempo. Players’ commitment and response time vary, and a temporarily undermotivated player, or one caught in a real-life crunch, can halt a game indefinitely.
• Arbitration. Interrupting to call for dice rolls is not an option, but PbP turns into collaborative writing when there’s no unpredictability.

The above list is not exhaustive but sums up my experience, and that’s the only generality I’ll claim. And to further establish common ground, here are the reasons I consider the above problems.

In real-time games, players who don’t want to silently listen to others’ monologues might tag along with plans they’re not crazy about. By contrast, PbP is more of a sequence of written monologues than a (moderated) conversation, lowering the odds of coordination emerging from “just playing.”

Following up on coordination, PbP is often a workaround for busy real-life schedules, and tempo reflects commitment and availability. They both vary, even for individual players, over time, and a game should adapt to that. Hard rules for deadlines and mandatory participation are possible, but they seem to me to defeat that purpose.

Playing to discover what happens implies that the game world should sometimes respond to player characters’ actions unexpectedly. The game rules model the variance of that response. If they don’t come into play, what happens is akin to multiple writers’ inspirations combining into one story—and that’s co-authored fiction, not TTRPGing.

You may disagree with any of the above. If you’d happily enforce cooperation in your gaming group with a rigid story structure (aka a “scenario”) and/or tight rules and deadlines, all these issues would disappear. Ditto if you’re fine with collaborative storytelling sans rules.

Some solutions, in principle

My leading principle is that avoiding rule-based back-and-forth between players and GM is key to a PbP game’s flow. This may appear to rule out (pun intended) systems with a high density of dice rolls, like skirmishing-and-looting simulators (D&D, Pathfinder) or generic physics simulators (GURPS).

Appearances notwithstanding, roll density is a red herring. Given access to NPCs’ stat blocks and a simulationist system, a player could resolve a situation without GM input, provided that they know the NPC’s intentions and preferred method of action, rolling for themselves and their opposition (assuming good faith, etc.).

This can solve the arbitration issue if the rules provide enough scaffolding, i.e. if players can easily identify when they should input the world’s response to their characters’ actions. But it may not help much with tempo if there’s more than one player, and someone goes missing.

But conversely, given access to PCs’ stat blocks and a simulationist system, a GM could resolve a situation without player input, provided that they know the PC’s intentions and preferred method of action, rolling for them and their opposition (assuming good faith, etc.). So, a GM could fill in for a player gone missing in real-life action.

Now, those are only solutions in principle, and their viability in practice depends on good faith (already mentioned), and the willingness of everyone involved to temporarily relinquish agency. And, they do not help much with structure. Fortunately, there’s a workaround.

Scaffolding

The simulationist solution to the arbitration and tempo issues extends to systems where rule scaffolding is tight enough to represent N/PCs’ intentions and preferred action methods (“scaffolding” is not “crunch,” cf. the Fine Prints). As for structure, I’d take a page from narrative systems centered around scenes, and let the dominos fall from there.

• Structure. The unit structure is a scene with a well-defined (default) challenge. The PCs are dropped in medias res in the scene, saving exposition. Players can tackle the challenge, or side-step it entirely—it’s not a plot hook (cf the Fine Prints).
• Tempo I. A scene included a cast of NPCs with specified strategies: within the boundaries of the challenge, everybody knows how they would behave—and thus, how to roll for them if need be.
• Tempo II. At the challenge’s beginning, the GM announces what they take to be the PCs’ “default” strategies: if a player doesn’t object, and later goes MIA, the GM can use it (but should compensate the player, e.g. with metacurrency)
• Arbitration. Solved, in one fell swoop, with Structure and Tempo: whether the players (GM included) engage in the challenge or attempt to side-step it, they can in principle rolls for themselves and their opposition.

Some rulesets have distinct advantages for this above. I wouldn’t try it with D&D or Pathfinder for anything but combat, but I can see it working with GURPS (which has solo play). But narrative engines typically offer better options to represent challenges mechanically as stat blocks similar to NPCs (Fate, Cortex) or as a randomized story generator (PbtA).

Leveraging (local) structure

A scene challenge is a tie-in structure: when choosing one, the GM should have an idea of the player character’s typical reactions to the challenge and (possibly) announce them. That way, if a player does not feel compelled to engage, the GM can default to that reaction. Here are three options for players.

• Go along. The player actively participates and conforms to the expectations about their character’s typical reaction.
• Resist. The player actively participates but does not conform to expectations, thereby adding to what other players/characters can react to in the scene.
• Sidestep. The player declines to actively participate in the scene and excepts their character from it, but proposes an alternative situation to be resolved later.

A fourth possibility, but not strictly speaking an option, is a player going MIA and the GM taking over their PC for the scene. While functionally equivalent to Go Along, the player will have to deal with the fallout of actions they may not have taken. My policy is to compensate the player (with metacurrency because the systems I use has it).

Note that Resist and Sidestep blur the traditional player-GM line, as they may result in scene reframing (Resist) or a new, player-initiated scene (Sidestep). There’s much more to say about structure, but that will suffice for today.

Scaling up?

The above tweaks are unlikely to offer a complete solution to the “initial enthusiasm/satisfying run/loss of momentum/indefinite hiatus” gameplay loop. They are, at best, a “local” solution to prevent loss of momentum, where “local” stands for at the scene level.

Currently, I have no solution to maintain momentum in the long run that I’d be comfortable discussing because the only one I ever worked out (with my first Cortex build) did not pan out.

Then again, in retrospect, it was not unlike scaled-up scene challenges with an act- or chapter-level structure. And the game may just have been wanting scene-level structure for the preservation of momentum, which the above tweaks are intended for.

The Fine Print

---

Wrapping-Up: What about no GM?

With those tweaks, PbP veers toward co-op play with a GM emulator (à la Ironsworn, a PbtA engine). However interesting I find the random-plot-generation aspect of GM emulators, I quit playing AD&D because I was fed up with random encounters, so I’m kinda biased.

Sure, GM emulators and oracle systems leave tons of stuff open to interpretation, which co-op players then tie together to build a consistent world. To be honest, I prefer a designated player acting as a game moderator. I’m old-school that way.

Then again, it may not be that old school. This division of labor is the cornerstone of the original Apocalypse World, the single most disruptive innovation in TTRPGs in recent memory. Granted, a bunch of “powered by the apocalypse” games have embraced co-op play. But that’s another story.

Now, I’d love to explore the “co-op with GM” angle in the future, but it’s time for some practice, so that will be all for today, folks.