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.
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).
Roleplaying: 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.
- 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
- 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.
- 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.