Making a tabletop roguelike - Part Two (Why TTRPGs?)

 (I had planned on writing another post for part two, but this is an interlude triggered by another Discord discussion, so here we are. You may or may not find part one useful).

It is always useful to tease out the assumptions of a thing you're designing  -- as an exercise if nothing else. Michael Brough for a while made an art of taking an assumption about roguelikes and turning that assumption into a whole game, whether it is character progression or inventory systems.

As I'm making a TTRPG, I've been slowly working through this myself - specifically "why am I making a TTRPG?". There's one straightforward answer: creating a tabletop role-playing game is extremely easy. Far easier than making a video game or board game. All you need is some kind of desktop publishing software, and a page on itch.io. And not only that, but you can be deliberately as expressive (glass of water as a hit point mechanic) and ambiguous as you want to be. I've spotted rule omissions in other pre-release TTRPGs, only to be told by the designer "Your play group can figure it out" and the beauty of the genre is entirely that you can. I've made a complete TTRPG from scratch and published it in under 2 hours.

"But how did you play test it?"

And that's the problem. Because the document as written isn't a tabletop role-playing game. None of them are.

Table top role-playing games exist in a space somewhere between board games, LARPs and their own unique thing - and they are hugely influenced and indebted to both. Inevitably I have ended up asking myself repeatedly "Would this be better as a board game?" or better as a LARP, and while I can try to answer those questions myself, I would expect other people to be asking those same questions and coming up with much more coherent answers than I could.

Let's start with the rules. Board games generally don't work if the players don't know the rules. But knowing the rules is the exception rather than the rule in the (traditional) TTRPG space. And while you could argue that more modern TTRPGs have tried to address this by simplifying the rules - these games can still work if you are entirely ignorant of them.

Well, if we're able to ignore the rules, there must surely be solid documentation about the practical process of playing the game. But it appears that LARPs do a much better job talking about this practice of play than TTRPGs do. The recent series on Dice Exploder about LARPs highlighted to me how sophisticated the thinking is in that space, whereas I can't see comparable writing about tabletop games (either board or role).

I think this is as a product of (paradoxically) how hard it is to get into the practice of tabletop roleplaying design. There is "no one place to go" because of the small size of the industry, and the way it keeps being shaken up by technology transformations out of its control. You used to be able to go to the Forge, then it was Google Plus for a while and now the majority of people have retreated to Discord, which has its own challenges for new entrants (being private by default, transient and moated to protect its communities -- attributes that are important to preserve those communities). Sure there is RPG.net, but it's much much clearer to me where to go for roguelikes (which are smaller again) or boardgames (which are bigger).

My recommendation as to where to start, after having spent a while looking, is podcasts: specifically starting with the Design Games podcast which does a great job going top to bottom on a specific design practice, then Dice Exploder which provides a zoomed in view of the history and practice of a single mechanic, then Read the Fucking Manual if you want to hear smart and thoughtful people with strong opinions talk about whatever they want to in the role-playing space, and around it.

So let's go back to my earlier bold claim that no tabletop game has ever successfully been written down. It's entirely impossible to enumerate all the circumstances a game can be played under, but in a board game, we can usually notice when the game breaks down because the rules don't work as written ("hey, you took my cards when I went to the kitchen for more snacks"), and in a LARP, a lot of work has been done to make sure that the game runs as intended ("the rules have been written in tears"). Tabletop games kind of fall in this weird middle between these two extremes, carried on the momentum of 50 years of playing D&D such that every other TTRPG is pulled along on its coat tails. But I think that's their strength.

You don't learn a TTRPG in isolation. You learn at the table. You watch actual plays. You learn go on to unlearn a whole lot of stuff that you learned when you change from one system to another. TTRPGs are accessible in a way that LARPs, and even board games aren't. Sure, there might be a need for a session zero, but there's no concept of teach the game the way that board games sometimes require. TTRPGs thrive on vibes.

Making a tabletop roguelike - Part One (Another Manifesto)

 (Or how I posted in a discord and got told by the mods to write a blogpost instead).

In response to me looking to get some TTRPG people onto Roguelike Radio, a fellow discorder Markus posted a link to his blogpost on Bringing Roguelikes to the Tabletop - a considered and well written piece on how to leverage some of the design tropes from modern roguelikes into table top role-playing games. It turns out this is not the first time someone has thought of this idea: another discorder (SamR) pointed out that the Old School Renaissance was in part inspired by an rpg.net post where a succession of adventurers lived and died in a procedural generated dungeon. Markus' argument (made on discord, in response to me) is that the key three roguelike elements (procedural generation, permadeath and system interactions) have already been incorporated by the OSR movement, and so examining repeated runs and metaprogression is more worthwhile.

I'm not going to pretend that I have encyclopaedic knowledge of the OSR genre (I believe I own one OSR game), but this struck a chord, because Sersa Victory - designer of OSR game Victory Basic, has adapted Unexplored's Cyclic Dungeon Generation into a tabletop version. Unexplored takes inspiration from Brian Walker's Brogue in many ways, but cyclic dungeon generation is unique to that game and an interesting innovation in procedural generation techniques. Unfortunately the algorithm is brittle and prone to failure states at many points (such as destruction or loss of keys), and I believe simpler and more robust dungeon generation techniques - such as adopted by Spelunky and Brogue itself - are generally more successful.

And SamR goes on to point out the more obvious problem with procedural generation in TTRPGS:

Meanwhile, procedural generation has fallen largely out of favor, because there’s an abundance of bespoke modules and referees can create their own content... Like the implicit promise of procedural generation is endless content that is nevertheless comprehensible. But any GM can create that no problem. [Ellipsis added].

So if procedural generation doesn't suit table top play well* -- and I'm not going to argue against a presumably more experienced wisdom of crowds --, what should a tabletop roguelike look like?

Rather than look at the modern roguelike, titrated and diluted through decades of implementation, I'm going to go back to our ur-text: Rogue, itself, to try to find some design principles that can define what a tabletop roguelike could be.

The first is a straight forward response to SamR's very excellent point. Glenn R. Wichman, Michael Toy, Ken Arnold and Jon Lane created Rogue because they didn't want to have to DM (whatever that mean - direct message? maybe email was too slow) and just wanted to play. A video game allows a set of constrained systems and rules to (mostly) safely operate for the player; whereas the explosive medium of table top play rules requires some kind of dampening effect like a carbon rod being inserted into the fissile material in a reactor -- a game moderator (GM) if you will (this is not a metaphor for sex maybe?). But this sounds like a lot of work and not enough play for one person (I suspect they should get paid). So any roguelike game is similarly going to forgo the need for this game moderator to allow everyone to play instead.

So a tabletop roguelike must be:

1. GM-less.

The second constraint naturally flows from the first. In a shared world, where everyone is a player, there is no authorial fiat: everyone must agree to the actions, outcomes and events (the systems). This is relatively straightforward in the game present because we can constrain situations of play to be within a specific space and time, but when it comes to backstory: it is too easy to create and miss contradictions in the wider world being made. So much like our Rogue, we are going to descend into the dungeon with a clear endpoint in mind (The Amulet of Yendor, in the original) and free of any past that might complicate this. The systems within the game may allow this past to be constructed, but we certainly don't want to play part way, and then realise we missed an important fact in a spin-off novel that negated everything we did.

2. No lore, one goal

(The easiest way to avoid the need for lore is to set the game in a modern setting -- any well documented historical setting would also suffice. The fantasy settings of OSR games might lean on D&D tropes enough to also apply -- certainly Rogue depends somewhat on this).

The third constraint will be where all the load-bearing design sits.

3. You can learn from your mistakes

You, as in you the player, not you the character. This is has many implications: the game systems must be complex enough that a simple solution is not obvious or (equally) random, but for which your gradual comprehension of the underlying rules and your capabilities as a player are of benefit. This also implies the possibility of an auspicious outcome instead of a steady descent into failure (even if auspicious simply means the last one to die, or the one to die most memorably). This also implies some repetition of systems, either through repeated play, or through enough similar scenarios that repetition dominates (but does not eradicate) variation.

Now I have sketched out the three design principles, it is relatively easy to cast around and find games in the same mold. I'll just pick three out:

Decaying Orbit - https://storybrewersroleplaying.com/decaying-orbit/

The Zone - https://thezonerpg.com/

Last Train to Breman - https://seaexcursion.itch.io/bremen

You'll notice pretty quickly that two out of three of these examples have at least one modern roguelike feature:

4. Cards

(Which I had planned on talking about in part two, but I got diverted to something else instead).

---

* I can think of two examples where procedural generation can still be successfully accommodated in GMed TTRPGs: scenario creation and character creation -- particularly life-path style character creation. In both instances the participant is essentially playing a solitaire game with its own rules and constraints that then feeds into the larger shared play.

Setting fire to everything

I've been thinking a lot about the season 1 finale of Sens8 recently. It's a great piece of writing, bringing together a gestalt of characters with different abilities to achieve a goal much in the same way a table top role-playing game might. The finale is (mostly) set in an isolated facility in Iceland, and to get to the facility, the protagonist drives up in a expensive sports car with streams of blue smoke coming out from under the bonnet, and sneaks in while the red-blooded, car-loving guards are all distracted by the tragedy of a high performance vehicle gone to its death to soon.

In a TTTRPG, who comes up with that idea?

If it's the players, then congratulations: you've got the perfect OSR group capable of creative solutions to challenges and the rules just really need to get out of the way to let you play. If it's the game master or scenario designer, then that feels like there'd be the need for a lot of prompting for the solution, which might be hand-waived away with a couple of action checks.

But it's also probably not the first isolated facility you've had to get to, and it's definitely not the last. So how many times do we allow this technique to work? Maybe its not an isolated facility, but its a checkpoint in Gaza, and its not the first check point you've got to, but the fifth that day and you're going to have to go back through them in the other direction later on in the evening.

This is where the game designer steps in. We tend to focus a lot on the action check as a resolution mechanic, because its (usually) flexible and generic, and giving the players verbs to use are a really good idea, regardless of the medium, but action checks work best when situations are dynamic and the player's actions are varied and impactful (like combat); and less well when situations are repeatable and player influence on the outcome is limited.

I'd like to call this type of scenario an activity, to distinguish it from an action. Activities have repeatable outcomes, with limited scope for improvisation (or where we may wish to limit the scope for improvisation for thematic reasons) and are often tied to and reinforce the game's themes. Downtime is a good example of an activity. You get some points, spend them on some stuff, roll for some good or bad things to happen, and then get back to the important part of the game.

But activities should be in the important parts of the game as well; I'm just not sure they're designed as effectively. I've been thinking about the Sens8 scenario, because that corresponds almost exactly to something that comes up in my TTRPG Sixty Years in Space a lot. Arriving at a planet, asteroid or moon is almost exactly the same as arriving at an isolated facility: everyone can see you coming from a long way off, they have plenty of time to do something about it, and you need to turn up with a very good reason for why you're there.

Because we're doing this a lot, the players' first, smart idea of enforcing gun boat diplomacy on every world they go to is going to get repetitive fast - and may not fit in the themes of the game you're trying to create. But we don't want to hand waive away the impact of arriving at a site that you're not necessarily welcome at: instead we probably want to deal with a spectrum of reasons for turning up and responses. This feels like a perfect activity: at a minimum we'll construct some kind of list of things that a typical arrival goes through (are you travelling fast enough to explosively collide with your destination?, can they see whether you have weapons or contraband, what does customs think of you, do you need to quarantine for a while because the bug hunt you came from went a little awry), along with some skill checks to overcome some obstacles that may be put in your way.

But most players don't want to fill out a check list or a clock: they want to role-play. So maybe you decide that the activity should be a scenario: sitting inside your locked down ship while you wait to find out if any of your crew got replaced by a brain-sucking parasite sounds like a perfect sci-fi horror RPG. But it doesn't make much sense if you're delivering a cargo of fresh oranges. Hopefully the orange delivery guys like checklists more than the oopsie we did another Alien guys.

Or maybe you don't want to deal with this at all, and decide to just put a cut scene in, or a fade to black, and hand wave it away completely. Those are fine, but as a game designer, I like making systems more than scenes or scenarios.

I know of one way of creating an activity that's more complex than a check list, and more repeatable than a scenario - and so does every other board game designer. Because that's what I'm suggesting. If you can turn your down time or check list or clock filling exercise into a physical or logical map of a space with some rules for how you navigate it, then players will start to lean forward and engage with it in a way that elevates the experience. It might be as simple as a map of the space port, with the list of places that you have to go in order to get the paperwork completed to get past customs. It may be a combat system. It might be fire fighting rules.

I'm going to repost the TTRPG map making manifesto that I've posted elsewhere, because I think point 3 is especially relevant for the role-playing experience:

1. Put maps in your game for the players to use, not the GM

2. Make the maps force the players to make meaningful decisions about where, when and how to move on them

3. Have rules that make the players talk about the map the way that their characters would talk about the map

I'm still figuring out how best to use this idea. Sixty Years in Space has activities that drop tokens (dice, counters) on the map that have multiple meanings in different contexts (activities), but the overhead of each activity is quite high because they could all potentially interact with each other which means I have to keep scales and effects in line with each other.

I suspect the best way to do this is have different maps for different activities which have the same verbs so that players don't have to relearn the rules for each activity every time. Think of lock picking and hacking mini-games where the layout of the lock or computer system determines the approach you take, but the actions you use are consistent every time. Sixty Years in Space does the reverse: it has the same (High Frontier) map, and then gives you a whole lot of different actions you can perform on the map. And I keep adding them. The next update will feature a whole espionage game where you develop your contacts into agents on the map and then use them to enable covert operations and exfiltrations. That's a more verbs and more ways of reading the same map. This may be a cursed problem.

Sixty Years in Space 4All

One of the wild design decisions I made with Sixty Years in Space is that it's rules compatible with the board game it is based on. Not only in the sense that it uses the same terms and units (in both senses) as High Frontier, but in that it could get to your turn in the board game and you say "hold up", assemble a group of players to form your crew, sit down and play the roleplaying game from the game state on the board and after a year of in-game time, the outcomes will be compatible with having played your year-long turn in the board game. That is, the odds of prospecting a site will be the same, building a factory has the same requirements, printing space craft components will take as long and so on.

That's all well and good, but I based the Sixty Years in Space on the 3rd edition of the board game, and during the intervening 12 years, a 4th edition got released, High Frontier 4All. And it significantly changes some core concepts: specifically Space Politics (but also promotions, Bernals, spacecraft components, colonists etc).

Space Politics is a core part of the Sixty Years in Space game: it touches almost every aspect of procedural generation which means it's woven amongst all the rules. I've always had it in my head that I'll end up making a High Frontier 4All version of Sixty Years in Space, but I've never gotten around to it because of the effort required to maintain what amounts to two separate editions.

Fast forward to today: I'm now working on a lite version of Sixty Years in Space called Epic Hazard Operations. When I say lite, it's still going to be completely rules compatible with Sixty Years in Space. What's lite about it is the theme. It's set in the era (the Exoglobalisation era) that makes sense to have combat and space dungeons and professionals exfiltrating technologies from other colonies. It'll still have you building factories and colonies and moving about the solar system: but you'll be doing it with much simpler rules (freighter movement) because you'll be playing as a minor faction stuck on a "dustside" on the edge of space -- and the building is done by dedicated players called exoarchitects who sort of act like game masters except you can have lots of them. And it'll have a much more traditional class and/or life path system that you'll use to create your crew.

Because I can never do just one thing, Epic Hazard Operations will also be an expansion for Sixty Years in Space, subtitled A Facility with Words, which you already possibly own and which will contribute a significant chunk of to Epic Hazard Operations rules. I'll be doing the same PWIW release of the remainder which will form part of a new supplement, All Terras are My Own.

And I think I'm in a position where I've solved most of the compatibility problems between the two games. The 4th edition version of Space Politics are going to correspond to the faction doctrines. I've already solved how I'm going to make promotions compatible; anchoring Bernals was an idea I'd already borrowed from the 4th edition and so it's a more straight forward addition; colonists never really worked in Sixty Years in Space the way they worked in the 3rd edition so they're not going to change at all; and some of the new stuff in the 4th edition (like delegates) are going in relatively seamlessly.

ETA for the first release is around September, which will include update 5 for the remaining rules.

Update 4 for Sixty Years in Space is out

Update 4 for Sixty Years in Space is now out. This update is focused on completing the colony administration rules in (A)-Base (D)-Landing and expanding the counter and dice "vocabulary" used across the game. The (A)-Base (D)-Landing supplement is now also priced at the same pre-release price as all the other supplements and core rules; but if you contributed $60 or more to buying the core game rules, you now get it for free! The colony administration game is the most board-game like of the any of the rules I've written for Sixty Years in Space and focuses as much on the social stratification of your growing population due to housing insecurity and inequality as it does on the mechanics of ensuring that you have enough food and labour to keep the colony running. You can read the full release notes here.