The Progeny Crowd Sale
Before I get into the meat of this post, I want to remind everyone that the Crowd Sale for The Progeny (free rules available at the link and paid subscribers get print & play access to all of our Microgames) starts on September 12. Follow the project on The Game Crafter to be notified when it goes live.
Origins of The Progeny
The Progeny started as a game jam entry as a design experiment for the ideas I’ve had around solo and Wardenless play in addition to working out larger design ideas for Orgy of the Blood Leeches. These larger design ideas and ways to play solo and Wardenless have also expanded beyond just Orgy of the Blood Leeches as I discussed in my announcement for Advanced Rules. I’ve been working on Orgy of the Blood Leeches for over a year now, and it’s required me to start the second large project Advanced Rules and to design and put out The Progeny as a Microgame, so I can work out workflow and ideas in a smaller, lower stakes space than Orgy of the Blood Leeches, which is the module that I have wanted to make since I started playing Mothership.
The Beginning of a Series of Design Notes
This newsletter entry marks the start of a series of design notes. I discuss how something appears in the The Progeny, and then I will share a larger discussion of adapting this to Mothership 1e to Advanced Rules after playing with the ideas in The Progeny. It’s a transparent view of my workflow and design process. These notes will include the following topics in upcoming newsletters:
Dynamic Tables
Dice AI
Generating Contractor Personalities
Grid Maps in Mothership
Zones in Mothership
Contractor and Encounter Stacking in Mothership
Solo and Wardenless Play Procedures for Mothership
Dynamic Tables
This entry is close to my heart because it's something that I've been processing for a while. This topic is what I've decided to call Dynamic Tables. If you're playing a game solo or wardenless all of the information is available to you from a module. Hidden information is going to produce surprise or unforeseen situations, and this can be boring. You can procedurally generate areas as you play, but that doesn't really cut it for me either because I vastly prefer to have a well made map that represents a situation. Traditionally, there are monster tables and treasure tables and sometimes you can see an interesting combination of them in the form of the overloaded encounter die. Dynamic tables are a variant of this.
When I first started playing and designing for Mothership, Emmy's Derelictcrawl Procedure was highly recommended and seemed to be used a lot. It uses an overloaded encounter die in the form of the d20 Panic die used in Motherships. It allows a party to explore an area with rooms using dungeon turns, and the Warden rolls the Panic die whenever there is an exploration turn. It breaks the d20 table down into broad effects: Panic, Encounter, Horror, Setback, Locality, Clue, Free, and Regroup. These are the general types of actions a Warden would take, but it takes a little bit of the burden off of the Warden. However, it still involves the Warden making up quite a bit on the fly and isn't specific to any module. It also supposes secret information for whatever is in a room. This is a tremendously powerful procedure, and I've included a variant in my published module, Slasher. However, my mind was blown when I published The Great Crossing Heresies for Chris Airiau. That pamphlet adds a counter to a table with events called the "Haunting Table." It's specific to the module and what is interesting about it is that as the counter goes up, it takes away options since you add the counter to the d5 that you roll to select an entry to the table. This builds pacing into the table, the longer you play, the more likely you are to encounter something more horrific.
Dynamic Tables combine the Derelictcrawl approach with Chris's module specific counter based approach. You can see an example of a Dynamic Table in action in the free rules for The Progeny. For a Mothership Dynamic Table, I base everything around the dice that are already used in Mothership, so a d10 and a d20. A Dynamic Table takes the form of a d30 table. You use a d10 as the turn counter, and you always roll the d20 whenever you enter a room unoccupied by another friendly. This is why a Dynamic Table has 30 entries. When you start and the counter is at 0, your only choices on the table will be entries 1-20. When you max out the turn counter at 10, your only choices are for entries 11-30. This is important because it lets you set the pacing. You can use the same idea from the Derelictcrawl procedure, but make it more specific to a module. specify the horror, require a Panic check and increase the counter, find an item when you search the room, have places to rest and recover stress, and find clues. By ordering these types of things in the table, you can control when they happen. If you don't place any encounters early in the table, you are ensuring that there will not be any encounters early in a session. If you place encounters entirely at the higher end of the table, you can build in escalation to violence. If you intersperse encounters throughout the table, you can make something with a more even chance of violence. By adjusting the frequency and order of what's in the table, you can build a picture of how to play through a session. Since you're rolling only when entering unccoupied rooms, it also makes players venturing away from the party a risk since then you're rolling on the table, possibly causing Panic or causing an encounter to spawn multiple times instead of just once if they players are moving together. This works really well in combination with the way to use Grid Maps that I will discuss in a later newsletter. Each time you enter an unoccupied space, it triggers a roll. This allows for it to operate almost like a video game where you trigger events by entering spaces.
You now have a method that gives randomness and structure, so you can play through solo or wardenless and can still be surprised. Even though you can see the table, it just gives you knowledge of the likelihood that something will happen, but you don't when or if something will actually occur because it is a roll. You are kept on your toes, and you can play through a session with pacing that approximates a Warden. The game ends up Wardening itself, letting you focus on problem-solving and gameplay without a position of authority at the table, the table is the authority.
If you're designing a module that’s not even designed to be solo or Wardenless, this is still a great way to build a table for an area, because the table gives Wardens a really clear picture of how you envision the scenario playing out without being too prescriptive. Even if they don't use the procedure as written, they have a very clear picture of the pacing and the types of things they will encounter. It can let them know where creatures spawn, if they should spawn in the same room as the players, or if they are spawned randomly as a more wandering monster. You're able to make your intent clear without being heavy handed. Even if running a module as a traditional Warden, I appreciate the kind of guidance that a procedure like this gives me. I'm a teacher, and I always develop a really rough outline for facilitating a lesson, and then I bounce back and forth and adjust on the fly. A Dynamic Table gives the Warden this kind of a plan, not a railroad with text boxes to read.
However, if you want to convert an already existing module that does not use a Dynamic Table, there is some work to do. This is part of the work of the facilitator role that I will talk about in further detail in another newsletter. In short, the facilitator will need to work through the module, gather maps, and construct the table with the right items, spookiness, downtime, and encounters. The facilitator has to think about how they would run the module as a Warden and then codify it in the form of the table. However, this is all front loaded, so when it comes to actually playing at the table, the facilitator is able to actually play and assist others with rules without having to be an arbiter of rulings. This is why they are a facilitator and not a Warden.
Solo and Wardenless First
The suggestions for building stock Mothership modules using solo and Wardenless tools fits with how I have started thinking solo and Wardenless first when designing a module. A Warden can paper over a lot of holes in a module, but if you’re designing it to be played without that kind of assistance, I feel like you end up with a module that is stronger in its fundamentals and legibility. You have to think through exactly how something would play out more, and it makes it easier to playtest by yourself before something is ready for a more public appearance. Solo and Wardenless first will also continue to be discussed throughout these newsletters leading up to and going through The Progeny Crowd Sale.
Links
I also have a couple links to some other fabulous crowdfunding events that are happening over the next couple of months.
Outsourced: The Luko Fin Corp Deception for Mothership 1E
This is a corporate escape module by Spicy Tuna RPG with art from Evangeline Gallagher, an adventure by Christian Sorrell, and solo rules by Alfred Valley.
This has a great team and some wonderful art, and I will be featuring a mini-interview with Marco Serrano from Spicy Tuna RPG in an upcoming newsletter.
This is a massive bundle with a lot of content and a huge roster of Mothership Designers including Ike, Chris Airiau, and Christian Sorrell.
The Lost Bay RPG - This is more of an early look, slow funding project that is also from Iko and is fantastics.