The Alexandrian

Posts tagged ‘troupe play’

Random GM Tip: Backup PCs

February 21st, 2022

Roleplaying games can vary a lot in how lethal they are for player characters. And, perhaps even more importantly, they can vary a lot in how permanent death is when it occurs.

This can even be true within a single system. In some classic versions of D&D, for example, PCs can begin in an ultra-fragile state (in which any hit in combat could automatically kill them) and then level up to a point where death is just a minor inconvenience.

But let’s assume that we’re playing a game where death really is the final frontier: If your character dies, then they’re dead. No take-backs. If you’re playing in a campaign with a game like that, how can you handle death?

One way is to duck the question entirely with script immunity. In campaigns with script immunity, PCs simply can’t die. This may be a feature of the rules (as in Magical Kitties Save the Day), but is often a metagame conceit openly or silently respected by the table. There are a number of techniques that are useful for making script immunity work, but the two most common approaches are to either disallow the mechanical outcome of death (NPCs will always miss the final blow) or to interpret the mechanical outcome of death to mean something other than death (e.g., the PC is instead knocked unconscious). These are often combined with a caveat which allows the PC to die if their player wants it to happen. (This is because script immunity is usually a technique favored by dramatists, and being able to have death occur only when it is dramatically appropriate and satisfying is desirable. But I digress.)

What I actually want to focus on is not how to avoid PC death, but rather what comes next.

The first option is to actually remove the player from the campaign. The PC was their agent in the game world. Now that their agent has been destroyed, they have no ability to participate in the game.

This is, in some ways, the opposite extreme from script immunity — where immunity completely removes lethal consequences from the game, the all-or-nothing approach makes those consequences about as meaningful as they can be. On the other hand, script immunity and one-PC-only both recognize how momentous and important death can be to a narrative and simply emphasize it in radically different ways.

Personally, I’ve never seen one-PC-only used in a multi-session campaign. (And I could only really imagine doing so if it was very deliberately the focus of experimental play.) But it’s far from unheard of to see it used in one-shots, and it can be built into games like Ten Candles and Dread.

The far more common approach, of course, is to replace the player’s PC with a new PC. Your character is dead, so create a new one that can join the group.

BACKUP PCs

There are two impediments to consider when using replacement PCs.

First, the time required to create the new character. This can range from trivial in some systems to laborsome to baffling (in games which feature interconnected character creation mechanics but neglect to account for how new PCs could be added to the group).

Second, how to organically integrate the new PC into the existing group. Even when the group leans into the metagame conceit of the replacement (“we trust this newcomer implicitly because we know Mark is playing her”), there can still be the question — when the group is in the middle of a vast dungeon or lost in the untracked wastes of an uncharted jungle — of how and when this new character can actually show up.

Sometimes these two problems can nicely cancel each other out (the time taken to create the new character neatly covers some or all of the time it takes the rest of the group to reach a point where a new character can be naturally introduced), but there can still be logistical and logical hurdles to clear.

The core tip here is that you can solve the first problem by preparing a backup PC. In other words, before your character dies you can already have the replacement character prepared and ready to go. This obviously simplifies things, as you can simply pull out the new sheet and get back to playing lickety-split.

Tangential Tip – Inheritance: If you’re playing in a game where gear is important (e.g., D&D), make sure backup PCs don’t come fully equipped for their current level. You need to work from the assumption that they will either directly or indirectly inherit the wealth/gear of the PC they’re creating. Otherwise every dead PC becomes an incredibly rich looting opportunity and death, rather than being a failure to be avoided, paradoxically becomes a payday which dramatically rewards the group.

You can extend this technique to begin addressing the second problem by giving the backup PC a clear connection to the group. This will often be through the PC who died. For example, “I heard my brother was killed! I have come to avenge them!” (Early versions of D&D actually included rules and guidelines for handling PC-to-PC inheritance and probate.)

BEFORE YOU DIE

Now that you have a slate of backup PCs waiting to step up if a current PC should die AND those backup PCs have existing relationships with the PCs (sisters, apprentices, old college roommates), you can incorporate the backup PCs into the game while the current PCs are still alive.

In many ways, this just makes sense. If you’ve prepped an apprentice who can replace your character Obi-Wan if they die, it makes sense that the apprentice would be part of the story before Obi-Wan’s death.

Of course, once a backup character comes onstage like this, it’s certainly possible that the evolving narrative will make them unavailable or inappropriate for being a PC. That’s fine. (Obi-Wan survived long enough and things went crazy enough with their apprentice that they ended up giving the apprentice a son and just copy-pasting their stat block onto it.)

Tangential Tip – Promoting NPCs: You can flip cause-and-effect here by letting a player of a dead PC take on the role of an established NPC. Even though the NPC wasn’t intended to become a PC, they have an existing relationship with the other PCs and are already integrated into the narrative.

Onstage backup PCs can be played by the GM, but it’s often more effective if the player takes on the role “prematurely” when necessary. To that end, it can be most effective for your backup character to have a connection to a different player’s PC. If you’re playing your own apprentice, there’ll be lots of moments when you’d have to roleplay with yourself (which can lead to skipping or abbreviating those scenes). But if you’re playing Alejandra’s apprentice, then you’ll both be able to frame up interesting scenes and small interactions that will enrich the game.

A variation of this is to create a common pool of backup characters, rather than having each player create their own. You might have one or two or three such characters, and whichever player’s PC dies first (if any) simply grabs whatever character is most convenient from the pool.

These backup characters might also just be temporary roles, which can be played until it’s convenient to create and bring in a fully fledged new PC. (In old school D&D, taking on the role of another player’s hireling is an informal version of this.)

These backup PCs can even account for Total Party Kills (TPKs). “So-and-so has mysteriously vanished/been killed and I’m looking through their notes” is a well-established trope in Lovecraftian fiction, for example, and can easily be transferred to other genres. Laying the groundwork for this sort of insurance policy can be used to frame epistolary play and bluebooking, encouraging note-keeping and enabling different forms of roleplaying that greatly augment a campaign.

You also don’t have to wait for a PC to die in order to swap to your alternate PC. Any number of circumstances might suggest it: Your primary PC might want to retire, be called away on a family emergency unrelated to the main thrust of the campaign, disappear into the Fairylands, or go into a witness protection plan. Or maybe you just want to switch things up.

In fact, you can swap back and forth between your PCs. Or across multiple characters. If your group has established a common pool of PC options, you might even find yourself playing the same character that was previously played by a different player.

TROUPE PLAY

… and we’ve just reinvented troupe play.

First created by Jonathan Tweet and Mark Rein*Hagen in the Ars Magica roleplaying game, troupe play can be broadly defined as a campaign in which the cast of player characters is larger than the number of players and the expectation is that the players will take on different roles for each session or scenario.

This style of play is, of course, quite impervious to the question of, “What does Naito do when his PC dies?” because it has already eschewed the one-to-one relationship between player and PC. More importantly, however, troupe play techniques unlock a lot of unique opportunities at the game table.

Most notably, the constant shuffling of the current group creates a huge variety in personal dynamics and relationships. (You can get a similar dynamic with an open table. The distinction here is that you can get the same effect with a small, dedicated group of players who are sharing all of the experiences in common.)

Ars Magica notably uses the technique to create the dynamic found, for example, in The Hobbit: Gandalf is clearly a much more powerful character than everyone else in the adventuring party. Ars Magica solves the problem of, “Who gets to play Gandalf?” by letting everyone create their own Gandalf and then rotating who’s playing Gandalf and who’s playing the motley assembly of mortals each week.

Similarly, a Star Trek-style space opera can run into the question of, “Who gets to be the captain?” In troupe play, the captain could be a communal character shared by all the players (each of whom also has another bridge crew member as a PC). Each session, a different player gets to play the shared role of the captain.

Ars Magica also associated the concept of a rotating GM into troupe play. I think of this as actually being a distinct technique, but it does combine very well with troupe play. (Since the campaign dynamic already has characters constantly swapping and realigning, it’s easy enough for each GM to have their characters skip the adventures that they’re running.)

Eclipse Phase - Posthuman Studios

Essentially every character in Eclipse Phase has a personal muse: An AI that serves as their companion and personal assistant from the time that they’re a young child until the day that they die. Their persistent presence and collaboration in every facet of a person’s life is one of the transformative elements of the Eclipse Phase setting which creates the unique exotic flavor its science fiction.

As I mentioned when I posted my Eclipse Phase system cheat sheet a few days ago, however, it initially proved difficult for players to properly utilize their muses as an integral part of their lives. Literally front-paging the muses helped, but something I also started experimenting with was the idea of letting another player run the muse. Thus everyone at the table would control both their PC and the muse of another character.

The recent Eclipse Phase: Transhuman sourcebook makes a similar suggestion. There are multiple advantages: First, it forces the roleplaying relationship between the PC and their muse into the open. Second, it encourages the muse to have its own independent personality. Third, it can also make it a lot easier to split the party because many or all of the players who aren’t present may still have a muse to play in the scene.

As I mentioned a couple of days ago, however, I’m currently developing an open table Eclipse Phase campaign. Unfortunately, an open table disrupts the idea of having a second player run your muse: Since the players at the table are constantly in flux, there would be no guarantee that the player running your muse would be at your next session.

Loosely inspired by Shock: Social Science Fiction, therefore, I’m going to experiment with the idea that your muse is always played by the player to your left. (Basically a structured troupe-style play in which the muses form the body of communal characters.)

This obviously sustains the advantage of the muse always being portrayed by a separate player. The disadvantage, however, is that there would be a constant flux of different players portraying your personal muse (leading to potential continuity problems). To mitigate these problems, what you need is a quick briefing sheet that would introduce the new player to your muse. This needs to be insightful enough that the essence of your muse is communicated, but focused enough that it can be quickly assimilated at the beginning of the session.

Fortunately, I already have a template like this that I use when designing NPCs for social-intensive scenarios. I’ve tweaked it slightly to customize it for troupe-style muses. I think you might find it useful even if you’re not contemplating this style of play.

When designing your muse, I also recommend checking out “Maximizing Your Muse” in Eclipse Phase: Transhuman (pg. 166-169). There’s a lot of good ideas in there.

MUSE TEMPLATE

Name: Self-explanatory. As limited artificial intelligences, muses have their own identities.

AR Avatar: A description of the muse’s “physical” appearance when it appears in AR (or VR).

Altered Carbon - Ben MauroRoleplaying: This is the heart of the briefing sheet, but it should also be the shortest section. Two or three brief bullet points at most. You’re looking to identify the essential personality traits or mannerisms which will serve to unlock the muse.

Motivations: Like any other character, muses should have three personal motivations (Eclipse Phase, pg. 138). These may mimic, support, or even contrast the motivations of their owner.

Background: This is likely the only section of the briefing sheet which is likely to need frequent updating. I recommend a single bullet point for each significant scenario the muse participates in (and keeping each bullet point to no more than two or three sentences). The point isn’t to be encyclopedic: It’s to provide an essential overview of key facts. (If the muse’s current player needs clarification about something, they can lean over to their right and ask.)

Notes: A miscellaneous category of key information that wasn’t hit in the previous sections. For example, if the muse is currently holding the encryption keys for an important data store or is hiding the fact that they know what happened to their owner during a span of lost time, this is probably a good place to note it.

Stat Block: Include the muse’s stat block at the bottom of the briefing sheet for easy reference. Most muses will use the standard muse stat block, but they’ll still be customized by selecting three Knowledge skills. Some muses might be commonly housed in a bot (in which, case include that stat block, too); others, of course, may have received custom upgrades.

AURORA – SAMPLE MUSE

AR Avatar: A young girl with yellow hair so bright it seems to glow lemon. She usually has a cigarette drooping out of the corner of her mouth.

Roleplaying:

  • Refuses to take any shit from her owner, but is also fiercely protective of her.
  • Her owner cannot understand her obsession with celebrity gossip.
  • A dry, sardonic laugh that often breaks apart into a fake “smoker’s cough”.

Motivations: +Open Source, +Wealth, -Alien Contact

Background:

  • Aurora was originally licensed on the likeness of a child star named Sundrop. Around the time her owner turned 17, “Sundrop” got tired of that identity and started referring to herself as “Aurora”.
  • Aurora was actually the one first contacted by Firewall based on a research project she was working on for her owner.
  • Aurora’s owner deleted her and restored her from a backup that was three months old. Her owner refuses to explain what happened, which completely infuriates Aurora.

Notes:

  • Aurora was infected by a “dormant” strain of the exsurgent virus. It hasn’t had an visible effects yet, but she’s been spending her down time secretly researching a very strange and seemingly random set of topics. (List anything she researches on the back of this sheet, please.)

Aurora: Aptitudes: 10, INT 20. Skills: Academics: Psychology 60, Art: Simulspace Design 30, Hardware: Electronics 60, Infosec 30, Interest: Celebrity Gossip 30, Interface 40, Professional: Accounting 60, Programming 20, Research 30, Perception 30.

 

Archives

Recent Posts


Recent Comments

Copyright © The Alexandrian. All rights reserved.