Hey there folks! Aidan here.

I'm getting back into the mindset of working on Tabletop stuff, and was recently reminded of something I drafted up a while back regarding how to approach the design of a system. The idea was to come up with "system requirements" for TTRPG games, basically an analog for how a computer game might have certain demands on hardware to run properly. This wasn't meant to create a list of things you HAVE to have or your TTRPG to run poorly, but more of a thought experiment into what might be a problem with the design of a particular tabletop game, and what steps can be taken to mitigate them. This will make more sense once we get into into it, so hear me out.

What are "System Requirements"?

System requirements are the harware components needed to run a specific piece of software. Since a PC game doesn't know what hardware configuration a use will have, developers will look a their software and outline some specs you should meet in order to ensure their program runs as intended (ie, if photoshop tends to consume 16 gigs of ram when it's running, having 8 gigs of ram installed is less than ideal). This shouldn't be new information to anyone familiar with video games, but sometimes a game has to be shipped with limitations in order to fit specific hardware, such as when deploying to a handheld console that doesn't have the processing power of a PC.

Tabletop games as a Computer System

Tabletop roleplaying gameplay is, generally, one Dungeon Master running the game, and three or more players who, through verbalized actions, progress the game. From a computer archtecture standpoint, we can already draw a comparison to the Server/Client relationship used in multiplayer games, which have their own design considerations different from singleplayer games. We can also make note that the work the game requires from a Dungeon Master will be different than the requirements for a player. Ultimately our goal is to create a game which runs smoothly for the players and DM, but what exactly are the points of friction that could turn a well designed game into a poorly designed one.

Storage / How Many Manuals

In a video game context, storage is measured in the products file size, or in simpler terms, how much of it there is. In a TTRPG, storage can be thought of as the rules or other written materials for the game. A game with a high storage requirement would be a game with a high page count, multiple manuals, or any other reference materials. We can consider Dungeons and Dragons to be a "high" storage game as it can require three or more manuals to play. On the other side of the spectrum is Risus, which only has one page of rules. We should make note of the obvious observation that the larger the storage requirement is for a TTRPG game is, the longer it will take to find specific elements like rules, creature stats, or random tables. This is not unlike how games with a high storage size can encounter loading issues when trying to retrieve and deploy assets.

CPU / Rule Complexity

The central processing unit is the hardware component that handles most of the game logic and other aspects of "running" the game. In a TTRPG we can think of the CPU as a person's ability to resolve game mechanics or retrieve information from a rulebook (storage). A TTRPG game with a high CPU requirement would be games with multi-step resolution methods, probably with lots of conditional modifiers or references to rulebooks to retrieve results (ie, if instead of one attack action, there are 35 similar but subtly tweaked variations that require a rules lookup). A low CPU game will be any of the "rules lite" systems with simple resolution mechanics. Warhammer is a good example of a high CPU game, since resolving an attack takes multiple dice rolls and character specific modifiers, while a more freeform RPG game will likely use the same dice roll resolution method for every check.

RAM / Short Term Memory

Random access memory is the part of your computer that is used to temporarily hold onto information while executing a program. In a TTRPG, we can think of RAM as the player's short term memory. Games with a high RAM requirement will require the player to keep track of a lots of details during play, and have an understanding of how their chatacters unique abilities work. A game with a low RAM requirent is one where the player doesn't need to consider many elements of the game other than what is currently occuring. For example, a game of Dungeons and Dragons 4th edition can have players adding lots of modifiers to their dice rolls, often overwhelming new players before it's even their turn. A game like Everyone is John however, only expects the player to keep track of two skills and goal.

Graphics Card / Imagination and Visualization

Graphics Cards are, as you might expect, the element of the hardware responsible for visualizing the graphics of the game. In TTRPG this can be thought of as the groups creativity, or ability to improvise. Another high graphics demanding example for a TTRPG are titles which rely heavily on battlemaps, positioning, or other visual aids. Tabletop roleplaying games will obviously all have elements of improvisation, given the medium, but the battlemaps are the primary friction point for progressing a game. Consider a traditional dungeon crawl, where a DM needs to take frequent breaks to draw out a map on a dry erase board, compared to a game using the 2d20 system where all that matters are things like "you're in the same room" or "you are standing in melee with these characters". Virtual tabletops have someone mitigated the battlemap time sink, with DM's being able to prepare maps in advance and deploy them as needed, but setting up those maps is still work that needs to be done, even if the players don't have to wait for it in real time.

Network / Communication

The network requirements for a game would be the internet speed for reliable play. In our TTRPG game, we can recall that we're talking about something similar to a client-server archetecture, so we can think of the network requirements being how frequently the players have to send "requests" to the Dungeon Master, and what that interaction looks like. For example, in a d100 system, players are able to resolve most rolls and determine if the succeeded or failed independant of the Dungeon Master, while a d20+ modifier system follows a ask/response resolution pattern from the player saying what they want to do, to the dungeon master saying what type of roll is needed, followed by the player informing the DM what they rolled, followed by a confirmation on success or failure from the DM, and then potentially followed by the player informing the DM of how much damage they've dealt. A game with a high Network command will have lots of asking/clarification between players and the Dungeon master, while a low network game will require little verbal interaction for mechanical resolutions.

Lag

With these requirements clarified we can think about what an undesireable state during game might be for a player, Lag. In a computer game, lag can manifest from a variety of sources, but generally results in the game slowing down, or pausing. An instance of Lag for a player could be any time they're attempting to perform an action, but need to look up a rule, or they are waiting for someone else to stop talking.
Players are going to experience moments of inaction during normal gameplay, like when waiting for another player to do something, but generally will self-moderate to their personal preference. However, moments where this is overriden by game mechanics is when it becomes important to making sure the game performs well. For instance, idle states will naturally occur during a turn based game as players wait for their turn, but these idle times can also be spent preparing for their turn by looking up their spells, abilities, or listening and engaging with the other players at the table. A common case of lag is when one character (usually a spellcaster) isn't prepared for their turn, and needs to lookup rules or resolve a complicated ability.

Case Studies

To illustrate this analogy further, here are a few different games, and what viewing them through the lens of "system requirements" might look like. I find this is a useful exercise to help identify what a game's system is strong at, and where potential issues could arrise

Everyone is John

"Everyone is John" is a free TTRPG where the players are all playing the same character, named John. Players are competing to make John complete individual objectives and earn points, and games tend to last one or two hour long sessions. Skill checks are resolved by rolling a 6 on a d6, or rolling a 3+ if the check is one of their "skills". Only the active player has input on the story, but "Control" of the character is shifted win a player fails a roll, completes an objective, or "does something boring". Control is switched by players betting "willpower" with the player who bet the most gaining control. when all players are out of willpower, the game is over.

Component	Specification
Storage	Low, Core rules fit on one page
CPU	Low, Mechanics are simple and only ever rolled by players, dice rolls are unmodified
RAM	Low, Characters only need to keep track of 4 attributes, 3 of which are static and do not change during play.
Graphics Card	Low-Medium, being a freeform game, the character could end up anywhere doing anything, so player creativity pulls a lot of weight in making the game run effectively. however, no battlemaps or visual aides are required.
Network	Low-Medium, Only one player and the Dungeon Master will be communicating at any given time, but lots of back and forth is required to run the game effectively.
Remarks	EIJ has potential for long "Idle" states of players due to the "one active player at a time" approach of the game. This is mitigated by the frequent switching of "control", but shy players might not opt to gain control as often as more aggressive players, leaving them idle for longer periods of time. Dungeon masters or players who have difficulty with improv, particuarly with switching situations and objectives, will find periods of "lag" where they need to take a pause and think about what should happen next.

Dungeons and Dragons, 5th Edition (2014)

Dungeons and Dragons 5th edition is the classic TTRPG where players are heros embarking on quests. Skills are resolved through DM determined D20 tests, with player specific spells/abilities as needed. Game as designed is best suited for dungeon crawl adventures, though actual playstyle and setting can vary wildly between play groups.

Component	Specification
Storage	Medium-High, Depending on rulebooks used and class/race played, character complexity can vary. Official Adventuring league suggests a "core +1" approach, meaning the core 3 rulebooks, plus one optional module of supplementary material.
CPU	Medium-High, While the system has the potential to be demanding, players will tend to self-sort into the complexity they are comfortable with. Spellcasters in particular are examples of a High CPU player, and a barbarian or fighter ending up as a "low-medium" demand. For a Dungeon master the CPU requirements will be higher than a player, just due the nature of having to check rules for resolutions.
RAM	Medium. Most effects in game are resolved as they happen, and there aren't too many ongoing effects or rules that need frequent remembering. This requirement starts on the high end of medium as new players need to learn common gameplay flow (how to perform a turn, for instance) but lessens as they become more familiar with what they can do on their turn.
Graphics Card	High. Dungeons and Dragons is one of the few Roleplaying game what puts an emphasis on grid based combat, nessesitating the need for battlemaps, miniatures, or other visual aids. Ironically, choosing not to use a battlemap can put strain on other aspects of the game, as players need to remember where they are in relation to other creatures, clarify with the dungeon master as to where they're going and what they're trying to do, and re-update their mental picture as other players change the scene.
Network	Medium, back and forth discussion is required to run the game effectively, but is manageable.
Remarks	5th edition is often praised for it's design, and with good reason. Despite it's potential for high complexity in certain aspects, a number of smart design choices mitigate moments of lag and guide the player away from common friction points. For instance, Spells are catagorized by level, school, class spell list, known spells, prepared spells. This catagorization reduces the number of attributes a player needs to look through at each step, meaning they don't need to know all 300+ spells, only the 4-5 their character knows.

Conclusion

The "TTRPG Systems Requirements" are just a way of analyzing your game and looking for things which might slow down the game. What is valuable about this thought process is though, is that it lets you identify how your game might play at the table, and what things you may need to tweak to fit your design intent. A game with a high systems requirements doesn't mean it's a bad game, it just means that it might take a while to do things as written, which fits the pacing for systems heavy in resource management. Similarly, a rules-light game might be quick to run, but if everything just comes down to a coin flip to see if you can do something, that isn't much of a game.

Hopefully this was helpful, or it wasn't, hopefully it was entertaining. As previously mentioned, I'm working on a new TTRPG system now, and have been looking into dice probability. If you're at all interested in the approaches used in different roleplaying games and why they are the way that they are, that might be of interest!