How to Run a Pathfinder, 2e Play-by-Post Game over Discord
This post provides some of my thoughts about running an asynchronous play-by-post (PBP) Pathfinder game over Discord. PBP is a game format in which all play is done via posting on Discord. The PBP games I run are asynchronous in that not all players are required to be online at the same time. I’ll discuss some of the pros and cons of the PBP format, some thoughts on setting up and using a Discord server and other technologies, as well as some policies I use in my games.
Benefits and Challenges of PBP
PBP has a number of benefits that draw me to the format. Firstly, it’s accessible, allowing a group that doesn’t share a large, weekly block of free time to participate in engaging campaigns. Players can have wildly different schedules and still play with each other (although, as discussed later, I prefer that all players be in similar time zones and have the ability to check in and post multiple times a day most of the time). Secondly, PBP as a format allows for greater role-play in my experience. Players have the time to put a lot of thought into important posts, and can flesh out their characters and their relationships in greater detail than they might be able into in a standard live game. On a related note, PBP games still require detailed prep on the part of the Game Master (GM), but if players go in an unexpected direction there is more time to plan and execute a reaction in a coherent way. Lastly, I think the PBP format is fairly scalable from a GM perspective, but this is something I am still slowly experimenting with. Personally, I’m less interested in running multiple PBP games of the same system — so I’ll likely be running other PBP games soon in other systems.
PBP also has some challenges that require careful attention. A big one is pacing. It is a fact of life that the pacing will vary from time to time, but keeping the game alive requires active attention and clear communication of expectations. It’s also important not to move too fast in a way that makes some players feel unable to meaningfully participate. Maintaining coherence in the order of events can also be a challenge. You may have a player who is constantly engaging and a player who works much of the day. In a conversation, a lot could happen before the working player has a change to interact with an NPC — and they might want to respond to something that was said earlier. I generally allow for some ambiguity of exactly what happens when in such cases to allow for the latter player to contribute, this just requires being proactive about maintaining coherence. Another challenge that requires attention is making sure that everyone is ready before moving scenes. These are some of the most consistent challenges when running PBP, and a bit later on I’ll provide some thoughts on how to mitigate them.
Initializing a Game
The first step to initializing a PBP game is to make a few decisions that will have be communicated to players before the game starts. If you have a pre-existing group of players, make sure to include them in such decisions. Most things you want to decide at this step are common to in-person, live games and are outside the scope of this post, but one major consideration which is specific to PBP is the desired check-in rate. I prefer to ask players for a target minimum of three check-ins per day, but I think one or two per day might be reasonable targets for some groups. Setting this expectation will help the game be fair for all players, as it limits how long the game might wait on an action from one player. Players who fall well below the target check-in might have their characters temporarily “botted” by the GM to keep things moving at the desired pace. This expectation is one of the most important things to communicate up-front.
If you are going to be recruiting players from the internet, you’ll definitely want to make sure that you communicate the expected check-in rate along with any other expectations in any advert. You’ll want to throw a wide net to catch many potential players and then take time vetting them to find the best players from among them. I’d recommended pulling players from similar time zones to you and making sure all players understand the expectations — but beyond that the vetting process is out of scope for this post.
Discord Use
In my view, Discord is the best platform for running a PBP. I break things apart into a few channels — primarily “main”, “mechanics”, and “status”.
In the “main” or “story” channel, players post narrative entries which explain their characters actions and you post descriptions of what players see and experience. Example:
GM: The path ahead gets narrower and the forest gets thicker. Less sunlight seems to make it through the canopy. You all suddenly hear a rustling up ahead.
Jorek: Jorek holds his hand up, trying to get everyone’s attention. He readies his shortbow and then motions for the group to follow.
In the “mechanics” channel, you ask for rolls, provide mechanical information that doesn’t make in-world narrative sense, check for exploration activities, and things like that. Example:
GM: You’re traveling through a forest, so what is everyone’s exploration activity?
Jorek: Jorek will be scouting.
GM: Okay, everyone will have + 1 to any initiative rolls that come up.
Sandr: I’ll be searching.
GM: Great. Based on your character sheet, your Perception modifier is +7, is that accurate?
This “mechanics” channel is also where I put (using Discord’s spoiler feature with two vertical bars) information that only one character might know.
GM: Sandr, || you see an abandoned pack just a few feet off the pathway ahead. ||
The character could then choose to share that information or react to it in the “main” channel.
The “mechanics” channel is also the place to make rolls (using a bot like Avrae), including non-secret GM rolls (I roll enemy attack and damage rolls in public).
I post in the “status” channel updates about the current status (such as combat turn order and HP, marching order & exploration activities, or subsystem updates). Here are some examples:
MARCHING ORDER / EXPLORATION ACTIVITY
Valeros / Defend
Jorek / Scout
Sandr / Search (Perception +7)ROUND 1
>> [24] Jorek 22/22, AC 17
[20] Monster
[18] Valeros 28/28, AC 18 + 2, shield raised
[15] Sander 18/18, AC 15
CONDITIONS
Dim LightThere is also a “chat” channel, which is for out of character conversation as a group. I also use an announcements channel for game-related and server-related announcements, and I keep a “wiki” channel (a Discord forum) with entries about major NPCs, locations, etc.
Running exploration mode and downtime this way is fairly straightforward, but it’s worth making a few comments about how to run combat. I keep some private, GM-only channels for rolls and status updates where I’ll add and track enemy details. I ask for initiative in the “mechanics” channel and players make their rolls. I roll enemy initiative in secret. Once everyone’s initiative is in, I set up the scene on Owlbear Rodeo and then make a post like thisin the “status” channel:
INITIATIVE
[24] Jorek 22/22, AC 17
[18] Valeros 28/28, AC 18 + 2, shield raised
[15] Sander 18/18, AC 15
[??] Monster
CONDITIONS
Dim LightI keep enemy initiative secret until it becomes their turn for the first time. I also don’t display how much damage enemies have taken or their ACs, at least at the beginning. If it becomes clear that players who were watching on rolls carefully would have been able to deduce the enemy AC, I sometimes add it to the status posts after that point.
Everytime it’s a new character’s turn, I make a new post with any updates rather that constantly updating the same post. This makes the “status” channel noisy, but it’s also very clear when it’s up to date.
I ping each player when it is their turn. They can declare one action at a time or declare multiple actions. If, during resolution, something would change the situation they are free to change later actions. For example, if they move and then attack but as part of the movement trigger a trap, they could use that actions to do something else (keeping the face value of any rolls). For attacks, I ask players to make attack rolls and damage rolls together, so that we can save time if it hits. If the attack ends up hitting we apply the damage, or double it for a critical hit. If a critical hit would use different die size then I ask for a reroll. When their turn is over, I make a new status post and ping the next player (or take an enemy’s turn).
When combat is over, or after any short rest (Treat Wounds, etc), I ask players to reconcile the latest post in the “status” channel with their character sheets — including any HP totals and durable conditions. Keeping character sheets up-to-date is generally the responsiblity of each player, but during combat we use the “status” channel to track turn-by-turn changes in HP, conditions, etc.
Running the game in Discord basically requires two key bots: Tupperbox and a dice roller. Tupperbox lets players set up avatars and profiles for their characters such that all posts they make in the “main” channel appear to be coming from their character. As a GM, I also make “tuppers” for each major NPC in addition to a generic GM profile. This makes for much clearer reading in the “main” channel. For rolling dice, I prefer Avrae as my main dice roller bot but I also include kobold on my server as well (this integrates well with players’ character sheets in either Wanderer’s Guide or Pathbuilder). There are likely other quality-of-life bots that would help running a PBP game, but Tupperbox and a dice roller are required.
Owlbear Rodeo Use
Owlbear Rodeo is a great, simple tool that fills the roll of a Virtual Tabletop (VTT) and works well with PBP games. Owlbear’s feature set is beyond the scope of this post, but keep the link to the group’s Owlbear Rodeo room pinned to the “mechanics” channel. I use a different room to build scenes as necessary. When players take voluntary movement, I ask that they use the marker feature to mark their path of movement (for traps, reactions, etc). If a player forgets, I make a good-faith attempt at estimating their likely path.
Character Sheets
Players are responsible for maintaining their character sheets, and all I ask for access to a somewhat recent version. Wanderer’s Guide and Pathbuilder are both great digital options. Wanderer’s Guide characters can be made publicly visible, so a URL only needs to be grabbed once. Pathbuilder can export public copies of the character, so I ask Pathbuilder players to give me an updated export every time they level up. Players could also track their characters using pen & paper character sheets, and I would just ask for PDF versions after each level up.
Key Policies and Procedures
Now, I want to cover a few procedures I use to try to keep the game running smoothly. All of these involve the core challenge of PBP, which is pacing. Firstly, I define a few benchmarks based on the check-in rate. Since I ask for check-ins at a minimum of three times per day, I use 6, 12, and 24 hours as key thresholds. If you have a less frequent expected check-in rate, use similarly longer thresholds. I’m always comfortable with a scene “sitting” in one place for 3–6 hours. After that time range, I use a handful of policies to decide whether or not to move the scene (if a scene movement would trivial or obviously uncontroversial, I might move it after the 3 hour mark).
One such policy is the quorum system. For the purposes of my PBP games, a “quorum” is half the party size plus 1 (2/3, 3/4, 3/5, 4/6, 4/7, etc). Moving a scene sometimes only requires a quorum of players to be ready. I still don’t want to move too quickly without high participation, so I don’t move right away with a quorum. I often post checkpoints in the “mechanics” channel, asking players to acknowledge that they are ready to move on, and sometimes taking a poll on which of several options to pursue. Once I get 100% participation, I’ll move the scene. In some cases, I’ll move the scene after the first threshold (6 hours) provided that a quorum of players has responded. In any case, I’ll move after the second threshold (12 hours) is reached. The quorum system helps keep a minimum pace regardless of the situation.
Another policy is the “botting” policy. After certain time frames of player non-responsiveness, I may “bot” (take actions for) the player’s character. The first level of botting (which I call “trivial botting”) comes in at the first threshold (6 hour mark). Generally, I only do things that I know the player would have to do (such as rolling a check I asked for, rolling initiative, etc). Moving the scene with approval from a quorum alone is a type of trival botting as well. the next level of botting (“light botting”) comes in at the next threshold (12 hour mark). At this point, I might take a player’s turn, or decide that a player makes some choice. Botting a character’s choices must always be done in good faith, and if an absence is forseen I’ll honor any input a player gave on how to bot their character. After being lightly botted, I don’t keep botting the character. If an action is required of the same character later, I wait the full threshold again. If, however, the higher threshold (24 hours) is crossed after something was needed from the player with no sign of them having come back, I’ll move the character to a full botting status, where I’ll treat the PC as an NPC until the player returns. This is analogous to when a player might miss a session in an IRL game, so I’ll usually look for a cause to move the character away from the party temporarily. These botting policies helps put a limit on how much the game can slow down.
PBP is an engaging format for Pathfinder 2e (and for other RPGs as well), and I’m still in the early stages of learning and forming best practices — but what I outlined above are my lessons learned from running two games. I’m likely to continue using the format, and possibly employing it in other systems as well.
