Architecture & Dragons
RPG Rules, Software Systems, and the Craft They Have in Common
I’m a “forever GM.” If you don’t know what that means, let me back up and explain first that I love roleplaying games, and in specific tabletop roleplaying games. Dungeons & Dragons is probably the game most people are familiar with; even before Stranger Things, if you’d heard of RPGs you most likely had heard about D&D, although there are literally thousands of different games out there offering different experiences. I’m the guy at the table that is always up to be the “Game Master,” orchestrating rules and adventure ideas for the entertainment of the rest of the table, and that’s a pretty thankless job, so people who are willing to do it often keep doing it. They are “forever GMs”. That’s me. Ever since I ordered copies of the core Dungeons & Dragons 2nd Edition books back in the late 90s I’ve run games for people. It wasn’t too hard to get some rural junior high kids interested; when you were an hour from a movie theater, the “theater of the mind” is pretty compelling. In 2000, all of my friend group jumped onto buying the $20 printing of the D&D 3rd Edition Player’s Handbook so we could all play, but I was still the GM. I’m the GM because I want my friends to have fun and to experience ideas that I find fun. To share the joy.
Over the last 20+ years, I’ve read a lot of roleplaying game books and manuals... in fact, I’ve read more than even most Game Masters would. If you look over my reading list, you’ll see that I read more RPG books in a year than I do fiction, and nearly as many as I read for work! That is a bit excessive, even for someone in the hobby; I could just read the book for whatever game I was running and call it a day. Let me also explain for those who needed to learn what a “GM” is... these books aren’t always entertaining on the surface. Sometimes they have shiny art, but really, the core of the text is basically rules about make-believe for adults. Sometimes in excruciating detail or frustratingly too little. I love it.
I think that those rules and what they represent are fascinating in and of themselves as examples of design.
System Mastery
The design of any product, RPG, software, or soda can, is based on decisions made from many options to create what you hope is a cohesive outcome, but I think that RPGs and software have a huge overlap that is probably why I find both so fascinating. Both are attempts to model a “real” world in a way that captures the necessary elements and ideas well enough to support lots of scenarios with limited resources.
It is, of course, self-evident that RPGs are designed. They aren’t conjured up from hell as some of my early teachers might have thought. One or more nerdy humans decided that they had an interesting idea for a new or better game that they thought would be fun, and who wanted to share it with other gamers. To that end, RPG designers have to start making a lot of decisions about what kind of game the rules will support, how those rules will align with or express certain ideas to work with or against the gameplay, and what kind of choices players will have in the game. Once that work is done, you have to realize that a rulebook isn’t just the rules, it is also a book. It has to be written well, and in such a way that it supports the rules and the reader. It has to have graphic design, layout, and even custom art... it might be even more complex than just writing fiction.
Those design considerations overlap a lot with software engineering. Someone (maybe a product manager) has an idea for a new or better product, and engineers go to work figuring out what code and infrastructure will need to underpin this software to support this idea. That code is the rules by which the software will operate, and those decisions will shape how the software can evolve over time. Like a book, most software isn’t just the code either; it has graphical interfaces and human touch points that need to be designed in such a way that the users understand the underlying rules of the system and cannot just operate it, but predict how it will behave (an idea called “system mastery” when applied to RPGs).
What might seem worlds apart are actually two similar ideas: the things your system encodes as rules be rooted in what matters to those systems and then shape the direction of those systems as they grow.
The Character Sheet
The first thing any good software architect will do with a new project is to ask questions. Hundreds of questions. The second thing they will do is attempt to create a model of the domain they work in and the entities within it. Entity-Relationship diagrams are one of my three favorite diagrams because they help codify and talk about all of the things relevant to the project. That model defines what the system can do, at its core. If your model includes a Customer object, you can assume that there are customers and that your system cares about them. If there isn’t a Car object in your ERD, then it’s likely that automobiles aren’t particularly relevant to the domain of your software.
This focus stood out to me in Dune: Adventures in the Imperium. I love how the system designers used the game’s “domain model” to support the concepts of their universe. If you look at games like Dungeons & Dragons, player characters are modeled with the iconic attributes of Strength, Dexterity, Constitution, Intelligence, Wisdom, and Charisma. The things of epic sword and sorcery adventurers. In contrast, while Dune does feature conflict, its setting is much more driven by political intrigue and conflicting motivations than combat prowess. Dune instead centers its characters on “Drives,” Duty, Faith, Justice, Power, and Truth. These Drives are the moral focus and beliefs of the characters, and players use these scores to power actions based on how those actions align with their character.
That is a really important domain modeling decision. Dune players know that they have to be able to talk about their character’s morality and that their physical attributes don’t matter. They don’t even exist. If there is physical confrontation, what will matter is that the character is motivated by their sense of Duty or of Justice, or whatever they are feeling in this fight. The rules reinforce the type of game the designers set out to build.
Murder Hobos
A software system or RPG experience might be influenced by the underlying models, but neither is a static products; the people interact with those systems and learn how to work within the rules they provide. This too is something the designer must account for, because there will be natural consequences, intended or not. In the case of Dungeons & Dragons, one of the unintended ways that players have learned to work with the system is to be a murder hobo.
A “murder hobo” is a player who tries to maximize the rewards of the system (equipment and experience) by having their character treat everything in the world as a challenge to be fought and looted of its treasure. Because character equipment and their level dictate strength and advancement in that system, murder hobos have cut out other considerations to maximize their advancement and “game the system.”
On the other hand, the RPG The Wildsea rewards players in a way that discourages murder hobos. The setting itself has some superficial resemblance to a world that could be run with Dungeons & Dragons’ ruleset; action packed high adventure against mysterious monsters and delves into lost treasure hordes, but gear and experience aren’t emphasized in the same way. In The Wildsea, important items are part of the character and everything else is just salvage. Players advance their characters by collecting “Milestones” which are memories tied to events in their adventure (whether slaying foes, solving mysteries, or advancing relationships with friends) and assigned at a regular rate that can’t be rushed by killing extra monsters. It’s a strategic design choice that encourages players to approach play differently than in D&D.
Software architects are very familiar with attempts to game systems. Even if you missed out on the era where everyone wanted to “game-ify” software platforms, it’s always been true that “you get what you measure.” Engineers and product managers have to think very carefully about what things are reported and measured in their system, particularly when rewards or reprimands are attached, or the system users will find ways to maximize those scores while minimizing work. For example, an engineer I know works with a ticketing system for their work that tracks how long tickets are open, flagging those support members who have overdue tickets to their boss. In this environment, a few support people figured out that they could avoid being caught with the hot-potato by reassigning the ticket to others so that they wouldn’t be assigned the ticket when it expired. They might not be a murder hobo, but that certainly isn’t going to win them favors with the team.
Session Zero
Lots of products are designed. What separates the good ones from the mediocre ones isn’t the presence of design decisions, it’s the coherence of them. The decisions align. They reinforce each other. They tell the same story from different angles.
In addition to the prior examples, both The Wildsea and Dune do something I don’t think is a coincidence: both games begin not with character creation, but with group creation. In The Wildsea, players build their ship together before they build their characters. In Dune, they define their Noble House. In both cases, individual characters emerge from a shared context the whole table owns. That is a strategic, structural choice that shapes the tone of play, the kinds of stories that get told, and the way players relate to each other and to the world before anyone has rolled a single die. They then go further by choosing other mechanics like Milestones and the Drives that further refine and support that strategy.
Strong product strategy makes the same move. Defining your brand identity, your core user, your product’s reason to exist; these aren’t marketing exercises. They’re structural decisions that make dozens of downstream choices easier or unnecessary. When a team is constantly debating whether a feature belongs in the product, that’s usually a symptom of a missing center of gravity, not a missing feature. The best designs in both fields don’t just make good individual choices. They make choices that cohere, pointing in the same direction and reinforcing each other all the way down.
The Long Campaign
RPG designers and software architects are solving the same core problem: how do you build a structure that produces the right outcomes without specifying everything in advance? The rulebook can’t enumerate every player action. The codebase can’t anticipate every user. Both designers have to accept that the structural choices they make will govern far more than any individual rule or feature ever will.
The Wildsea doesn’t have a rule against murder hobos. It doesn’t need one. The Milestone system makes that behavior structurally pointless. Dune doesn’t tell players to care about politics more than combat. The Drives make political and moral engagement the only lever players have. The designers didn’t write their way to the outcomes they wanted. They built those outcomes into the structure, and the structure did the work.
I don’t think most people really appreciate how these very deep, often technical, decisions guide everything afterward. The structural choices underneath aren’t just supporting the product. They are the product. What your system measures, what it rewards, how it models the domain it operates in; those decisions determine what the system produces at scale more reliably than any feature list ever will.
That’s what I’m looking for when I read a rulebook. What they chose to model, what they left out, and what they decided to reward. It’s the same thing I look for in a well-designed system at work; what are the strategic underpinnings of the product, and how well does the solution model and support that direction. That is why I stay up at night reading rulebooks.
