TTRPG Systems Design 101

Now with additional electrolytes! (meaning I did a full edit pass recently: 8/21/25)

By Klok Kaos (2022), Project Chimera: E.C.O. Lead Designer

Legal

You are free to:

copy, distribute, display, and perform the work

make derivative works

Under the following conditions:
Attribution: You must attribute the work in the manner specified by the author or licensor.

Noncommercial: You may not use this work for commercial purposes.
Share Alike: If you alter, transform, or build upon this work, you may distribute the resulting work only under a license identical to this one.

For any reuse or distribution:
You must make clear to others the license terms of this work. Any of these conditions can be waived if you get permission from the copyright holder. Your fair use and other rights are in no way affected by the above.

Full Legal Information HERE.

Attribution:
TTRPG Systems Design 101 by Klok Kaos (2022), Project Chimera: E.C.O. Lead Designer.
Please provide a digital link in digital references to this page or a printed link on printed references.

This guide is not sponsored in any way by any of the mentioned products.

Introduction

There are many schools of thought in TTRPG (tabletop role-playing game) design. Opinions, theories, philosophies, and patterns are plentiful, but few give you a concrete list of steps to begin making your own game. That is what this guide aims to provide, a simple structure to help you start shaping your design.

This 101 is not a full course with a beginning, middle, and end. It is a crash course meant to point you in the right direction, built on what I have found to be reliable advice. It reflects the general wisdom I wish I had when I first started. It does not give direct answers, but it does highlight questions worth considering when creating your unique play experience. Your learning should not stop here. This is a primer to get you moving and up to speed.

The idea began with my own frustration. When I started, there was no resource that organized what should have been simple to learn. I studied everything I could and kept notes. Over time, those notes grew into this free community resource, which I continue to update whenever I find new, useful information.

This is not a deep dive. It is only meant to get you started and reflects the state of the industry at the time of writing, first in 2022 and updated through 2025. Game design is iterative. Tools, concepts, and even the idea of what a TTRPG is will continue to change. This means the process outlined here will eventually become outdated and serve more as a historical snapshot than a practical guide.

-Klok Kaos

Outline

Step 0: There is No One True Way

-Preparations

-Perfect is the Enemy of Good

-Understand the Core Strength of TTRPGs

-Get in touch with your Feelings

-What is your game about?

Step 1: Start with a Small Design

-The Importance of World Building in Systems Design

Step 2: Consider What Success For your System Looks Like

-Why you shouldn’t expect your first game to gain massive appeal/attention/sales

-Spectacle Vs. Substance

-General guidelines for system design and rules crafting

Step 3: Establish your Design Values

-Gimmick Concerns
-Balance in a Vacuum is Useless

-Be Mindful

-Refining the Elevator Pitch

Step 4: Determine the Basics

-Designing your CRM

-Edit Down Your Work

-Generating Lore

-Good vs. Bad Mechanics

Step 5: Determine your Game Modes

Step 6: Determine your Sub Systems

Step 7: Designing your Systems

-Naming Conventions
-Using A.I./ChatGPT for Working Through Ideas

-Understanding What has come Before

-Think Like a Designer

Step 8: Play Testing

-Do Not Attempt to Design the Perfect Game

Step 9: Editing, Layout, Art Direction, Character Sheets, and UX

Step 10: Marketing, Advertising, and Beyond

-Hiring Other Writers/Artists
-How Long is a Game?

-Selecting your Storefront

-Doing your first convention

-Expectations of duties for solo publishing and professional production

-Pricing your product as a small company

-Closing thoughts

-Additional Resources

Step 0: There is No One True Way

There is no single correct path in TTRPG design. Most of it rests on opinion and subjective table experience. Even when research is involved, success often comes from timing and circumstance more than any universal formula. Do not assume your choices are absolute, and do not accept others’ as absolute. There is generally good wisdom to lean on, and there are always exceptions. Think less in terms of right and wrong, and more in terms of what works in most cases, or what is right for your game, not every game.

Consider the claim, “You need high-quality art to have a commercially viable TTRPG.” Not always. Plenty of successful games lean on simple, even stick-figure art that gives the product a distinct identity.

Treat this guide as tools, not dogma. Use the principles when they help, and subvert them intentionally when your design calls for it.

Design is defined less by what you choose than by why you choose it and how it plays at the table. Rules should serve the game’s premise in practice. As with music, restraint matters. What you leave out, when you add variation, and where you allow space can matter as much as what you emphasize. The same lesson applies to TTRPG design.

Preparations

To get good at something, you usually have to do it poorly first for a long time. That process is often better known as practice.

For system design, I often suggest a progression of roles and skills:

Player → GM → Adventure Writing → Multi-System Experience → Homebrew → World/Setting Building → System Hack → System Design

Working through these, failing at first and improving over time, builds a strong foundation. The path can take years, even decades, but each step naturally supports the next. I tried jumping straight into system design as a teenager with almost none of that groundwork, and the results were predictably poor. That may or may not happen to you, but the more practice you have in these areas, the more prepared you will be when you turn to system design. You do not need decades of mastery, but a solid base always helps. Think of it as “multi-classing” into each discipline at least to level 2; learning the basics and the theory behind them before leveling into system design.

This is not a strict or mandatory path. Entire books, blogs, and channels are dedicated to being a better player, GM, or worldbuilder, and I have written at length on these topics myself. The important point is to research, practice, and keep learning. Play many different systems, not just many similar ones. Someone who has played five very different games will learn far more about mechanics and gameplay loops than someone who has played twenty nearly identical ones. If your only experience is with a single favorite system, that is almost never enough to design something of quality. Go out and try new games.

Finally, you do not need to follow this process or even read this guide to make a game. But you will likely design more thoughtfully if you do. Considering these ideas, including the ones you may not agree with, will help you form clearer opinions and stronger design choices.

Perfect is the Enemy of Good

Perfect is the enemy of good. This lesson applies whether your game is intended for commercial use or private, and further applies to pretty much any creative endeavor.

Keep in mind at all times: everything is placeholder, even after you print because there’s always the next edition. This is your art, it will never be finished. There is however, a time where you will need to be done. That time is when you have reached one or both of the following criteria:

Slide source: Chris Wilson at GDC 2019

1) Additional iteration comes at a cost of investment (time/money/effort) that far exceeds the potential benefit. Notice that the graph above is an asymptote (you will never reach 100% quality). Strive to be at the blue line (90% quality) for optimal results (least work for most benefit) or just slightly above it if you have the extra resources available.

2) Additional iteration is only likely to negatively impact the product (your game design) because you have reached your reasonable potential with your current skill sets and resources.

Points 1 and 2 are both almost the same thing, but not quite. It’s important you understand the difference. One is about the project limitations, the other is about your personal limitations, and those are related, but not necessarily the same.

When doing all of this, expect to fall short on some things. You aren't a bad game designer if you make a bad design or play test. You're a bad game designer if you had a chance to learn a game design lesson and didn't/refused to recognize it when it spat on your shoes.

Understand the Core Strength of the TTRPG Format

The core strength of the TTRPG format unique from other entertainment media such as books, television/movies, video games, board games and others is that it has infinitely branching narrative possibilities, limited only minimally by the system that governs the game and the imaginations of the participants.

No other entertainment media provides this breadth of possible experiences. Additionally, it can be argued that while other media can provide various amounts of entertainment immersion value, because the TTRPG has infinite possible branches of narrative, it provides a unique style of collaborative engagement for players that is not well replicated by other media, even those that consider themselves RPGs (such as video game formats or choose your own adventure books).

Get in touch with your Feelings

Almost all of design is rooted in preference and opinion.  What you like and what I like are very likely different things. Same for any two players or GMs or Designers. Even if we like the same system/genre, we might like it for very different or even contradicting reasons. The good news is, if you’ve ever made a house rule, you’ve already exercised your design muscles a little. Because you found a pain point and created a solution that you found more fun (fun being an opinion and subject to various interpretations).  And maybe you were good or bad at it (and you’ll get better with practice), but that process is pretty much the same thing for making a hack or original system, you just do that same thing over and over again until you have a full game. Get into the habit of investigating what you like and don’t like, and why, and how you think you can make it better.  That’s pretty much the whole ball game.

What is your game about?

There are three things I recommend strongly figuring out before designing anything at all:
What is your game specifically about/what is the product identity?
What is the intended play experience? (How should it feel to play?)
What are the design goals (your plan) to fulfill that intended play experience?

Here are some questions to answer (or at least think about for now and come back to regularly) that may help you figure out answers to these questions if you’re struggling:

1. How is your game different from the last uncountable number of dust collecting RPG releases from the last decade?

2. How is your game (different from/better than) similar games or games that inspired it?
3. Who is your target audience? What will they value in this game? What are the core game loops?
4. How are the players supposed to feel when playing the game?
5. What are the PCs supposed to do? Not what CAN they do, what are they supposed to do? (reward these actions)
6. What player behaviors do you find desirable in your game? (reward these actions)
7. What kinds of play styles and genre(s) does your game cater to? What is the intended atmosphere?

8. Who has what control of what part of the narrative and when?

9. How do your intended resolution mechanics and sub systems reinforce the game’s world building and intended play experience?
10. What areas of your game deserve extra development and attention to enhance the intended play experience?

You will benefit greatly from knowing what you are building before you build it, saving tons of time and unnecessary headaches. This is the single most useful piece of advice you can internalize as a designer imho.

Once you know what you are building, you won't need to ask "is this good?" because you can instead ask "Is this good for my game?" and refer to those things to find out if the answer is yes or no (or maybe), making the design process far easier on yourself and more intuitive.  Very importantly, think of different TTRPG systems as ecosystems of rules.  An identical rule in 2 different systems will handle and play very differently, that’s why there’s no right or wrong decisions, just which is the best decision for your specific game.

When you design first and figure out what your product is afterwords, there's a strong chance you will:

• Be working uphill the entire time
• Have an incoherent/disjointed design
• Be plagued with constant bouts of design/choice paralysis
• Have no end goal in sight
• Have constantly expanding scope/bloat

All of these issues individually (let alone combined) can cripple/kill a game design before it ever sees the light of day.

Another tip regarding scope concerning a game’s identity: It is often better to do one thing very well, in depth, than to do everything, all at once, poorly and with shallow depth (avoid inch deep, mile wide design). This is not to suggest that there is a specific target minimum or maximum of game granularity for all games, but rather, there is a correct/optimal amount of granularity for your game’s intended play experience and you need to figure out what that is through first understanding your game, then building a competent design, and then play testing to identify and fix the pain points. I will also add that your game should be as long as it needs to be, but no longer. Your core game is not finished when there is nothing more to add, but rather, when there is nothing more to take away.

Very importantly, when making a design choice, it’s not about what you implement but why you implemented it and how.  In theory it should be supporting one or more of your answers to the 10 questions above.  If any content you are including doesn’t support what the game is supposed to be, why is it there?  Chances are it’s probably design bloat.  Challenge your assumptions about what your game needs and wants. Challenging assumptions is the very basis for iteration and innovation.

As a last bit here, don’t be afraid to rethink what you started with.  Listen to what the game wants and needs.  Fail faster and follow the fun (game jams are great for this), even if that means redesigning major elements or throwing out major bits if that means you’ll have a better, more cohesive, and tighter experience at the end.

Other Starter Wisdom

New designers often run into the same common concerns. These tips may seem obvious, but they are worth keeping in mind.

1. Take breaks. Step away when you need to. Touch grass, watch a show, have coffee, try something new. Breaks help prevent burnout and give you fresh perspective. If you burn out, rest until you are ready to return. If you make a habit of reflecting, almost any life experience can feed back into your design work. Be careful though, staying “always on” will burn some people out faster even if it makes them briefly more efficient. You can also cycle between projects within your total workflows to keep things fresh when you get stuck on a particular area, just be sure to note/mark unfinished sections to return to them later.
   
2. Ideas are cheap. Your ideas excite you, and that enthusiasm matters. Use it to fuel progress. But ideas by themselves are not especially valuable, it is execution that counts. Many people have interesting premises, but the difference between a thought and a playable game is the work put into the design. Execution is greater than premise.
   
3. Do not ask for unpaid labor. Designers already have their own projects or paid work. Friends may help each other collaboratively, but strangers online almost never will beyond a few minutes spared for critique of short sections, and professionals will almost never do so for free. If you want help, either have close friends from existing relationships as collaborators who care about your project or be prepared to pay fairly. Otherwise, all of the work is on you.
   
4. Start with what your game is (not what it isn’t or what it is compared to others). Focus on the experience you want to deliver, not only on what you want to avoid or how it relates to other games. Why you make each decision matters more than the decision itself. Being able to explain your “why” shows you are thinking about design philosophy and how best to deliver your intended play experience. This leads to stronger, more fitting solutions.
   
5. Consider system hacks over system design. If you love design (not the idea, but the activity), create your own system. But if you are more interested in customizing than building from scratch (i.e. you just want a system to deliver your setting), consider using a flexible framework like BRP. It is a flexible engine built on d100 mechanics that can be reshaped in many ways. Use of d100 makes it easy to map probabilities to any desired CRM (core resolution mechanic). It is not perfect for every project, but it can save enormous time for someone who wants a working base without reinventing everything, and can then be further customized via hacking.

Step 1: Start with a Small Design

Just do it. The biggest benefit of beginning small is that you will actually finish something. A short project is manageable, gives you a writing sample for the future, and avoids the common trap of biting off more than you can chew. Many designers abandon their first projects because the scope was too large. Starting small helps prevent that.

This is advice, not law, but both research and experience show that more people believe they are exceptions than actually are. Working within constraints, like making a one-page RPG or hacking an existing system, trains you to be concise and direct. It also forces you to explore a single idea in depth instead of scattering effort across dozens of shallow ones. A narrow focus produces sharper, more satisfying results, and these skills are even more important to have when doing larger projects.

The principle can be seen in the video game Legacy of Kain: Soul Reaver, where puzzles build on one another as the game progresses. Each solved challenge prepares the player for the next, creating a satisfying and educational game loop. Good TTRPG design works the same way, giving players and GMs challenges that layer into a cohesive experience.

In short: beware scope creep. You can under-design a system, but bloated design is a far more common problem, and one that will derail your project quickly. 

The Importance of World Building in System Design

System design is world building. Rules define what is and is not possible in a game world, and traditional world building will directly shape the values, goals, and intent of your system.

As general advice, do as much world building as you can before designing a system. It fills in gaps, clarifies identity, and provides direction before you move on to deeper design choices.

You can make a system without a setting, but I do not recommend it. The market already has countless generic systems, most of which differ only in minor mechanics. Unless you have a breakthrough that fundamentally redefines TTRPG design, a new generic system will struggle to stand out. If your game is “about nothing,” players have little reason to be excited when they could pick a system already tailored to their preferred genre, play style, or tone, or an existing and trusted brand of generic system.

A defined setting provides anchors for design values, helps with probability and pacing choices, and creates opportunities for specialized mechanics. It also supports branding regarding art style, layout, tone, and presentation; all are easier to shape when you know what your game is about. Without this, you end up with vague or abstract presentations and an at best weak answer to the most basic question: “What is your game about?”. Notably, if you answer this question with “It’s about whatever you want it to be!” this sounds very suspiciously like offloading your job as the game designer onto the game master (or preferred term) which is unlikely to be very convincing to potential game masters who might run your system.

There is a gray area. A system does not need a fully prebuilt setting, but it benefits from at least a clear genre and feel. Burning Wheel is an example. It focuses on character motivations in a fantasy frame, with mechanics that encourage players and GMs to co-create setting details collaboratively. It does not ship with a full world, but its identity is still clear. Additionally, players always contribute to world building during play, the question is how much structure the system gives them to do that.

Settings are also portable. Many publishers take an established system and adapt it to new settings/worlds. This is an industry staple, and it works because players already trust the system from its original form and the creative visions of the developers/publishers.  Almost all major publishers do exactly this. Adapting mechanics to a new setting is easier than convincing an audience to embrace an unproven generic engine.

World building is its own discipline, and a prerequisite skill for system design. There are two broad approaches: top-down and bottom-up. Both rely on answering the basic questions—Who, What, When, Where, Why, and sometimes How—over and over, with special focus on Why.

Practical tools can help. Create vision boards (Pinterest), jot down notes as if writing adventures, or use platforms like World Anvil for worldbuilding prompts. Even simple exercises like searching for writing prompts online can spark ideas and help refine your setting. If you’d like more insight into world building I’d suggest this video as a good start.

Popular Generic System Cover Art

Step 2: Consider what Success for your System Looks Like

In most cases it’s best to not consider that your first or any design will be a gold mine that will compete financially with corporate giants in the industry of TTRPGs. In many cases “finishing the design” and “having my name on a finished product” are likely your best goals starting out. Things like any degree of financial success that looks like financial freedom, for most, is not a reasonable expectation for a starting hobbyist. The important thing is that you know what you want to achieve. Maybe it’s just a game with a neat new mechanic you dreamed up, maybe it’s just to have something you can play with your friends at your gaming table that you all find fun. It doesn’t matter exactly what the goals are, so long as you understand what they are and have realistic expectations regarding them. 

Why you shouldn’t expect your first game to gain massive appeal/attention/sales

• An estimated ~20 games/systems per calendar day are launched daily, with an expected 12 of those being English speaking.*
• Many of these are made by individuals or full teams of educated professionals with decades of experience (and many times those fail to gain traction).
• Many of those are likely to have larger scale budgets than are typically available to a starting indie designer.
• Your first game is your first, and thus very likely to be your worst attempt. Assuming competitiveness under that paradigm after taking the first 3 points above into account is very likely definitive hubris.
• The vast majority (estimated 80-95%) of started indie TTRPG games/systems are never finished/publicly released. The attrition rate is notably bigger than the drop out rate of US Spec Ops Navy Seals in training (about 70%).
• The vast majority of finished games earn $0 annually (free/PWYW donation games).
• The vast majority of indie games that do make money earn a little extra fun money each month ($200 USD/monthly or less, very frequently less) for an indie creator, not a comfortable salary.
• System Design/Production is a notorious money pit, not a lucrative career, particularly for indie designers.  This is often best illustrated by the term “heart breaker” which is a term used to describe TTRPGs that are passion projects someone puts all their effort and money into, leveraging their personal assets, and finds it never gains traction for sales.
• Rare examples of games earning millions during crowdfunding almost always require 1 or more specific built in advantages:

• An existing built in community audience such as having a popular youtube channel in the TTRPG space with 100K+ subscribers or a similarly very large and active TTRPG discord community.
• Specific popular brand identity association such as being made by a long standing and trusted individual or company in the TTRPG space (Monte Cooke, Matt Coleville) or a specific IP licensing with major cross over into the TTRPG space that isn’t better served (Avatar Legends).
• Hard Work and Talent: These are prerequisites for success, not guarantees. Many great games sit in perpetual obscurity, collecting dust.
• It is possible to “get lucky” otherwise, but odds are expected to be roughly equivalent to hitting the jackpot in the lottery.

*Games/Systems are counted as fully playable individual TTRPG products as follows:

• Does NOT include: splat/errata/ongoing kickstarter campaigns/expansions/adventure modules/other table top games/RPG video games/play aids, etc.
• Does include: any size from 1 page games to massive volumes (former being more common, latter being less so).
• Estimates are based on:

• Independently collected data
• 3 decades of anecdotal observation
• Data Reporting from Market Reporting Outlets:

• Source 1
• Source 2

• Note: This Data Requires Estimates. While spending and projections can be reported from trusted outlets, this does not account for: uncategorized/improperly categorized sales/products, independent website exclusive sales that do not meet tax reporting thresholds (would require scraping the entire web, repeatedly, over time, still only resulting in estimates), and shifts/changes in market trends both minor and major that affect consumer and production/service behaviors over time.

Take Away: The only really, truly good reason to make your game is because you have an idea that isn’t better served elsewhere and want to see that game made, AND, because you enjoy the act of making it. If those reasons aren’t both true for you, consider finding a better system fit to houserule or hack (extensively house rule/reinterpret) for use, it’s far easier to do with much less effort and skill level required. Any other reasons or expectations for engaging with TTRPG System Design are likely to be folly.

Spectacle Vs. Substance

While it is true that players buy with their eyes first, and largely if you want commercial success you need to meet certain art, layout, and general polish standards (and even if you aren’t seeking commercial success these things will only help your system’s circulation and adoption rates), it’s important to remember that this alone is not enough to carry a system. You still need substance and while players will tolerate a certain amount of bad design (which is why players will home brew rules and world build custom settings they find to be of better use) they will reach a critical point where your game is no longer a game they will want to play and is instead mined for content ideas and is otherwise relegated to the shelf, closet, attic, or external HD to collect dust. You’re going to want both substance and spectacle if you want your game design to exist meaningfully beyond your personal playgroup.

Also keep in mind that there is nothing new under the sun. There’s a strong chance that if you think you created something “new” in TTRPG design, no you didn’t. This isn’t to say this is impossible, but the industry is iterative, not one rooted in invention. The basics of most things have all been mapped out in decades past, and while once a decade or so some individual brings a new idea into the fold, there’s a much stronger chance that idea will come from someone who is a career professional with years of industry experience rather than a first time designer.  All of this is to say, don’t fall into the illusion that what you are doing is new. That doesn’t mean it’s not a unique take on an old idea, but there’s a significant chance whatever you thought up in your first several years of doing this have already been done elsewhere to some extent.  Lastly, don't forget the mantra: Execution > Premise.

General Guidelines for Systems Design and Rules Crafting 

Writing a rule:
1) Clarity, the rule must make sense to the reader. This starts with understanding the purpose of the rule.

2) Introduce information in the order needed and keep it short and punchy (especially important for bigger systems but this is always important)

3) If it's a complex system that isn't better simplified, break it into bullets and organize in the order the information is needed. Use break out boxes for examples if needed. Avoid complexity for the baseline use cases, allow players to opt into complexity at investment cost vs. benefit (unless there is a specific reason not to).

4) The rule understands and follows the intended play experience, product identity, design goals and world building (this is why you should figure these things out before designing any rules).

5) Always consider what player behavior the rule encourages and compare/contrast to the intended play experience.  I’d strongly recommend reviewing Manyfold for basic ideas on how to support and craft different mechanics for different kinds of player motivations/game loops.

Game Design Principles:

1) The rule (where possible) provides meaningful choice, something where players weigh a cost/benefit analysis.

2) The rule interacts with other systems logically. Don't stretch the bounds of the rule to make this happen, but do make sure you do this whenever it should reasonably apply.

3) Adds enough fun factor to justify requisite cognitive load/word count/book keeping.  I refer to this as the “old faithful equation”: Fun ∈ props(Rule) : Fun ≥ (wordCount + cognitiveLoad + bookkeeping). To parse that into basic English “Everything related to fun in a design relies on elegance”.

4) Have systems where you should in order to enhance the intended experience, ie wizarding school for youngsters has a custom wand sub system, etc.

5) Organize and UX your data for accessibility, make it easier to reference (consistency, icons, charts, indexes, graphics, ToC, appendixes, etc.)

After independently developing this it was pointed out that all 10 of these loosely align with the Norman/Nielsen 10 usability heuristics (for interface design), though are made relevant in the context of TTRPG design.

I also want to expand on point 3 slightly:
Many people get hyper focussed on procedural mechanics modelling to make the game achieve a certain feel and that’s good as it helps fulfill the intended player experience which is one of the things I keep harping on in this guide, but it’s not what makes or breaks a game for 99% of players.  The vast majority of players couldn’t give half a care what the mechanical resolution procedures are, they care about the interaction design (does this feel fun and intuitive?).  

I’d argue that in a perfect world you would want immutably and objectively awesome/perfect rules regarding both procedures and interactions, but if you’re going to hyper focus on making one of those better, focus on the interactions.  A stupid simple design that promotes really fun interactions will be played over and over.  A game that is all procedure and no interaction focus will be played once for curiosity because it seems really cool on the surface, and then find its way to its forever home on the shelf to collect dust.

As an example: If your game is about the IP Mad Max or similar to it, it is going to need to feature intense car chases/battles to fulfill the promise of the game, and when designing those interactions you’re going to want to design the mechanics in such a way that the mechanics encourage and reward players who take risks or drive recklessly. (What are the players supposed to do? Reward these behaviors).  If instead the mechanics indicate the optimal way to play the car chase is to drive safely and take no risks, you won’t be delivering on the promise of the game.

Kinds of Rules:
Rules are the representations of underlying logic of your core mechanics, so it’s useful to understand what they are made of and how they might typically interact as component structures to engineer them correctly for the experience your game wants to deliver.  This list is not definitive but seeks to capture major concepts with minimal overlap without also being overly broad. Consider this just a basic primer to get you started and as always, challenge your assumptions.

Core Rule Components: These components can be mixed and matched in various ways for translation of different/complex design intentions.

• Prescriptive: A rule with a clear context descriptor and procedure within the system/sub-system: Example: X feat provides +2 to Y maneuver roll. This kind of rule functions similarly to a Logic rule but isn’t generally dependent upon a variable result determined during play sessions. A common example of this might be any character creation sub-system; things that are otherwise functionally specific static rules.
• Descriptive: A rule existing as a resulting parameter meant to be interpreted without a clear procedure attached.  Most common in narrative first + rules light games but can exist in rules dense games. Example: “Success at cost” without a clear definition of the cost. These types of rules can be used to function as guidelines for determining arbitrary fiat results.
• Consequential: A rule that provides consequence (generally a reward or punishment) to steer player behaviors towards the intended play experience. A common example of this might be Kill XP and magic items within a monster-looter like DnD pushing players to fight epic monsters despite inherent danger.
• Logic: A rule that states a procedure/rule is applied under a certain conditional variable outcome, most common in prescriptive rules but can apply to descriptive as well.  Examples could be if/then (if natural 20 attack roll, then double applied damage), and/or, minimum or maximum values, only if exceptions, etc. Logic rules are generally the most common kinds of rules and depending on how broadly the term is defined, could include any rule (even undefined rules) but for the sake of avoiding being overly broad they are considered here to be dependent upon a variable result determined during play. Logics of this type are generally best understood as both formal logic expressions to include logic gates.
• Aesthetic: While often not touted as a rule, and generally more tied to setting, specific aesthetics can be rules.  Example: All of the Black Templar Knights must wear black armor. While this might not have a derived prescriptive mechanic, we can assume narrative consequences for a black Templar Knight if they do not wear black armor.  Similarly, if a spell that does fire damage is said to be greenish hellfire in its description, we know that the representation of the fire for that spell is green.

Applicative Rules Subtypes:  This subtype kind of rule describes the axiom of how rules can be applied in a system engine.

• Adjudicative: Combines functions of prescriptive and logic. These rules determine how to arbitrate disputes or uncertainty.  Common examples include: “Roll 1d100 on the random encounter table (or any other specified die rolls called for by rules in context) and “PCs are forbidden from engaging in PVP behavior”
• Interpretive: A combination of the functions of Logic + Implicit + Setting Specific + House +Tacit, a rule that states an outcome is meant to be arbitrarily interpreted (usually by a GM utilizing fiat).  A common Example being: “Persuasion attempts by players vs. NPCs are determined by how convincing the GM finds their augment in relevant context”.  This also includes most uses of text declared GM fiat.

Meta Rules Subtypes: A rule that exists outside the typical base mechanical systems or that may directly affect narrative, even potentially superseding other defined systems.

• Preamble: Often not thought to be a rule due to its informal nature and separation from mechanics; a preamble in a core system sets up the narrative premise of the game and how to interpret it. As such it’s one of the most important kinds of rules because it colors through a specific lens everything that follows in the rest of the rulebook by explaining what the game is supposed to be and feels like to play. Frequently located in a Core System Introduction section and may be otherwise displayed/reinforced by artwork or diegetic articles.
• Meta-Currency: A rule classification for a pool of points/tokens (often but not always earned by player actions rather than characters) that can be spent to modify/alter existing mechanics or narrative direction/outcomes.  Common Examples: Hero Points and Inspiration.
• Optional: Official supplemental rules that exist beyond the core system, frequently included in expansion books that may have content relevant to these systems. Often these add subsystems, classes, or game modes for players that may find them useful. In most cases these rules wouldn’t be considered for organized/tournament play without explicitly being highlighted as part of the tournament despite being official rules.
• Defaulted: Rules that provide a default rules interpretation guidelines to override existing mechanics similar to a preamble but are (often) specifically codified as/among core rules though in some cases may exist as part of a preamble. Common Examples: Rule of Cool or Rule of Cruel (see Tales from Elsewhere).

Contextual Dependency Rules: These kinds of rules are governed by individual/unique contexts (such as the setting or players).

• Setting Specific: A kind of rule that operates differently within a specific setting to coincide with the altered premise of the new game world, usually relevant to franchise systems that print specific setting books (see GURPS, D20, SWADE and other generic systems). These rules seek to capture and represent a specific vision for a narrative fictional game world to provide immersion to that end.
• Implicit: Usually not a good example as it’s not something that’s usually written down, but provides a limitation or requirement based on the setting allowances or narrative intent. Example: “You may not name your character Buttfartimus the Flatulent in this game/campaign with a serious tone”. Notably much of what separates a lot of rules dense vs. light is how much dependency there is on implicit rules.
• Tacit: A combination of the functions of Implicit and house rules whereby the narrative premise is not the determining factor, but the social expectations of the individual play group apply a constraint or requirement.  A common example of this being “Lines and Veils”.

Rules Modifications: Specialized types of Applicative Rules designed as modifications to existing RAW (rules as written).

• Errata: Official corrections/clarifications that are meant to retract RAW, most commonly for print editions and released through official channels (typically social media in the modern era).
• House: Unofficial rules used at the table to meet table preferences not outlined in the RAW that may even contradict, replace, or undermine RAW.  Note that it’s likely in most games outside of organized play that any substantial system is likely to have house rules in place at a private table no matter how well designed your game is. 3PP (third party product) rules are functionally within this category as they are unofficial rules only included for the same reasons as any other house rule.

Depth vs. Complexity

Complexity is the number of steps needed to be taken to complete any one action and/or the mental/cognitive load of information needed to competently make a decision at any one decision point (ie, this is the cost of resolution granularity). Complexity must serve a critical function to justify its existence and is often best minimized.  A high complexity resolution will incorporate multiple and potentially various procedural stages and will increase time between experiencing the fun of the game (leading to boredom, the opposite of fun).

Depth is the number of viable options at any one decision point, or the variable viable resolutions available for an outcome. Note that non-viable options are the illusion of choice and should be avoided in most use cases. A high depth resolution does not necessarily require high complexity, such as having a d100 random outcome table with 100 options (roll + chart reference).

For games that aren’t specifically looking to be rules light, the general notion is that you should seek to add depth, not complexity, the complexity will only ever slow down the execution at the table due to the total procedural cost. A game should be “only as complex as it needs to be” and no more. How much that is will vary with the vision for the game (usually revolving around desired granularity), but as a designer you’ll want to seek to eliminate complexity any time it doesn’t directly serve some other more vital aspect of the game’s fun/function.

Example of when to add complexity: In VtM (Vampire the Masquerade) players are vampires and have a hunger meter that requires constant tracking and provides feedback and consequences.  This is more than just a standard multi-tiered status effect, because it is an integral part of the game’s central motivations and fiction (vampires must feed or lose control, and preferably with discretion).  As such this isn’t “just another status effect” but rather, a core function of the game printed on each character sheet because it directly impacts the narrative play for every character as a core motivation.  Is this added complexity?  Yes, tracking this hunger meter and its effects is definitely added complexity, but arguably it is a core game function that without which the game would lose its core identity and drama, making it a good candidate for inclusion.

Example of when not to add complexity: Functionally any time added complexity fails to meet the old faithful rule above as the end result is that the time to enact at the table vs. the benefit it provides leading to play feeling more like a slog/chore/grind rather than fun and engaging.  Additionally it’s worthwhile to consider that even with various added complexities being worthwhile, there is a maximum cognitive load for your audience (as indicated in the old faithful rule), and you need to prioritize the most important instances of complexity first, and determine at what point you need to start cutting/combining/streamlining bloated features due to the game becoming too difficult to manage at the table for the intended audience, noting that different audiences will have different capacities and in different areas. Additionally different player motivations can contradict while granular resource management in any capacity may be hated by one player and the majority of fun for another. Further, much of the job of marketing is to clearly help the audience correctly self select by painting a clear picture of what the game promises to deliver.

How to Bake Rules
Another important but more abstract bit is something I call how to bake rules, applied in a similar context to baking a cake, souffle or other preferred baked goods.  It’s a bit abstract but goes like this: “The rules are likely to work best when they have rigid exteriors (clear boundaries) and soft gooey middles (adequate room for needed adaptation and improvisation).” To the extent one prefers how rigid or gooey is personal preference, but that this formula is likely to be great advice in just about any format; too rigid on the exterior and you burn it, too gooey in the middle and it’s similarly inedible.  This was a concept I first heard pitched by Dr. Ben (RPGPHD, youtube). It’s one of those elusive obvious things that just works very nicely once you get your head around it.  Once you figure out what your ideal thresholds are for your design (in an abstract sense) this lets you know when the baking time is done on a rule (providing you’re applying the other basic principles).  Like baking, let it cool a bit (so you can reflect from different angles) before consuming (playtesting/implementing).

If you’d like to view the full discussion with myself, Dr. Ben, and Peter (Tales from Elsewhere): PART 1 , PART 2

Just be aware this is an especially long TTRPG design discussion (4 hours in total), but I’d argue, is a particularly great one.

Step 3: Establish your Design Values

Design values are your compass. They help prevent design decision paralysis, keep scope in check, and clarify what your game is about. Early on, your values can be as simple as six or more adjectives that describe the kind of experience you want to create. These will evolve over time, but starting with them will make design decisions easier.

Clear design values serve several purposes:

• They reduce design paralysis. When you are stuck, compare options against your values and follow the direction they point.
• They clarify your vision early. A muddled vision makes the whole project harder.
• They help fight scope creep. Ask, “Does this feature serve the game’s purpose?” If not, cut it or save it for a later supplement.

Remember that size and bloat are different. Size is word count. Bloat is unnecessary word count. Any game can suffer from bloat, but it is especially damaging and more noticeable in larger systems.

Questions to consider when defining your design values:

• What features do you care about most? What features must be in your game to achieve your vision?
• How is your game different or better than others in comparable genres? If you haven’t researched as many other games in similar or relevant genres as you can find, yesterday is precisely the time to start.
• How should the setting feel through play? On a scale from 1 (bright whimsy) to 5 (dark and brooding), where does it fall?
• How do you define fun in this game? Is it rules-light, heavy crunch, theme-driven, subsystem focused, something else?
• Who is your target audience? Are they new or experienced players? How will they find/discover your product? If you haven’t begun a community as a resource around your game, yesterday is precisely the time to start.
• What is your product identity? What is your elevator pitch? What kinds of stories should it tell? How does presentation (art, layout, tone) interact with mechanics?

Three important things to keep in mind:

1. Your game will evolve. Core principles may shift as you iterate. That is normal.
2. There are only two truly bad outcomes in design:
   

• You create content that harms others or encourages attitudes that lead to harm.
• Your mechanics do not function or are unclear.

1. If you avoid those 2 outcomes, and your game is fun, you are on the right track. Uncertainty is expected. Playtest, iterate, and refine until satisfied.

3. Good design is much harder to detect/is nearly invisible because it fits the consumer/user needs so well.

Rapid-fire beginner tips:

• Avoid “non-choices” in character creation. Essential abilities choices should be accessible to all without investment. If something is overpowered, rebalance it, make it essential (available without investment) if deemed mandatory for the game style, or cut it.
• Match mechanics to the promised fantasy. High-powered superheroes may shrug off bullets or even missiles, but ordinary characters should not survive dozens of lethal blows.
• Provide clear rules or guidance for common scenarios in your core gameplay loops.
• Avoid repetition/duplication/extensive overlap in skills, combat, or other mechanics. Variety keeps play engaging.
• Be cautious when mixing unrelated ideas. Not all good concepts belong together. Use playtesting to confirm whether they fit.

Gimmick Concerns

At this stage it is worth addressing a common trap: “You don’t need a gimmick… sort of.” Many new designers fixate on inventing a gimmick that will make their game stand out. The problem is that unique does not automatically mean good or useful.

The best gimmicks emerge naturally from solving design problems or reinforcing the core themes of your game. If a feature grows out of your mechanics, setting, or design values, it will feel integrated and meaningful. If you force it in just to be different, it will often feel bolted on and awkward in play.

Your game does need to stand apart, but that can come from many directions: mechanics, resolution engine, subsystems, lore, tone, visual design, or gameplay loops. Usually a combination of these is more than enough. Simply working on your design with commitment and bringing your own perspective will make it distinct. If creativity is not your strength, you can partner with someone who has that skill, or better yet, build the habit yourself.

Creativity is not magic or innate talent. It is a skill that strengthens with practice, like a muscle. You develop it by working through problems repeatedly. Here is a practical process for building that creative muscle:

1. Identify a problem (or take inspiration if it appears, but do not wait for it).
2. Learn more about the relevant subject.
3. Form a better informed opinion.
4. Investigate that opinion thoroughly. Ask and answer “Why?” at least five times to dig deeper.
5. Challenge your assumptions.
6. Remix different approaches to discover new applications. Randomize reconfigurations if necessary until something useful emerges.
7. Implement your best solution.
8. Test it. Use playtesting, critique, and iteration.
9. Apply what you learned and repeat the process until you are satisfied.
10. Celebrate the result once it feels right.

Balance in a Vacuum is Useless

Just like gimmicks, balance often receives too much attention from new designers. Balance alone is not fun, if you don’t believe me, watch this video (I’d also recommend it either way for any TTRPG designer). What matters most is whether your game is engaging and exciting/fun. Balance comes second.

Defining fun is subjective, and chasing trends or “perfect balance” rarely guarantees success. Players often don’t even know what they want until they see it. For that reason, the best advice is to design the game you want to make. If you work in the industry, you may design under someone else’s parameters, which can feel restrictive but also spark creativity through imposed limits.

A common pitfall is trying to balance characters 1:1 in party-based games. The real measure is how well roles fit together in the party. Consider the potency of abilities, the upfront cost or investment, how accessible they are, and how often they will come up in play. Context is everything. A character who specializes in hunting undead will feel weak in a game with no undead but invaluable in a campaign focused on them. As a designer, you can’t predict every table, but you can avoid options that clearly don’t fit your game.

For numeric balance, start small. If you are torn between giving a +2 or +3 on a d20 roll, start with +2 unless you have a strong reason not to. Smaller numbers are easier to control and diagnose. This is especially important in systems with many sources of modifiers, where bonuses can escalate quickly. Early balance only needs to be “close enough.” Playtesting is where you refine details. Players rarely object if numbers are adjusted during testing, as long as changes are logical, and they’ll be especially less likely to object if it’s a buff to a weak ability.

Ultimately, balance only makes sense in context. A brutal horror game like Call of Cthulhu or Warhammer 40K expects high failure rates and death. A superhero or anime-inspired game may expect near-immortality and over-the-top physics. Both can be fun, but each requires a different balance philosophy. Tie your approach to your product identity and intended play experience. Balance is important, but “fun” should always come first.

Be Mindful

Promote a healthy TTRPG design space. Consider the social ramifications of your design and, when appropriate, seek perspectives from sensitivity readers. Remember one of the two worst outcomes in design: creating content that harms others or encourages harmful attitudes. This does not mean that games must avoid difficult subjects, only that designers should approach them thoughtfully and responsibly. Here’s some key points to help you avoid pitfalls if this isn’t immediately clear and obvious or you feel yourself wanting to push back:

1. As a litmus test, use this as a design rule: “Nazis are bad”. This principle extends to all forms of fascist, exclusionary, or bigoted ideas, particularly in regards to content that targets vulnerable groups. Including Nazis (or similar groups) in a game is not itself problematic if they are clearly categorized as antagonists, but do not portray them as correct, admirable, or glamorized. Some might argue that fiction requires villains, and it does at least require conflict/antagonists, but things that are villains should remain villains, not portrayed as aspirational figures unless the text makes clear that this is critique, not endorsement.
   
2. If your game contains darker elements (gore and personal horror), more extreme sensitive elements (such as slavery or mental illness), or adult content (explicit drug use or sexual content), include a disclaimer at the beginning. This is not about appeasing critics, but about respecting consent and allowing play groups to choose whether to engage with the material or adapt it as necessary. Some may feel that disclaimers are unnecessary, but they are not censorship; they are tools of consent that give players autonomy over what they are willing to encounter at the table.
   
3. Use Inclusive Language and Artwork. Chris Claremont, when writing X-Men in the 80s and 90s, famously asked himself: “Is there a good reason this character can’t be a woman? If not, why not make them one?” That single question led X-Men to become a landmark for diversity and allegory, mutants standing in for real-world struggles such as the U.S. civil rights movement. The same principle applies to TTRPG design. If there’s no good reason a character can’t be Black, trans, gay, asexual, disabled, or otherwise, then there’s every reason to include those possibilities provided you can do so with due diligence and respectful and thoughtful representation. Even when games already contain diverse elements, they often fail to emphasize them. A changeling, amorphous alien, or sentient robot isn’t inherently male or female, it doesn’t have to default to “man.”
   
4. Context Matters. Sometimes, exclusion does make sense. For example, in Project Chimera: E.C.O., a game about black ops super-soldiers, rules for wheelchair-accessible HALO jumps or SCUBA infiltrations would break suspension of disbelief, especially considering 3D print organs, genetic rewrites and bionics exist, allowing for correction of someone’s disability, specifically being required for their militaristic duties. But diversity in nationality, gender expression, sexuality, and background makes complete sense, especially in a near-future setting with advanced prosthetics, bionics, and medical technology. The key is finding where inclusivity fits within your world and then making it explicit (with care).
   
5. Provide Tools, Not Control. You can’t stop bad actors from misusing your system and playing the game in ways you would not personally approve of ethically, but you can give reasonable people the tools to make safe, respectful tables. Provide safety mechanics guidelines such as session zero and lines and veils. Explain what they’re for, what benefits they provide, and ask that players use them. After that, it’s out of your hands. Remember: some people will object to any content. That doesn’t mean you must bend to every demand. Every game requires buy-in. Call of Cthulhu thrives on horror, insanity, and violent death. Some players with mental illness embrace it, others avoid it as problematic representation of mental illness as gamification, or as potentially personally triggering, and it’s still the second most played game. Not every game is for everyone, and that’s okay.
   
6. Sensitivity Readers and Due Diligence: Do your homework. Ask how your system might affect players who aren’t like you. Talk with friends from different backgrounds, or hire professional sensitivity readers to spot blind spots. More perspectives mean more data, which leads to better design. And when you make mistakes, and you will make mistakes, own them. Apologize sincerely, fix the mistake as best you’re able (ask for help if needed), and move forward. What matters most is consistent effort: striving to be more informed and better tomorrow than you were yesterday.
   
7. Handling Criticism: Sometimes, criticism comes in the form of hostility or unreasonable demands. If you can’t engage productively, step back, but don’t stop there. Seek out another person from that same community who can give you a calmer, clearer perspective. Even if the messenger was aggressive, the core issue may still be valid. If there’s something you can improve, improve it.

Key Takeaway: Genuine inclusivity isn’t about pleasing everyone or performative posturing. It’s about making thoughtful design choices, giving players tools, and committing to continual learning.

Refining the Elevator Pitch

Once you understand what your game is supposed to be in concept it’s time to put together an elevator pitch to help guide you as a mission statement and draw attention to your product/give you a way to talk about it with others. You might think you should design the game before that, but that usually works against you. Do this first (and amend if needed) so you can meaningfully talk about your design with appropriate context ASAP (to get good feedback you need to be able to thoroughly explain what the game is supposed to be, otherwise others are using their best guess).

What is an elevator pitch in regards to a TTRPG? In this case we’re going to talk about something that is either posted in a short thread regarding your game on social media, or something that would appear on your back cover, or a community group description, etc. In this time you need to generate interest by proposing a value proposition. No game will appeal to everyone, but your goal is to help people self identify that they are interested if they should be.

Example from David Garrett, This Mortal Coil:

Do you like necromancers? Do you like space? Would you like to play a necromancer IN SPACE?

This Mortal Coil is both a standalone science-horror setting for Liminal Horror and a toolkit for incorporating necromancy and space travel into your own Liminal Horror, Cairn, and other Into the Odd inspired games.

I've just launched a public beta and itchfunding campaign. The full text of the game runs about 136 pages and a good portion of the layout and art is complete. The proceeds collected during the beta period will go toward funding additional creepy artwork for the final version.

During the beta period, I will be writing Glorious, the introductory adventure that will be included in the final version. I expect this to be between 24 and 36 pages, bringing the final count to somewhere between 160 and 172 pages.

If you dig necromancers, space, necromancers-in-space, creepy monsters, and lots of undead, you can find the beta here: This Mortal Coil.

Notice a few things about the post:
-They tell you why you might be interested right away. The game has a clear point of view and a good reason to be interested (you might not be interested in necromancers in space, but if you are, you’re in the right place). Simply put, if there is no good reason communicated for others to be interested, then nobody will be.
-They explain some specifics about the game but don’t get bogged down in mechanical detail.
-They provide you with as much access as they can to further material and a call to action.

Your elevator pitch might be more or less further along in development, but the point is that it should do at least the first one of those to be able to communicate and drum up interest about your project, starting with inspiring yourself. If you can’t explain why your game is exciting and interesting and worthwhile, who can? You need to understand the value proposition of your game and be able to effectively communicate it as soon as possible as this not only helps generate interest/community early, but it also helps work as another lens to filter your design choices.

Step 4: Determine the Basics

Start by answering two simple but essential questions:

• What are the characters supposed to do? Not what CAN they do, what are they supposed to do? Start with this and worry about the rest later. Additionally, consider providing reward structures for players who engage with what characters are supposed to do.
• How do the players achieve this?

To get there, every TTRPG needs three core elements:

1. A ROLE for the player to inhabit, often (not always) featuring character creation choices and character sheets.
2. A space (a setting or equivalent) where they can PLAY in where conflict and uncertain outcomes can occur.
3. A decision engine, aka CRM, (plus supporting systems) to resolve uncertainty to make it a GAME.

ROLE. PLAY. GAME.  All you need is right there in the name of the thing to qualify.

With these three pieces, you technically have a role-playing game. The third element—the decision engine—is what separates a TTRPG from children’s pretend games like house or cops and robbers. As a systems designer, creating and managing this is your primary responsibility (particularly in how it relates to characters, outcomes, and various sub systems you choose to include).

The purpose of rules and the decision engine is to turn uncertain outcomes into clear results. (Does my attack hit? Roll, compare, and find out.) A good engine minimizes resolution steps while still providing enough detail to feel meaningful but leaving space for creative interpretation (hard exterior with soft/gooey interiors from the baking lesson).

None of this needs to follow the traditional PC/GM structure, dungeon fantasy, or dice rolling. Some games have no GM at all. Some are solo-only. Characters can be hackers, gods, kittens, or microbes. Worlds can be contained to a single city or  sprawling multiverses, or even both simultaneously: see Planescape. Your engine could rely on dice, cards, coins, dominoes, bidding, or any other tool that produces random or semi-random results. What matters is that results are clear and meaningful within your game’s rules.

Even simple tabletop games offer useful lessons. Candyland resolves actions with single-color cards, Magic: the Gathering builds complex interactions into individual cards, and poker uses the same deck of cards as countless different games. While not RPGs themselves, these designs demonstrate different approaches to resolution mechanics. Likewise, dice systems vary widely, from binary pass/fail checks to nuanced probability curves, 3+ success states, and more.

A widely shared recommendation (which I also endorse) is to study a Magic: the Gathering card. You don’t need to know the rules of the game, but the way a card communicates function, value, and interaction is a masterclass in clear design and usability. Also consider this video when thinking about the basic mechanics as well as your design goals/values and product identity/intended play experience.

With that in mind, here are some common categories of resolution engines to consider:

• Chance / RNG: Dice, cards, coins, spinners, or anything that uses random outcomes.
• Resource Management: Systems based on bidding, token spending, or point allocation.
• Narrative Focus: Minimal tracking, relying on algorithms, GM negotiation, and/or collaborative storytelling.
• Hybrids: The most common approach, mixing elements of the above.

Designing your CRM

Which CRM (core resolution mechanics) dice should You choose? You don’t have to use dice at all, but percentile (d100) is often the best starting point. With a d100 you can map probabilities first while designing as a simple percentage without having to worry about solidifying your CRM just yet, then later convert those odds into whatever resolution engine you want, single rolls, dice pools, cards, marbles, even bidding systems (though those are trickier). This saves time by focusing on probability and outcomes before worrying about dice structures. Not every mapping will be exact (non–base 5 or 10 dice like d6, d8, or d12 rarely line up perfectly), but you can usually get close enough, and adjust further with pools.

Different engines fit different design goals:

• Short-term games with flatter progressions often work better with additive dice pools that produce curves (commonly 3+ dX), since these make small benefits feel relevant and results more consistent.
• Long-term or broader progressions tend to work better with single-die resolutions, which scale more easily as characters advance.
• Roll-over pools that count successes allow fine-grained results combined with predictable curves, though they can be fiddlier and slower/faster depending on dice volume and design implementation.

Always consider how many outcomes you need: a simple pass/fail system differs from games that require three or more result states (such as partial success or success-with-cost). Your die choice or pool should support the full range of outcomes your system promises/needs.

That said, there is no consensus on what makes a “good” resolution engine. People like contradictory things, and with varying levels of passion. Make the game first for yourself and your table, and next for anyone else who happens to enjoy it—not for those who won’t. A useful approach is to ask:

• How many narrative outcomes exist for a given roll?
• How are they weighted in probability?
• What modifier ranges are desirable?
• How many sources of modifiers exist, and of what type?
• What is the smallest die or set that can map those outcomes with the right percentages?
• At what point is the die or pool too large or small to showcase your intended probabilities?

Attack the problem from a functional angle first. If it works cleanly with minimal complication, it will probably also feel intuitive, which is what you want from a resolution engine. “Fun factor” matters, but treat it as secondary, chasing forced gimmicks usually leads to clunky results. Start with function, then refine with form. And when you’re down to two equally functional options, that’s when you test and ask the last important question: does this feel good at the table?

For even more info on various common decision engines head here, and keep in mind the opinions of the author are opinions, and really any of these or variations can be modified drastically for better and worse by the surrounding rules ecosystem.

It’s important to understand the basics of probability and average die rolls, especially how different dice sets or randomizers (like cards) create bell curves and influence granularity of results. Even if you don’t use dice, probability underpins how consistent or swingy your outcomes feel.

For example, a one-shot zombie survival game with high lethality should reflect harsh odds, while an anime power fantasy demands higher success rates, and a realism-focused combat sim will need probabilities tuned to simulate realism above all else. Many typical games peg base success around 65% for a “typical” challenge (rising with character growth), but your target numbers should match your design values and intended play experience.

These principles apply to any resolution tool—dice, cards, tokens, or others. What matters is that your chosen ratios and success states reinforce the feel you want. Be familiar with different methods like dice pools, roll-over, roll-under, step dice, roll-and-assign, contested rolls, and hybrids. Any can work if supported well by the surrounding system, but each has strengths and weaknesses depending on context. Tools like AnyDice are invaluable for charting probabilities and curves so you can compare methods quickly.

A brief historical note: in the 1980s, many games leaned heavily on use of the d6 because it was universally available in most homes included in popular board games people were likely to have as hobby stores that carried sets of polyhedral dice were often inaccessible (this was most popularly pushed by GURPS). That’s no longer relevant. Polyhedral sets are cheap (full sets can be purchased online for as low as 1 cent, the shipping costing more than the product), widely available for free online in most search engines (type “roll 3d6” in your search engine of choice, it probably does this), dice rollers are commonly built into website playspaces, downloadable apps,  and VTTs for free. Further, digital dice rollers can often emulate even more dice combinations like rolling a d57 (if you have such a need). Accessibility is not a valid reason today to restrict yourself to d6-only design. Use it only if it genuinely fits your design’s desired feel, not because of outdated accessibility assumptions.

Edit Down Your Work

“Refrain against overt utilizations of superfluous and extraneous verbosity when a singularly unloquacious and diminutive linguistic expression will satisfactorily accomplish the contemporary necessity.”

When designing your systems, edit down your work. If a single rule requires a paragraph and several explanations to define and explain it will benefit specifically from being broken up into bulleted points and organized into the order the information is needed by the reader.  

• The less supporting text a rule has, the more coherent it will generally be.  
• While the shortest possible explanation isn’t always the best, generally speaking, shorter and simpler is better when it comes to mechanical rules designs (KISS rule).  
• Using this method also cuts your overall word count and allows you to focus more on developing lore with your remaining word count in non-rules sections and focus on organizing the data in the order it needs to be received.  
• This is especially important for larger and more complex systems with more options and rules that rely more heavily on data organization.  

As you continue to write more rules for your game, filter each through the following lens questions:

1. Is it fun? Does it make the game more enjoyable?

2. Does it support the game’s intended play experience?

3. Is the rule clear and concise?

4. What player behavior does the rule encourage and is that a worthy endeavor in keeping with my design goals?

A brief note about rules scoping to keep in mind with editing: Rules Light ←  In between → Heavily Detailed, with various points along the spectrum.

Complexity, choice, and "realism" in a general RAW (rules as written) feel is AT BEST (you absolutely can make it worse with bad design) inversely proportional to simplicity/speed/accessibility (though hopefully not brevity). Further, too many complex rules can actually hurt "realism" when the systems' parts interact in ways that are non-intuitive.

Generating Lore

As mentioned in Step 1, it’s best to work on lore before diving too deeply into the rules. There’s no “correct” amount of lore, but a good guideline for a core rulebook is this: give a short vibe-setting description at the front, keep the big lore dump in the back, and scatter smaller lore pieces throughout the text where they support rules or examples. Supplements work differently, they should match their own design goals, whether that’s expanding the setting or drilling into a specific aspect of the game, or being mechanics focused, etc.

The strongest lore sections do two things:

1. Present a coherent vision of the world.
2. Provide open-ended tools, hooks, and threads for players and GMs to get excited about.

Endless fact lists that must be memorized tend to discourage play by creating barriers to entry. Instead, focus on broad details that inspire rather than restrict. Macro over micro.

The best lore gives players and GMs room to decide what they want to include, sparking creativity and ownership. Details are fine, but keep flexibility so players can easily carve out a place for themselves in your world and GMs have space to adapt minutia to make it their own.

Good vs. Bad Mechanics

A mechanic can be “bad” for many reasons, but the real measure comes down to your design values and how well you can articulate why a mechanic belongs in your game. “Why” is usually more important than “what” or “how.” Reasonable minds will disagree, but the key is clarity of purpose.

Instead of obsessing over “red flags,” focus on “green flags”, what makes a mechanic support your goals? To do that, let’s define the two main purposes of rules within a TTRPG:

1. Facilitate Roleplay. Players need enough information to inhabit their characters and act in a world that responds in a logical way (according to the logic of the setting). Your rules must allow characters to interact meaningfully with the setting. If you offload all world detail onto the GM, the burden is theirs (not recommended), but otherwise it’s your job to make the world intelligible and usable. Different players will have different needs, so aim for clarity and accessibility for multiple play styles (remember Manyfold?).
   
2. Provide a Gamified Experience. Your rules are the “physics” of the game world. They describe what is possible, from mundane actions to magic, psionics, superpowers, sci-fi/super tech, or whatever else might be relevant. A satisfying mechanic mirrors the internal logic of your setting and feeds back into roleplay decisions.

The sweet spot lies between too much freedom (anything seems possible, so nothing is clear) and too much restriction (players feel blocked from doing reasonable things). For example, a system that only lets players attack on their turn fails to account for healing, retreat, skill use, conversation, or defense, things most players expect. Conversely, a superhero game should allow wild, physics-defying stunts that would break a zombie survival sim. Communicate these expectations not just through text/rules/lore but also through your art, layout, and visual design. Grim fonts and oppressive textures signal a different truth than candy-colored castles and talking ponies.

A good mechanic is one that:

• Represents character experience in a way that feels intuitive.
• Produces identifiable results without needless complexity (as complex as is required and but no more than)
• Helps players make reasonable decisions in character.
• Feeds into and reinforces the core game loops.

To support this, establish design pillars aligned with your goals and intended play experience (what are the characters supposed to do?). Common examples are combat, stealth, and social interaction, but pillars can be anything that defines your game which does not have to include combat or stealth (but generally social is good in most cases to have for communication purposes). Like a table, three sturdy pillars usually provide balance, while four can add depth of stability. More than that usually risks unnecessary engineering complexity (a five legged coffee table) that can introduce problems/faults/bloat.

Finally, be cautious with overreliance on math or statistics. Numbers only matter in context. Data stripped of its setting can mislead. This graphic (left) clearly shows that “god” clearly dislikes cameras as he refuses to perform as many miracles for humans unless humans can modify that documentation (that’s satire, in case it wasn’t clear). The point being, statistics are only relevant within specific contexts, and without that specific context any derived conclusion (assuming the collection of data was unbiased, ethical, and impartial with a decent sample size to begin with) is going to be, at best, misrepresentative disinformation rooted in ignorance.

As a common example of use of bad statistics, citing medieval accuracy is irrelevant in a world with dragons and spellcasters. Research your influences, but always filter them through the lens of your game’s reality and desired tone.

Step 5: Determine your Game Modes

A game mode in the context of a TTRPG is any distinct phase of play where different rules apply. Modes often define how time flows are measured (dilation or contraction), what actions players can take within the mode, and may affect how resolution is handled.

In most TTRPGs, exploration is the default mode. Time moves in scenes, players act freely, and there is no strict turn order. A common secondary mode is combat, where actions are limited, time is broken into rounds, and turns are often resolved by initiative (sometimes using grids, tokens, or other tools).

Beyond these, your game may include other specialized modes:

• Downtime for crafting, training, mundane travel, or recovery.
• Mass combat for resolving battles between armies.
• Investigation for piecing together clues in mystery-style play.
• Hexploration for structured overland travel and discovery.
• Intricate social systems such as reputation or faction standing.
• Base building, plot clocks, or other structures unique to your game’s focus.

The key is to define which major shifts are essential to your design. A mode should only exist if it supports your intended play experience. Each mode should be clear about:

1. How time is measured.
2. What actions are available.
3. Which rules apply.
4. What triggers the transition into or out of the mode.

This prevents overlap and confusion when rules “bleed” into each other. It also ensures you can provide meaningful mechanics and options for each relevant mode during character creation.

Scope caution: only include the modes essential to your minimum viable product (MVP) in the core book for larger style games (smaller games can have some extra bloat because they have the space for it). If your game is primarily about crafting or base-building, include those from the start. If not, consider postponing them to later supplements. Overstuffing with tertiary modes leads to bloat and unfinished systems.

Common examples to consider:

• Character generation and progression
• World generation and progression
• Exploration (default mode)
• Social encounters
• Hexploration (travel and discovery at the party level)
• Meta currencies (instant or retroactive resource spends)
• Combat
• Mass combat
• Downtime
• Altered Movement such as chases, races, vehicles use, flight/swimming/burrowing, etc.

You don’t need to use all of these. What matters is having an explicit answer, even if that answer is, “This game doesn’t use that mode.”

Step 6: Determine your Sub Systems

For larger systems, decide early whether you want modular subsystems. These are self-contained rulesets that reference themselves (and often the core resolution engine), but don’t depend on other subsystems. The benefit is flexibility, tables can choose to use or ignore them depending on player needs. For example, a hacking mini-game might only apply if someone is playing a hacker.

Subsystems are essentially mini rule packages tied to game modes or specific situations. They shape how niche elements of play are resolved: hit points vs. wound tracks, how grappling works, or whether damage exists at all. Notably often what makes something a subsystem is whether or not it is absolutely essential for the game to function as intended.

A good common example is Dungeons & Dragons spellcasting. It’s modular: you can play with a no-caster party or even remove magic from the setting entirely, and the game still functions (arguably, characters will have significant difficulties without access to magic items and healing, etc.). But for groups who want it, the subsystem provides a rich set of mechanics.

You won’t get every subsystem right on the first pass. Some may get cut, others added later once playtesting shows they’re needed. The best approach is to start by asking: What is this game about? Your design values will point to the essential subsystems: A paranormal investigation game needs investigation tools/systems, a knock off harry potter wizard-school game should have custom wand mechanics, etc.

Common Subsystems to Consider:

• Altered Movement
• Status Effects (buffs, debuffs, conditions)
• Wounding
• Damage Mitigation (armor, shields, evasion, stealth, incorporeal forms)
• Rest/Recovery
• Turn Order (initiative or alternatives)
• Skill Usage / Skill Mini-Games / Group Skill Challenges
• Battlefield Tactics (cover, concealment, terrain, weather)
• Consumable Tracking (ammo, money, potions, durability, survival elements)
• Equipment Systems (gear, crafting, or even base-building)
• Special Abilities (powers, feats, spells, psionics, teamwork actions)
• Investigation Systems (dedicated mechanics for mystery or discovery play)
• Item Crafting / Enchanting / Base Building
• Social Dynamics (factions, relationships, reputation)
• Random Generators (encounters, NPCs, hooks, tables)
• Anything else that might apply to your game.

You don’t need all of these. But you do need clear answers for each, even if the answer is, This game does not include that subsystem.

Step 7: Designing your Systems

At this stage, you’re taking your decision engine, applying it to each game mode or subsystem, filtering it through your design values, and balancing until you’ve achieved the intended play experience. That’s the whole process in its simplest form.

Yes, system design can be made endlessly complicated with Design Theory, UX, R&D, STEM-heavy experiments, and additional philosophical naval gazing, but none of that is required to get a playable demo. Those are tools you can dive into later if you enjoy design deeply. For now, here’s the hack: look at what already works, copy the concepts (not the exact text), and innovate where you find pain points (and test). Always remember: the behaviors your rules reward are the behaviors your game will incentivize in players.

Start by listing out the variables. For a base CRM system, this usually means understanding your CRM’s success states:

• Simple binary: Pass / Fail
• Multiple success states example: Crit Fail with complication → Fail → Success with Complication → Success → Crit Success

For a subsystem, list the variables that matter. For example, a weapon subsystem might include:

• Damage Bonus
• To-Hit Bonus
• Parry/Block Bonus
• Range/Range Bonus
• Area of Effect Radius
• Etc.

Once you know the variables, the job becomes mostly about form filling and balancing. Assign values that make sense given your decision engine’s probabilities and your intended success ratios. Then playtest.

After each test, identify pain points, adjust solutions, and test again. Rinse and repeat. With each iteration you’ll inch closer to  the best version of your playable demo.

Naming Conventions

A naming convention is just a set of rules for naming things consistently. The question is usually framed as: should names be clear and easy to understand, or thematic and immersive? The real answer is both, like peanut butter and jelly, the balance just depends on how much of each you can merge effectively.

• Clear/Familiar names reduce cognitive load. Players don’t need to memorize lots of new terms to understand the rules.
• Thematic names add immersion and atmosphere, helping the game feel distinct.

The problem is that each does what the other doesn’t. Sometimes you can blend the two, but cultural and language differences limit how far you can go.

Scale also matters. The bigger the game, the less space you usually have for obscure or highly thematic naming, because players are already spending cognitive load on rules, options, and interactions. Smaller games can afford more obscure thematic terms since the overall load is lighter.

Audience also matters. For example, my current project leans into espionage. If I use a term that is a nod to James Bond (without copyright infringement), the intended audience will likely get it and enjoy the flavor and reference. If the game were high fantasy, hard sci-fi, or written for kids, the same reference would likely miss.

General Guideline: add as much atmosphere as you can without losing accessibility for your audience. And don’t rename things simply to be different (have a thematic reasoning). If a common, established term already describes your mechanic perfectly, use it. That makes onboarding new players easier.

Using A.I. for Working Through Ideas

Absolute Basic Rules for AI use:

1. If you have strict moral opposition and outrage to AI use of any kind, don’t use it, full stop. Skip this entire section and move on.

You didn’t go yet, so I’ll tell you a “secret”: there are more ethical solutions available discussed below and it can be a useful tool.

2. Never copy and paste anything from generative AI directly into your final product. It’s not yours and that is plagiarism even if legal, and also can include massive inaccuracies and inconsistencies due to AI hallucination. With that said, it can be a useful tool to develop ideas, particularly generic lists of things for rapid prototyping.
3. AI suites are a tool and have a learning curve. You absolutely do need to learn to use it like any software tool and you can train it to be a bit “smarter” so long as you learn how to better prompt and fine-tune it correctly for better results with training data.
4. AI is not a replacement for artists and craftsmanship. It’s good for bouncing ideas around at 3 am when nobody else is available, but I’d still recommend being part of a design community because AI simply still has a very long way to go in overcoming limitations and it’s not functionally better than talking with other talented designers about high concept ideas and constructive criticisms. In particular it’s good for generating well established mundane content in bulk, and very bad at generating fresh new ideas and concepts. AI is great for helping creative people do tedious things, it is terrible at helping tedious people do creative things.

An example of what I consider responsible AI use: I was working on my vehicle supplement and wanted to model/stat a large variety of modern vehicles that would be useful in all sorts of situations for my game. I could have spent weeks online doing research for all the kinds of varieties of vehicles I wanted to model, or I could spend a couple of hours with AI to determine an appropriate list.  I would still need to do my due diligence to verify the information, and stat it out by hand appropriately within my system, but this helped me create a list of vehicles that met my needs saving potential weeks of time researching.  I didn’t copy and paste that list, but I used it as a starting point to develop my vehicle supplement. This information was all publicly available, but it was able to compile this list for me to about 96% satisfaction in 4 hours or so (again, as opposed to weeks of research and I still had to correct and tweak it). This would be considered a form of help with rapid prototyping, not having the AI do my work for me. All of the individual stats for my system were all developed by hand, rather, this only generated specific model types to use as references for my creations.  As such I was able to develop multiple types of buses such as: Articulated, Commuter, European Double Decker, School, Special Needs, and Tour Coach. Not being an expert in buses I might have spent half a day in a research hole to discover all of those options rather than a minute or so for just one type of vehicle.

How to avoid ethical conundrums with AI:

All moral concerns with AI use as a tool are rooted in problems with late stage capitalism and can also be fully circumvented.

Misconception 1: All AI Models are trained on stolen data.

I’ll leave the exact legal ramifications to the courts regarding improper use of scraped data (which is likely fully true in most big tech cases), but even if we assume all scraped data without consent is in absolute legal fact data theft, does this apply to all major big tech AI services? Almost all, yes. There’s some debate about informed consent regarding use of owned stock image libraries, but technically that is absolutely agreed to and consented with the caveat that people don’t consider what it means when they click the yes to all terms and conditions, and that’s legally their contractual liability. Anyone that doesn’t understand to read and understand contracts they assign isn’t competent in a legal capacity by definition.

But what about all AI?  Absolutely not. You can access and use AI trained ONLY on public data.

By far not the only example of public only trained data, but one supported by scientific study shows this is FAR easier than it sounds (only 8 TB of public data needed for from scratch training) and shows clearly that this can be done with peer reviewed research.
Article HERE  followed by research white paper HERE.

This common misconception is mostly rooted in:

• Ignorance of people that don’t use and refuse to learn about AI models.
• An intentional lie from the big tech companies.  They specifically made arguments early on that they “HAD TO” do this, but they didn’t (as shown in the papers above, the performance of that model exceeds all early models). The reason they “had to” was to be first to market to gobble up all money and sell AI as hype. This proved massively effective once they and other big companies realized the data harvesting potential of putting AI into literally everything (this is largely why AI is in practically every digital product now).

If you’d like to use models that are only trained on public data and publicly donated data:

LLMs (large language models): Here's 4 right away that have research white papers support.

Here's a 15TB DB training set to make your own from scratch if you’re at all code capable (almost twice as big as the one used in the 8TB paper).

If you want Image Generation: Look into Mitsua Diffusion 1 (2nd generation model, been around for a minute), and Public Diffusion (currently in beta as of writing with revealed works of much higher quality).

You can then micro tune most AI’s with your own data (that you own), and specialized instructions and protocols to be more useful to you.

Misconception 2: AI causes job displacement, particularly for creatives and artists.

Not really. Companies that laid off mass workers to replace them with AI found it to be too dumb to do most things competently and with accuracy, and either quickly corrected and rehired individuals or went under. If it was that easy, McDonald’s with their ridiculous money would have already replaced cashiers (that’s called foreshadowing).  They tried and it failed spectacularly, so much so that even mainstream news covered it.

Additionally, as previously mentioned, AI is bad at being creative because it’s essentially regurgitating/remixing common data it’s trained on as output (whether an LLM or Generative Image creator, usually diffusion based), essentially it’s a slightly more advanced version of predictive text on your phone.

Regarding disruptive tech in general, all disruptive tech does in fact change the market and jobs, but inevitably this always produces more, different jobs every single time in history, and further, hand crafted/curated products then have an inevitable revival in about 10 years time at 2-3x markup. Doomers exist for every disruptive tech claiming it will destroy society back to the invention of writing, to include other things like electricity (see the cartoon, left, circa 1889), the printing press and more recently rideshares and 5G, all with extensive historical documentation.  To get art specific: Cameras didn’t end painting. Photoshop didn’t end photography. Drum machines, sampling, records, and streaming services didn’t end music. In all cases they were prophesied to destroy the medium and then went on to expand their markets.

Even TTRPGs are relevant here. Writing and the printing press would both (at separate times) destroy story telling. TV would end books. The internet and video games would end TV. Now we have TTRPG books and PDF files that let us do collaborative story telling which we can play online with people across the planet using VTTs the simulate many video game features (which some TTRPG enthusiasts maintain “ruins TTRPGs” despite many people liking online play and VTTs) and the TTRPG market is only growing as a result of becoming more accessible. Story telling is still alive and well.

AI won’t take artist jobs, skilled artists that use AI to increase output by automating tedious tasks will take more jobs. This is inevitable and already happening now. Additionally as the younger generation grows up with the technology they will incorporate and advance its uses to greater effect, concerns about AI will be more nuanced regarding how much, where, and why. The rest of the economy will be forced to adapt or become irrelevant fringe weirdos like people who don’t get vaccinated “because it puts tracking microchips in your blood”.

Will AI ever truly replace skilled individuals for art production? Not any time soon by the looks of it. Probably at some point if the species survives long enough, but at that point it will be functionally better suited to the job than a human. Which brings us to our next major misconception…

Misconception 3: AI Model use and training destroys the environment.

Similar to point 1, Big tech companies?  Absolutely, just like all major companies. But all AI?  

Posit this: You use one of the publicly trained AI’s above, possibly even creating and training your own model. Then you put it on your PC for privacy and environmental reasons. You use your own paid electricity. If you want to get fancy, drop a solar panel system on your space and change from using ANY gridded energy to reducing your carbon footprint to 0 for electricity and further benefitting the environment by selling your surplus clean electricity back to the grid (now you’re not only not making things worse, you’re helping the problem that isn’t your fault).

“Misconception” 4: AI can be used unethically (there’s lots of examples of how this can apply).
This is less of a misconception and more of a reality check. Every tool, EVERY TOOL, can be weaponized or used for public good, be used with good or ill intent, and used masterfully or ineptly. See cleaner atomic energy vs. the atomic bomb or knife used to cut food into more readily eaten bites or to stab a person or code used to create the internet as a repository of knowledge or steal your grandma’s life savings.  AI is no different.  AI has been used for major science and medicine advances extensively already. It’s also been used to flood markets with AI slop and is being used by the military to better pilot drones (the US military is literally working on SKYNET and terminator equivalents as of writing). Companies are harvesting your data everywhere on the net, and even more bot spam with even more convincing disinformation will be part of all future election cycles. There’s lots of individual unethical uses of AI, that’s true, and something should be done about that. But you can’t control how others choose to use a tool even with laws (Evil Megacorps are gonna Evil Megacorp), but you can choose how you use it.

Additional Concerns with AI Usage

Any use of generative AI in the final TTRPG production workflow (particularly regarding image generation) is still currently very much disliked very vocally by many.  In extreme cases this has even led to death threats to people who openly label their TTRPG product as having used AI assets and gave it away for free in more than one instance. If further clarity is needed: death threats and harassment are not acceptable behavior and that kind of activity is indefensible. This is very slowly changing as people are starting to become more concerned about larger issues rather than AI existing as a fact of matter, and becoming more educated about it. To that end, here's an article you can use to be better informed when speaking about ethical data claims and AI, please consider that essential reading if you choose to use it. If you do use AI in your workflows be sure to indicate how much, where, and why so that others can make informed decisions if they would like to purchase. Additionally, it’s not at all uncommon to find that even when confronted with scientific papers as evidence as I’ve linked above, and articulately and thoughtfully responding to all concerns, that some people will not change their minds in light of expert evidence and will choose to be very angry about AI not matter what you say.  This should not be shocking if you’ve ever argued with anyone on the internet that insisted they were right even when you functionally proved their argument to be invalid. In those cases it’s best to identify early and move on so as not to waste your own time.

Understanding What has Come Before

The best way to improve at design is to study what has come before. This means both understanding the design conventions past games established and seeing how later systems iterated on them. The most direct way to do this is to read and play many different kinds of games. While TTRPGs should be your main focus, don’t ignore board games, video games, or card games—each offers valuable lessons you can adapt to RPG design. Inspiration can come from anywhere.

No system is perfect, especially older ones, but even flawed designs contributed ideas that shaped the modern space. What matters is recognizing not only what each system introduced or popularized, but also how those contributions influenced later games. Learning why they worked (or didn’t) will help you decide whether to adopt, adapt, or avoid them in your own work.

Below is a minimal list of notable TTRPGs and the key concepts they popularized. This is not definitive, only a launch point. Your real growth as a designer will come from constantly learning, playing, and analyzing games firsthand.

Disclaimer: Some of what follows is objective history, much of it is opinion. Modern design theory is rarely absolute. Do not take any single perspective, including mine, as gospel. Research, play, and form your own conclusions. Also note: none of the products below have sponsored this section; inclusion is for fair use, educational purposes only and is presented in chronological order.

Shortcut part 1: If you want a definitive short list to start with I’d recommend: Blades in the Dark, Mothership, GURPS, DnD 4e.  Why? Check out this video which I largely tend to agree with.  I will add my own honorable mention onto this list of BRP as an essential tool for all new system designers  (I know I recommended it to people who don’t want to build a system above), not because it’s special and wonderful, but because as a toolkit to build a system and can give you lots of things to think about and modular ways to incorporate systems you may not be aware of if you have minimal system design experience. The only places it really falls short is with Cybernetics/Bionics and highly specialized equipment (for games that really want gear focussed characters) to give you a really solid foundation of the kinds of systems you might want to include, and various ways you might go about implementing them.

Shortcut part 2: OK you did the entry level stuff, how about some more advanced considerations? Next check out: PF2e, Mork Borg, RoleMaster, Apocalypse World, And “Weird Stuff” with my personal recommends of these being: Everyone is John (3 pages, or you can use the original 1 page version), and Brindlewood Bay (168 pages). Why? You guessed it, Video Link.

Dungeons and Dragons 1st edition (1974):  
The first edition of Dungeons & Dragons was the breakthrough that defined the commercial TTRPG space. While it borrowed heavily from tabletop wargames like Chainmail, it popularized many mechanics that became foundational: attributes, hit points, spell systems, skills, polyhedral dice, variable target numbers, and more. Even in their primitive form, these systems established a framework that countless later games would build upon.

Importantly, the original edition created a distinctive style of play—what is now often called OSR (Old School Revival/Rules). These games emphasize player creativity, hijinks, and sandbox-style problem solving rather than the cohesive narrative arcs common to modern campaigns or adventure paths.

Studying 1e today is a bit like an anthropologist examining primordial goo: weird, fascinating, and deeply informative, but not necessarily practical as a design model on its own. Modern games (including most OSR revivals) filter its ideas through decades of iteration and refinement. If the game were released today, stripped of its cultural legacy, it would almost certainly fail commercially.

Still, its historical value is enormous. Context is one of the most important tools in design, and understanding where these mechanics began helps us answer the crucial question: “Why?” Why do our games look the way they do? Why did certain conventions survive while others faded? That perspective is invaluable to any designer.

Call of Cthulhu (1981):
This game (CoC) was an early system that has managed to legacy its way into being one of the most played games in the current space after Dungeons and Dragons 5e. The system popularized level-less character progression and failure as progression, though these would not remain its most defining features. More notably, the sanity system, which has since evolved extensively, gave players something to interact with in an emotional way, supported episodic or serialized stories, and emphasized a more explicit type of horror than D&D. Just as importantly, cosmic horror tropes have since spread across nearly every genre and design space. Call of Cthulhu can also be credited with paving the way for future adaptations of the zombie horror survival one-shot genre. While CoC itself is not about zombies, its core experience, ordinary people facing supernatural horrors that vastly overpower them, translated directly into these newer games. Those games, in turn, influenced the survival mechanics and post-apocalyptic titles that followed.

GURPS (1986):

This game is notable for popularizing fully open point-buy, removing class or ancestry restrictions and instead letting players customize characters however they liked by spending points on advantages and disadvantages. At the time, this was revolutionary, and in many ways set the stage for what would later become feats in d20 systems. Point-buy remains a staple mechanic in many games today, though few offer the same level of flexibility as GURPS. Its other major claim was being a truly generic system that could be applied to any world or genre, though this came at the cost of not including a built-in setting in the core rules. Later releases of setting materials would be added to fill that gap.

This openness was a major selling point in the mid-80s, as players were eager for options beyond traditional fantasy. Star Wars by West End would not appear until the following year, and games like Cyberpunk and Shadowrun were still a few years out. Palladium had begun exploring multiple genres earlier with Fantasy (1983), Heroes Unlimited (1984), and TMNT (1985), but it was not until 1990 with Rifts that they reached wider circulation alongside D&D and GURPS. In hindsight, GURPS’ generic advantage was tied to its timing. Today the market is crowded with both generic systems and highly specific niche systems, meaning that the same pitch carries less weight. Even so, GURPS continues to maintain a dedicated player base in the modern space.

Vampire: The Masquerade/WoD (1991):
The World of Darkness (WoD) line popularized several mechanics, including dice pools (though Shadowrun introduced them two years earlier), wound tracks, and the nature/demeanor system—a prototype for what would later become more robust storytelling frameworks like those in Burning Wheel. Its biggest impact, however, was its focus on emergent narrative. WoD was the first major successful release to explicitly state that its design goal was to produce story arcs centered on social interaction and roleplaying as a chief priority, rather than combat.

This intent was reinforced mechanically through systems like vampire hunger, which tied player motivations directly into gameplay. It also gave players a rich, socially-driven world to explore, where interpersonal dynamics were just as important as combat, and reintroduced PvP elements that had largely been abandoned by other games at the time. The influence was so strong in reception that even Dungeons & Dragons began shifting design priorities in response with the 3e and 3.5e follow ups.

WoD clearly drew inspiration from Call of Cthulhu in its use of personal horror, but it flipped the perspective: instead of playing as fragile humans against the supernatural, players became the supernatural horrors themselves, indulging in a form of power fantasy largely absent from the medium at the time. This inversion of expectations created a distinctly different play experience and proved highly influential. Other media would not explore similar territory until years later (e.g. Blood Omen: Legacy of Kain in 1996 in video games, and in TTRPGs major releases, the Book of Vile Darkness in 2002), giving WoD a unique place in TTRPG history.

Twilight 2000 (1991)

Twilight: 2000 (often called Twilight 2k) remains one of the crunchiest systems on the market, standing alongside games like Phoenix Command and RoleMaster in terms of sheer complexity. Its rules are not beginner-friendly by any reasonable metric.

The key lesson from this franchise, now in its 4th edition (2021), is that not all game designs need to be small, lightweight, or streamlined. There is a dedicated audience of die-hard gamers who love nothing more than rolling on crunchy tables all day, resolving results through intricate mechanics, and digging into systems that account for minute details (“Grognard” being the frequent terminology being typically associated with the style though the word has other implications).

As an example, the core rulebook doesn’t just provide one stat block and illustration for an Abrams tank, but two nearly identical Abrams variants, alongside numerous other armored vehicles. This level of detail may seem excessive to some, but for its fan base, it’s an essential part of the appeal.

The continued success of Twilight: 2000 is proof that high-complexity, high-density game systems still have a strong place in the market, even as much of the indie design space trends toward lighter, rules-minimalist approaches. As always, there is no single “right” way to design a game.

The Forge (2001)
Unlike the other entries on this list, The Forge was not a game system but a now-defunct TTRPG design forum from the early 2000s. It operated as a TTRPG system design think tank, the only one of its kind at the time. This stood in contrast to something like RPG Design (a current resource I recommend), which functions more like a workshop. The key difference is that The Forge emphasized theory above all, while RPG Design emphasizes helping creators refine their own projects without pushing it through a unified theoretical lens that may not be suiting.

Many notable designers emerged from The Forge, and two major design theories came out of it: GNS and the Big Model. I will not go into heavy detail here because these frameworks are not especially relevant to the modern design space, save among a small handful of designers who still insist on them. They can be useful tools in very narrow situations, but they are deeply flawed and have been debunked in various ways by countless modern design examples that better explain the craft. If you want more depth, William White’s book is a useful read.

It is worth noting that, even today, someone may occasionally insist on GNS or the Big Model as though they are authoritative. In truth, the design space has expanded so far beyond their definitions that they can only be applied in a limited way. At most, they may have some utility in marketing or in explaining basic concepts to players who lack system design literacy, but they have little function in current design theory. That said, The Forge retains historical significance. It was the first major effort to codify and centralize tabletop design thinking on the English-speaking internet. It also informed the early development of several talented designers who went on to create games that remain influential today. While its models should be treated as low-priority for research, being aware of The Forge prevents blind spots in understanding how modern design discourse evolved.

Burning Wheel (2002)
Burning Wheel was far ahead of its time, introducing mechanics that wouldn’t become common until decades later. Its major contributions include collaborative worldbuilding, tag-based character backgrounds and motivations (instincts/beliefs), and the “let it ride” rule. By transforming GURPS-style advantages and disadvantages into narrative drivers, it shifted RPGs toward character-driven stories. These ideas were later refined in Mouse Guard (2008), also by Luke Crane. Ultimately, Burning Wheel recaptured the best of early D&D while pushing the medium toward narrative-first play.

F.A.T.A.L. (2002)

FATAL is widely regarded as the worst designed TTRPG ever made, and for good reason. Much like Troma Films turning academic criticism of their films into the borderline unwatchable movie Terror Firmer, FATAL feels almost like a parody of design itself: bloated, indulgent, and strikingly unpleasant. Its combination of poor mechanics, excessive crunch, and outdated, patently and excessively offensive content makes it infamous across the hobby. Yet, like studying a colliding train disaster in slow motion it can be fascinating to witness and  can even be instructive, serving as a masterclass in exactly what not to do. While not worth playing, skimming it with a designer’s eye highlights pitfalls to avoid, which may be its only lasting value, but still stands as “some kind of achievement”. Not surprisingly it’s not for sale, but if you really want to read it a bit of internet search sleuthing should turn up a copy in short order.

Dungeons and Dragons 3.5 (2003)
This edition marked a major shift away from Gygaxian roots, adopting lessons from more modern systems and pushing the game firmly toward heroic narrative. Feats became central, AC was streamlined, and overall accessibility improved. But the true legacy of 3.5 lies not just in mechanics, but in the introduction of the SRD and OGL, which opened the doors for third-party creators. This move fundamentally reshaped the hobby, directly leading to Pathfinder and setting the stage for the wider ecosystem of independent publishing that defines the modern TTRPG market.

3.5 also exposed players to a new phenomenon: rules and content fatigue. While power creep was familiar, what became clear was that the sheer volume of expansions eventually made the system unmanageable. No individual or even the digital tools of the time could track all of it, and the original game experience became buried under the weight of its own success. This realization helped the community accept that new editions were sometimes necessary, even if 4th edition’s reception was rocky. Ironically, many of 4e’s most criticized mechanics are now recognized as ahead of their time and highly influential in today’s design space (though it also had other notable shortcomings).

Ars Magica 5e (2004)
Ars Magica is most notable for its noun/verb system for magic and spell creation. There’s not too much more to say about it other than the system is interesting and worth a look just for the sake of it even if you don’t use magic in your game (specifically as a proto version of tag based creation, and specifically that can be used in a live setting).  Under the hood it bears some resemblance to City of Mist Tags, but has more structure to it while still keeping a very open system.  Additionally there are multiple iterations of it across the editions, with each addressing different kinds of concerns, showcasing iterative design well across multiple genres.

 
Dogs in the Vineyard (2004)
Dogs in the Vineyard was a seminal game that introduced a lot of ideas that would push away from the more mainstream success of combat mid crunch sim-like games of D&D 3.5 and Pathfinder in a way that would shape a lot of the indie development scene to come as TTRPGs started to become a mainstream industry for the first time after having undergone an extensive underground due to things like the US 1980’s satanic panic involving dungeons and dragons.

The major contribution it made popular specifically was the concept of bids as conflict resolution and raises to increase/alter statistical outcomes.  This namely put dice now on the table as a kind of resource management, which wasn’t a previously widespread concept.  While the game is defunct, the system has since been licensed without the setting and a lot of its important innovative work can be seen to influence other systems like SWADE.

Apocalypse World and PbtA (2010)
Mechanically, these games are most notable for their “moves.” Each move is designed to elicit a specific type of narrative outcome, with the details left to player and referee interpretation based on the dice results and current fiction. The intent is less about crunching numbers on a chart and more about injecting imagination into the flow of play. This structure also helped popularize “success at a cost” and risk/reward design, paving the way for many rules-lite systems that now dominate the indie scene. The strength of this approach is narrative flexibility, but the weakness is that it relies heavily on referee judgment. While not inherently a flaw, it can magnify problems with GM fiat in less experienced or emotionally immature groups.

The true legacy of Apocalypse World is not its flagship game alone, but the Powered by the Apocalypse license. With minimal restrictions, it allowed indie designers to publish and profit from their own PbtA games. This not only expanded the brand but also empowered a wave of independent creators by giving them a trusted, familiar framework that made new games easier for players to learn. In many ways it repeated the SRD/OGL model of D&D and Pathfinder, but with even greater benefit to smaller publishers. Today PbtA is not just a system but a recognizable brand category of TTRPGs (similar to more recent X-Borg style games), with influence rivaling entire genres.

Savage Worlds (2012)
Later known as SWADE, Savage Worlds grew into another generic system, but unlike many others it distinguished itself with a focus on tactile mechanics and gimmicks that aimed to refresh how TTRPGs were played. Notable innovations included using dice as ability scores, exploding dice, raises, a deck of cards for initiative, and bennies—a distinct spin on the classic “hero point” concept later echoed by 5e’s “inspiration.” Savage Worlds also followed Palladium’s model of licensing and adapting established properties, most prominently RIFTS and even Pathfinder. What stands out, however, is how its emphasis on gimmick-driven, interaction-focused design went on to influence a wide range of independent creators.

Lasers and Feelings (2013)
Lasers and Feelings is one of the best-known examples of the “1-pager” RPG genre, famous for being stripped down to a single page and built around just two opposed dynamics: lasers and feelings. Its extreme simplicity makes it a benchmark for minimal design, often considered the furthest a game can be reduced while still delivering cohesive play. Attempts to go further in stripping down exist but typically collapse in key play areas.

The game is a valuable study not only for small RPG projects but also for larger, more complex ones. The bigger the project, the more important it becomes to be concise, focused, and purposeful. Lasers and Feelings demonstrates how much can be achieved with very little, successfully meeting its design goals despite inherent limits in complexity.

Dungeons and Dragons 5e (2014)
It is impossible to discuss modern design without acknowledging 5e (or 5.5e/6e/One DnD/whatever), the reigning giant of the hobby. While some credit its dominance to legacy branding and a massive marketing footprint, its success cannot be dismissed as just advertising. If it were not a solid system, it would not have become the most widely played TTRPG in the world.

Critics often complain that 5e is “dumbed down,” but its accessibility is also its greatest strength. The streamlined rules lower the barrier to entry, bringing in waves of new players. Its most notable contribution was the heavy use of advantage and disadvantage, a mechanic that drastically shifts probability in a simple, intuitive way while replacing messy bonus stacking. Other design choices, such as restricting similar bonuses, attempted to control power creep (though supplements inevitably reintroduced it).

At its core, 5e is a monster-looter: the game revolves around fighting monsters and collecting rewards. This clarity of purpose makes it incredibly effective for onboarding new players. While the system can support narrative play, it generally does so in spite of the mechanics rather than because of them, unlike narrative-driven systems such as Burning Wheel, PbtA, or Fate. Still, 5e’s straightforward “kill monsters, get loot” loop has been crucial to expanding the player base and, by extension, fueling the explosion of the indie TTRPG scene.

In recent years, however, WotC/Hasbro have faced intense backlash over extensive unethical business practices, OGL controversies, and an expensive and time consuming push toward a digital VTT future that resulted in a major flop. The reception to these changes has been mixed, with some players migrating to alternatives like Pathfinder 2e, Daggerheart, or MCDM’s Draw Steel. Even among dedicated fans, enthusiasm has cooled. 5.5 version rules are being met with trepidation, but do offer some lovely new art and sensible rules updates, as well as some questionable choices.

Blades in the Dark (2017)
Often touted as the modern-day manual for indie TTRPG designers, Blades in the Dark revolutionized design thinking by narrowing its focus. Instead of trying to be a system that could do everything poorly in an inch deep/mile wide compromised way, it honed in on doing one thing extremely well: heists. This singular clarity of purpose is arguably its most important contribution and has reshaped the indie design space more than any other element.

Mechanically, Blades inherited some spirit from Call of Cthulhu in that advancement is tied to what players do rather than simply increasing raw power. Conflict resolution uses player-facing dice pools where consequences flow directly from player choices, reinforcing agency and narrative ownership. While the game clearly shares DNA with PbtA, it distinguishes itself enough to be seen as a parallel branch rather than a clone.

The system also popularized stress mechanics and narrative clocks in new ways. While both ideas trace their roots back to earlier war gaming and RPG conventions, Blades reframed them as tools for pacing, tension, and broader narrative consequences. This design choice gave players and GMs a shared language for escalating danger and tracking long-term story stakes. The key lesson being, sometimes the best way to innovate is not to broaden scope but to sharpen it by focussing on one core experience and designing everything around it making the experience as strong as possible.

City of Mist (2017)
City of Mist is a PbtA game notable for popularizing the open tag system that first appeared in Lady Blackbird (2009). Since Lady Blackbird was a single adventure module, the idea remained niche until City of Mist brought it into a full-fledged system. Tags work like modular descriptors that players define themselves, giving bonuses tied to character traits, backgrounds, or themes without needing hundreds of pages of codified rules. In this way, the system stays closer to the rules-light spirit of PbtA while still offering deep customization.

The tag system introduces quirks. Broad tags can feel overpowered compared to narrower ones, and new GMs may struggle to balance their players’ definitions. However, because the GM adjudicates whether tags apply, most of these issues resolve themselves in actual play. Once GMs grow comfortable with the framework, the system tends to run smoothly, rewarding creativity while keeping bookkeeping light.

In essence, City of Mist shifted the collaborative creativity sometimes used in worldbuilding (see Burning Wheel) to character creation itself. This reinforced PbtA’s emphasis on imagination over charts, providing an alternative to more simulation-heavy systems like GURPS. The key take-away being that tags demonstrate how open-ended, player-defined mechanics can empower creativity and reduce rules load, provided the system gives GMs enough authority and guidance to keep play balanced.

Index Card RPG (2018)
Index Card RPG (ICRPG) is built around one core idea: you should be able to fit everything you need for a character on an index card. The system is highly streamlined and easy to use, with accessibility as a primary design goal. While D&D 5e aimed to be more welcoming for new players, ICRPG was designed from the ground up to make play simple, fast, and approachable. This focus has made it one of the most popular non-D&D games on platforms like Roll20.

Despite its simplicity, ICRPG is not only for beginners. Its flexible mechanics support a wide range of stories, and its modularity allows tables to scale up or down in complexity as desired as well as being noted for the potency of its GM advice section. It isn’t built for hardcore sim enthusiasts, but it excels as a “beer and pretzels” game, easy to pick up, fast to play, and open to a huge variety of scenarios.

It’s important to distinguish ICRPG from ultra-minimalist games like Lasers and Feelings. While both are streamlined, ICRPG is designed to be stripped down yet still offer layers of mechanical depth when needed, allowing for a broader spectrum of play experiences. The key takeaway here is that accessibility can be a primary design value. By reducing cognitive load while still allowing optional complexity, ICRPG proves that simple systems can remain versatile, have depth, and be widely appealing.

Mothership (2018)
Mothership is often celebrated as a masterclass in distilling design principles and UX, earning numerous awards and praise from systems designers. Its snappy aesthetic immediately communicates the game’s tone, while flowcharts in both the rulebook and character sheet make navigation seamless. The mechanics are minimal yet powerful, carrying significant weight without overcomplication.

Rather than inventing new technologies, Mothership refines existing ideas to a commercial and intuitive brilliance, particularly in terms of UX and the elusive “fun factor.” It stands as an essential study for designers seeking to understand how to build systems that are light yet robust, satisfying, and deliberately hackable, designed to encourage house rules and player modification as part of its core philosophy.

Pathfinder 2e (2019)
Pathfinder 2e’s standout innovation is its three-action economy, especially in combat. Few would dispute this as a major improvement over earlier d20 action systems. Unlike D&D 5e, which emphasized accessibility through simplification, PF2e went the opposite direction—offering crunchier mechanics, deeper character customization, and more robust options.

Characters also start at a more competent baseline compared to early-level D&D characters, thanks to meaningful ancestry and class contributions (notably in hit points). Over time, Paizo has expanded world-building and player options in a way that stays thematic while broadening possibilities. PF2e appeals to players dissatisfied with the simplicity and narrower choices of 5e, positioning itself as a high-mid to high-crunch system—still not the crunchiest out there, but certainly not beginner-friendly.

Beyond mechanics, Paizo made waves in 2023 by introducing the ORC (Open RPG Creative) license, a non-revocable alternative to WotC’s OGL after the latter attempted to revoke its open license. Paizo, alongside other publishers, effectively nullified WotC’s move, winning immense goodwill from the community. The backlash drove unprecedented PF2e sales (reportedly eight months’ worth of books in just two weeks) and strengthened Paizo’s position as the leading competitor to D&D in the market.

Mörk Borg (2020)

Mörk Borg is best known for its visual layout and design (it’s mostly something to see rather than read, though the writing is good) and spawning many similar style highly popular games and designs under its third party license. The key thread between most of these is that they have a very specific theme as well as usually an aggressive/dark tone amped up to 11 with frequent character death often being a main feature. The mechanics are familiar concepts but it deviates most notably on having only player facing rolls for outcomes.

BRP (2023)
Initially launched in 1980 I’d suggest most just stick to the 2023 or whatever is the most recent version at the time of reading.  As mentioned prior it’s rooted in a d100 system (chaosium’s specifically) which also allows you to map odds to just about anything as mentioned in step 4. Even if you are wanting to make your own fully custom system, I’d offer a strong suggestion to review this as one of your first stops in researching systems for the simple fact that it can provide a large number of varied solutions to typical RPG problems which you can then adjust/customize/use/abuse for your own needs. It also uses the ORC license for those who wish to create directly under that system.

Shadowdark (2024)

Shadowdark is generally best loved for its OSR style (though disputes of if it is “truly OSR” exist); blending elements of classic play styles with more modern design principles.  It very much acts like a “What if old school DnD but better?” and is often held in high regard by most OSR fans. The classic design also not only is about the mechanics and gameplay, but also extends into creating a physical product that is an art piece built to last and even featuring old school black and white illustrations.

Further Reading: While we’ve covered a significant portion of the most widely represented games with specific design values to give, once you are sufficiently familiar with their mechanical strengths and weaknesses as a basic primer, be sure to investigate niche indie publications.  Frequently cult classic games with minimal production values will often be home to some of the weirdest, most interesting/inspiring, and experimental mechanics that you might be able to polish just right to suit your game’s specific needs.

Think Like a Designer

According to wikipedia: “Design thinking refers to the set of cognitive, strategic and practical procedures used by designers in the process of designing, and to the body of knowledge that has been developed about how people reason when engaging with design problems. Design thinking is also associated with prescriptions for the innovation of products and services within business and social contexts.”

While there are multiple schools of thought on design thinking, the basic loop is usually broken into five steps: Empathize, Define, Ideate, Prototype, Test.

In TTRPG design, these steps can be translated into a practical loop:

• Empathize: Identify problems for the user and what they really want. Be careful—players often think they know what they want, but they usually describe symptoms, not root causes. Example: “Combat takes too long.” The issue may not be speed. Your job is to discover the true problem.
• Define: Clarify those problems and desires by asking Why? repeatedly. Why is combat too slow? Why is it frustrating? This step narrows the scope of what you are actually solving. If players report they can absolutely be immersed in hours long combats, maybe the problem isn’t speed, but engagement. Perhaps players grow bored sitting extensively waiting for a turn.
• Ideate: Generate solutions. Once the real issue is identified, brainstorm approaches. How can I increase engagement?  What if I make it so that players have ways to interact when it is not their turn to keep them better engaged, or eliminate/alter strict initiative rules?
• Prototype: Create a functional version of your solution. Write it down and make it testable.
• Test: Playtest and gather feedback. Learn from results and re-enter the loop with refinements.

Troubleshooting Methods

Several basic practices can help refine your designs:

• Identify the correct problem. The first guess is often wrong. Look at player behavior, not just player words.
• Find your levers. Once you know the problem, identify which variables or systems you can adjust.
• Iterate multiple solutions. Rarely is the first fix the best. The strongest solutions often resolve multiple issues at once.
• Anchor in identity. Always check ideas against your game’s intended identity. If your identity changes, re-audit older content for consistency.
• Prioritize. Work on big systems first (core resolution, action economy, etc.), then refine smaller subsystems later to avoid wasted effort.
• Experiment. Add or remove something unexpected to see how it changes player behavior. Keep a “failure file log” so no discarded work is truly lost as it may help solve future issues.
• Set clear behavior lanes. Either incentivize a player behavior or discourage it, don’t try to do both. Mixed signals create exploits and confusion.
• Test extremes first. Large changes often reveal a problem’s direction more quickly. If wrong, revert and try another big change.
• Flip the mechanic. Try inverting a rule or relocating its function elsewhere in the design (try reimagining a status nerf as a buff, etc.)
• Buff over nerf (with caveats). If your game promises power fantasy, it’s usually better to raise weaker options than to cut strong ones. For disempowerment-focused genres like survival horror, the opposite may be true.
• Prioritize fun over balance. If a mechanic is balanced but boring, it has failed. Make sure mechanics feel good within the fiction your game promises.
• Fail faster to learn faster. Don’t polish too much before testing; most early builds break anyway. Crash them as hard as you can intentionally, then autopsy and learn.

Additional Notes:

• Game Theory: TTRPGs are usually cooperative, asymmetric, non-zero sum, sequential, and imperfect information games, often containing elements from every category. Modeling them mathematically is futile, but understanding basic theory can help you predict how rules affect player behavior.
• Rapid Prototyping: Never aim for perfection before testing. Build rough, test aggressively, fail quickly, and learn faster.
• Further Reading: The Praxic Compendium is one of the best resources for studying a wide spread of design conventions. It isn’t exhaustive (nothing can be), but being aware of its catalog will expand your design toolkit.

Step 8: Play Testing

Playtesting is not technically mandatory to create a TTRPG, but any good designer should treat it as if it is. Playtesting validates your design, reveals blind spots, and keeps you from releasing flavorless design-by-committee sludge. Always be testing (ABT). Fail faster to learn faster.

Key Testing Phases:

Pre-Alpha (Solo Testing)

• Test the system yourself first.
• Run scenarios in your mind, on paper, or with full character sheets.
• Think of it like playing chess against yourself.
• Purpose: catch obvious flaws before wasting others’ time.
  

Alpha (Trusted Circle)

• Run sessions with supportive friends, design teammates, or other designers.
• Focus on core systems: character creation, combat, economy, equipment balance.
• Purpose: polish mechanics with informed testers.
  

Pre-Beta (Alpha Readers)

• Bring in outside readers.
• Recruit both system designers (for mechanics) and typical TTRPG players (for usability).
• Look for clarity, contradictions, and confusing rules.
• Handle edge cases: clarify or push to supplemental material if not core.

Beta (Wider Audience)

• Test with strangers: conventions, FLGS demos, online groups.
• Focus on:
  

• Discovering edge cases, exploits, OP builds.
• Onboarding experiences for different player types.
• Accessibility in naming conventions, rules writing, and data organization.
  

Pre-Launch (Blind/Wide Testing)

• Recruit streamers, content creators, or blind test groups.
• Provide premade adventures to showcase systems.
• Use this both as final stress testing and community-building promotion.
• If streamers record, you can watch the recording to identify areas of confusion or misinterpretations of rules.

Playtest Wisdom:

• Always test early and often. Even if you are sure something works, test it anyway.
• Designers should be present. Outsourcing testing removes you from critical lessons.
• One playtest is not enough. Outliers happen; test widely to identify consistent pain points.
• If no assumptions were challenged, you weren’t paying close enough attention.
• Vet testers. Don’t recruit crunchy-sim diehards for a rules-light narrative game (and vice versa).

Sample Questions to Ask After Each Test (use these and/or develop more for specific testing needs)

• Was the game fun? Which parts? What wasn’t fun? Why?
• Did the game deliver the intended experience?
• What rules were unclear?
• What systems felt broken, unbalanced, or unsatisfying?
• What wasn’t effectively communicated by text?
• What needs rebalancing?
• Explain when and why you felt the following emotions (in or out of character) during the playtest (N/A is a valid answer, multiple answers is also great):

• Immersion
• Inspiration
• Satisfaction
• Excitement
• Humor
• Boredom
• Frustration
• Confusion
• Helplessness
• Alienation

Note 1: Differing games may interpret these emotions differently, the only one that is strictly negative is boredom, as in some cases the game may not be meant for lots of humor injection in character, and confusion/helplessness/alienation might be key desired themes in more survivalist/horror style games.

Note 2: Some level of confusion is likely always going to occur for players new to the hobby, or players new to a distinctly unique setting that they don’t fully understand yet, which may also apply to some more involved mechanical complexities when they are new to a player as well (large and frequent amounts of negative feedback here may indicate a desire for more streamlining in a specific area, but a single or mild implication of confusion with mechanical complexity is likely to be common).

Collecting and Interpreting Feedback

A) Don’t be defensive. Thank players, listen, and take notes. The critique is about the game, not you.
B) Distinguish bugs from features. Sometimes a disliked element is core to your game’s identity. Other times it’s an actual oversight. Learn to tell the difference.
C) Focus on problems, not solutions. Players’ suggested fixes are often bad design, even if well-meaning. Extract the underlying issue instead.
D) Look for honesty in behavior, not just words. Some testers avoid confrontation. Watch body language, tone, and attention levels.

Blind Testing

• Have groups run the game without your presence or interference.
• Best insights come from watching them struggle or succeed, not from what they say afterward.
• Look for confusion, frustration, disengagement, or boredom.
• Pay special attention to first-time GMs running the material.

Personal Example: I noticed during a play test for Project Chimera: E.C.O. that a particular meta-currency move left players feeling unsatisfied. Within the scope of the rules, it was balanced, but it didn’t feel good for the amount of investment required to use it. As such I had a few options. My solution was to buff the move to be slightly more powerful rather than reduce its costs because I still wanted it to be rare in its use. The result of the buff left players feeling much happier with the move in the next test and the buff was actually rather small, but was important in the context of the game to fulfill the fantasy presented.

Specifically this was the three hero point (meta currency) move: Rule of Cool, that basically gives players a spotlight moment to succeed and have some greater influence on the overall narrative.  The duration and cost were right, but the dice rolls felt unimpressive sometimes, specifically with one part of the mechanic regarding the adding a +2 on a d20.  Instead I changed this to +1 instance of advantage (statistically only a +2.5 to dice rolls, a barely noticeable difference) but the felt fairness of the outcome vs. investment was far more tangible as a single roll going bad didn’t waste their turn, instead two dice would need to come up poorly to have a bad result.  Players felt the change and it wasn’t disappointing when a bad roll came up with two dice, because at that point if “felt” like perhaps the player was just fated not to succeed there.  Conversely, the odds of having a middling roll or great roll instead of a bad roll doubled in outcome results.  All because of a small change to a buff.

Standard Test Module

Near the end of alpha, combine your current playtests to prepare a sample adventure designed to:

1. Stress-test every major subsystem.
2. Showcase your game’s unique selling points.
3. Reveal different exploits in the adventure depending on how groups approach challenges.
4. Familiarize you with material so you can run smoother tests.
5. Serve as your first published module (polished by repeated playtesting).

General Priorities for Playtesting

• Simplicity: Remove unnecessary complexity and grind. Complexity must serve purpose.
• Fun: Identify which moments create joy and maximize them.
• Stimulation: Ensure replayability and intellectual engagement. TTRPGs should allow near-infinite variety.
• Motivation: Clarify why players choose your game over competitors. What’s your hook?
• Engagement: Track when players are most absorbed vs. when their attention drifts. Reduce downtime, maximize table engagement.

Do Not Attempt to Design the Perfect Game

As noted back in Step 0, perfect is the enemy of good. Another lesson, borrowed from the AAA video game industry, is that the bigger the net you cast for your audience, the more bland, shallow, and forgettable the experience becomes (Ubisoft games, particularly franchises like Assassin’s Creed and FarCry tend to have the most extreme criticisms of increasingly watered down designs with year after year entries).

Do not try to please every playtester and every player. That way lies design-by-committee, and design-by-committee is how you build a monument to mediocrity. Not only is it impossible to please everyone (player desires often directly conflict), it also strips away the spark that makes your game special.

Your job as a designer is to lean into your game’s inspired bits—the unique identity and design values you set early on—and polish those until they shine. Look back at the examples from Step 7: every standout game did something unique, different, and important, and did it well. They didn’t succeed by being all things to all people.

You can always compromise later if you’re old, gray, and ready to sell the rights to your system for a cash grab payout to sip Mai Thais on a tropical beach. But while your name is on the cover, especially when starting out, integrity matters. Your game should be something you’re proud to point at and say, “that is mine, it’s fun, and I think you’ll like it” with confidence.

Step 9: Editing, Layout, Art Direction, Character Sheets and UX

By now you’ve tested your game to death and are ready to move from demo into a release-ready product. As the old saying goes: the last 10% of production is 90% of the work. Some stuff for professional grade will cost you money. Do as much as you can for free, but don’t skimp on the important bits.

Editing

If you want your product to be taken seriously, hire a professional editor. Even if you’re an editor yourself, you know fresh eyes are invaluable. Don’t skimp here.

Some Budget hacks useful for free/PWYW games: read your full text out loud and/or run it through text-to-speech and listen to it, or use free editing suites on sites or software before sending it off to print/upload.

Data Organization

As a rule, Introduce concepts in order of relevance to the reader, then expand on them later. A simple core structure to follow in your book is: Opening Value Proposition → Brief Setting Overview → Brief Mechanical Overview → Character Creation → Rules Minutia → GM Advice →  Lore Dump. Study successful games with polished design to see how they order information.

Logos and Branding

Logos should be simple, often single-color, and thematically communicate your game’s identity. You will need this as a Vector file (not PNG or JPG) for other marketing purposes if you intend to sell anything. This service may require a graphic designer.

Example:
Source: Ted Hayes Sentients

The “Sentients” logo instantly signals sci-fi, humanoid robots/AI, and a sleek Apple-like design ethos—all without needing context. I’m still jealous of how good Ted’s logo is at communicating so much with so little.

Remember: branding matters. The cover art and logo get people to play your game once. The system gets them to play it again. But they won’t play twice if the first impression never happens.

Layout and Art Direction

Layout must balance function and form. Use it to immerse readers in your universe, transparent textures, thematic visuals, and consistent page design help reinforce tone. Avoid blank white documents unless it somehow serves your game’s identity. Many System Designers choose to learn layout design and art direction themselves, which is great, but it’s a wholly separate skillset that has a significant learning curve. If you intend to sell your game as a professional product, consider investing in a professional.

• Tools: InDesign is industry standard; Affinity is a solid budget alternative with frequent deep cut sales approximately 2x yearly. If budget is a concern, write in a document program of choice and wait for affinity to go on sale.
• Art Direction: Choose a clear style that reinforces your tone and core experience values. Mixed styles often confuse readers. Public domain art use (with proper attribution and awareness of publishing limitations) can significantly slash your budget. Stock art licensing can also be a budget conscious alternative. Actual hand crafted commissions will be a nightmare to pay for without crowdfunding for any newer creator.

Character Sheets

Your character sheet is the most-viewed part of your game and as such is the #1 piece of branding material. Treat it as a core art piece, not an afterthought. Similar to layout, if you don’t have the skills here, considering hiring out.

• Always include your logo at the top. This sounds obvious but you’d be amazed how many people miss this in their drafts.
• Carry over layout and texture cues from your book design for cohesion.
• Provide both printable (B&W or muted color) and fillable PDF versions.

A good sheet should:

1. Organize information clearly.

1. Use zoning (shapes, shaded boxes, grouped sections) to highlight frequently referenced areas and downplay less critical ones.

2. Be accessible at a glance.
3. Reflect your game’s aesthetics.

Teach the game through layout.

Sheet source: Autodesk Indestructables

Regarding UX, this is vastly important to any larger modern design. A lot of information can be communicated with thematic symbols, shapes, and colors (ie icons) that can drastically cut down your word and page count.

As an example, what does this mean?

It could mean a lot of things and you can specify what it means in a symbol key, but it probably means something like roll 1d20 or that dice are to be rolled as part of a mechanic, or what happens if a natural 20 is rolled.

This is probably a health or medical icon.

This is probably used in a sidebar or break out box to indicate important information/concepts or rule spirit clarity.

This probably means that something leads to something else, such as if it is a prerequisite for another feat in a feat tree.

If I use THIS COLOR any time I am talking about/referencing a primary ability score like INT 16, that will indicate as much to the reader, likely without them needing to be told. Beware of over-reliance on color alone however as this can possibly present accessibility issues for the colorblind. As such color is best used as an indicator when in combination with other visual indicators (such as distinct shapes or icons).

The exact icons you use and how they are stylized will depend on your game, but it is something to consider, particularly for games with any degree of complexity or ideas that are referred to repeatedly, particularly for larger systems.

Additionally don’t overlook basic navigation features either, such as side margin navigation, particularly for larger print books.  If you’re looking at this guide on a PC, depending on your browser, you will notice this article has sidebar navigation as well. Indexes and similar are also essential navigation tools.

Sidebar navigation, Source: Pathfinder 2e Advanced Player's Guide

Additional Layout Notes:
1. Usability first, function over form.  If it’s not easy to read and use, you failed in your primary layout duties. This means easy to read fonts, excellent data org, and appropriate UX.

2. Craft a thoughtful experience.  Presentation is everything. It’s not just about looking good, it’s about reinforcing the primary promise and aesthetic of your game.  The same sentence said or presented two different ways can have drastically different meanings/interpretations (see graphic, left), the same is true with layout.  Further this extends to additional aesthetics like choice of paper weight/stock, bindings, covers, format (zines vs. books), etc.

3. Layout and graphic design rules as listed by various tutorials are there much in the same ways as musical theory rules.  They are a foundation to build knowledge upon, but are largely suggestions and it’s OK to break those rules with style, provided you understand and know what they are and why they exist to begin with.  See Mork Borg and similar X-Borg games for games that radically break many layout design rules and still manage to have excellent layouts. See Shadowdark for excellent examples of best practices layout.

4. Print on demand is a great economic option for things like drive thru if you can’t afford printing.  It is not a great option for high quality printing of a collector’s tome. If you are going to print books with a professional, seek to budget for offset printing rather than limited small runs to get far better deals.

Step 10: Marketing, Advertising and Beyond

Marketing doesn’t begin after your game is finished, it should start the moment you commit to making a system (I told you to start on this at the beginning of the guide, I hope you listened). Build awareness early: put up a splash page, collect emails from interested players, start a Discord server, and present yourself as a TTRPG designer. Even small steps like getting playtesters streaming your game or reaching out to content creators can pay dividends.

Early-Stage Marketing (Free/Low Cost)

• Put up a simple landing page or blog.
• Collect emails of interested players/testers.
• Start a Discord/Forum/Youtube Channel or other small online community.
• Engage with TTRPG forums, Twitter, Reddit, or Facebook, not by spamming ads, but by joining discussions, showing off ideas, and asking for feedback and very crucially: Follow up on those discussions. Genuinely engage. People can smell through the internet the stink of poorly executed, thinly veiled attempts at free advertising and shilling. They don’t like it and will resent you for it. Don’t do it.

Paid Ads and Timing

If you buy ads, be careful during election cycles, costs spike due to competition with major political campaigns. Political ad saturation can make your ads more refreshing to see (positive), but you’ll reach fewer people at a higher cost (negative).

Publishing Options

When your game nears print-ready:

• Traditional route: Pitch to publishers (they’ll take a cut, which varies with support offered). For a bit about pitching to indie online TTRPG retailers, see this article.
• Indie route: Run a crowdfunding campaign (Kickstarter, BackerKit, etc.). But remember: this isn’t “free investor money.” You must deliver, or you risk reputational and financial damage.
• Digital-first: Publish on platforms like itch.io or DriveThruRPG. Consider using “pay what you want” to build a player base before focusing on print books (treat this as a luxury item, because that’s more or less the general state of the market, if you don’t have accumulated demand, don’t set your sights on print).

Creator Licenses and SRDs

If you have serious ambitions, consider releasing and hosting an SRD wiki and getting legal to draft a creator license. Letting people play your system for free expands reach. You can monetize premium editions, adventure modules, play aids and expansions. Broad adoption is more important than squeezing every dollar from the core rules if you want to gain more traction. Creator Licenses are a way to allow other gamers to craft under your brand. I’d recommend modelling after the most currently successful versions.  I’d recommend Draw Steel’s License as a good base model for most use cases, but consult with your lawyer. I am not your lawyer or a lawyer, I do not offer legal advice.

Paid Advertising

Marketing is its own industry. If you want to scale seriously and lack expertise, hire professionals or work with a publisher who employs them. Focus on being a designer, not a full-time advertiser. As with editing or legal contracts, this is not an area to “wing it.”

Protecting Your IP

If your project is commercial:

• Share only small excerpts on official channels.
• Use NDAs when sending drafts externally.
• If you’re working with a studio, follow its policies (usually strict). If they don’t have any, be cautious. Default answer: “This project is under NDA and I can’t talk about it.”

Virtual Tabletops (VTTs)

Do you need VTT support? Maybe.

• Rules-light games (theater of the mind): Discord + shared maps, handouts, or music are usually more than enough for most players who prefer this style.
• Crunchy, map-based games: The more your system tracks (grids, conditions, resources), the more players will expect VTT support.

But VTT module development is expensive and usually out of reach for first-time indies. Some publishers (like SWADE) employ full-time VTT developers. Costs may drop as AI-assisted coding improves, or HEDRON continues to mature, but it isn’t cheap yet.

Currently, only the largest systems are expected to have full VTT integration. Still, having fillable online character sheets is becoming a baseline expectation. Even without a VTT module, don’t skip this.

Hiring Other Writers/Artists

The TTRPG industry is small. Reputations—good or bad—travel fast. If you hire others, treat them with respect and professionalism. I’ve been on both sides of the table, and here’s what matters:

As an Employer

• Have a contract ready. Professional contracts (with NDAs when appropriate) are standard. Negotiate fairly.
• Understand pay scales.

• Writers: Bargain-basement rates (1¢ per word) won’t attract talent. Expect to find solid work at 15¢+, and professional-level work at 50¢+ or per diem. Don’t ask pros for tiny 500-word jobs; they’ll have to charge more than it’s worth.
• Artists: Rates vary wildly, but art is expensive. Quality is not cheap.
  

• Respect humanity. Emergencies happen. Good relationships matter more than one missed deadline. Professionals usually deliver on time, but build in space for the occasional hiccup. Don’t demand attention during their off hours unless you pay them a comfortable living wage salary.
• Could this be an email? Ask yourself if your communication can be an email they respond to when they get around to it, short of vital potential emergencies, usually this is the case (game development is rarely life and death stakes).  Even if something requires a meeting, you can send an email request to schedule a meeting. This applies typically unless they state they prefer some other communication type.
• Pay on time. Typically 50% upfront, 50% on delivery (unless a pro requires full prepay), for massive scale work this might be divided differently as well (payments and delivery schedules over time). Always credit their work appropriately.
• Be prepared. Have expectations, outlines, and reference images ready. The clearer you are, the less wasted time and money.
• Remember the “Fast, Cheap, Good” rule. You only get two. If someone delivers all three, pay them more before someone else does and you lose them due to their increasing demand.
• Respect the edit limits and employee time: Any professional will have an edit limit on how many times you can send back a draft before the object costs more. Maximize your edits allowance per work by addressing everything that needs fixing at once, do not piecemeal it.
• Special tools. If your workflow requires specific software, expect to cover licenses for seats and/or training.

What to Look For

• Writing samples. Three short samples (about a page each) usually show range and fit. For niche projects, you can request a half-page challenge test, but don’t demand unpaid full drafts.
• Art portfolios. Ask for online portfolios (ArtStation, DeviantArt, etc.). When you see pieces you like, ask how long they took to produce, time investment varies.
• Production history. Nice to have, but not critical if you’re hiring cheaper. Samples matter more than résumés.
• Personality and communication. Culture fit matters. Interview over voice, or even better, video. Enthusiasm and clear communication make collaborations smoother and reputations stronger.
• AI use. Ask openly about AI in their workflow. AI can be a tool, but copy-paste use may raise copyright/ownership issues. Establish expectations clearly by having a clear AI policy.
• Scheduling. Ask how much time they can realistically devote per week so deadlines are achievable.

How Long is a Game?

Short answer: As long as it needs to be, but no longer.

Marketing answer (by page count):

Note: These numbers aren’t hard academic categorical definitions, they’re interpretations of how the market actually behaves, with fuzzy overlaps between tiers.

• 1 page → One-pager (includes trifold pamphlets and double-sided sheets). Designed for ultra-compact play, usually one-shots or quick “pick-up” games.
  
• 2–60 pages → Micro RPG. These games focus on a single idea or simple play experience. They often serve as one-session experiments or palate cleansers.
  
• 61–200 pages → Rules Light. Enough to feel like a “full” TTRPG, but intentionally streamlined. Skips granular detail unless it’s essential to support the fiction. (For reference: even at 200 pages, these are smaller than the ~350-page average for most base books.)
  
• 201–550 pages → Average Size. The industry standard. D&D 5e lives here, and Pathfinder sits near the upper boundary.
  
• 551–1200 pages → Rules Dense. The “big boys.” These games go far beyond what most players call “crunchy.” Casual players often think Pathfinder is the height of complexity, but compared to true rules-dense systems, it’s relatively modest. Most standalone core books rarely exceed 800 pages, when you see 900+, it’s usually a stitched-together collection.

The Psychology of Page Count

Players are perfectly willing to consume four 400-page books (1,600 pages total, see DnD modern editions) but balk at a single 1,000-page tome—even though the single book is shorter overall. This is a psychological barrier, not a logical one, but it matters for sales and reception.

The reason is partly cognitive load:

• A 400-page core book feels digestible for most experienced players because they know much of it is likely art and stuff that isn’t critical to play the game functionally and can instead be referenced as needed.
• Once players gain experience with the system, they’ll feel more comfortable adding another 400-page supplement if they enjoy it.
• By contrast, being asked to learn and implement all 800–1,000 pages up front feels overwhelming.
• Spreading out release dates (usually quarterly for larger products) not only helps with learning curve management but also provides time for wallet recovery if that is a factor.

Takeaway: Break your large system designs into manageable volumes. You’ll help players learn more naturally and avoid triggering the “too big/expensive to start” reaction.

Selecting your Storefront

There are presently 2 major online distributors of indie creators in the English speaking internet unless you are big enough as a creator to have your own proprietary storefront.
The first and best known is Drive Thru RPG.  They are known for getting the most business and traffic but they will take a steep cut and will push for exclusivity of your title.  I believe the current numbers are 30% non exclusive, 20% exclusive, but don’t quote me.

The next is Itch.io which is far more reasonable in their cut (15%) but will move less product for you, though on Black Friday they also don’t take a cut from creators beyond base transaction fee.

I’ll also make an honorable mention for Hedron as a growing store front as well with excellent support and low cut rates.

You can also set up your own webstore on your site (do not expect this to pay for itself without sufficient market penetration) and offer hard and digital copies on Amazon and other bookstores.

Doing your first Convention

Conventions are equal parts advertising, networking, community-building, and exhausting. Sales are nice, but the main goal is exposure early on. Treat it as a long party where you meet people, make connections, and share what you’ve made.

Table Setup

• Location matters. Prime foot traffic or spots near main events cost more, but more people will pass your table multiple times, giving you more chances to catch their interest.
• Print + digital previews. Have a single demo copy people can flip through, and showcase digital previews on a tablet (but never hand the tablet over).
• Have more than one product. Even a small variety lets you sell bundles or appeal to different interests.
• Presentation. At minimum: a tablecloth, placard stand with your logo, and banner. Bigger displays can come later. Check if the venue provides tables and chairs.
• Logistics. Bring a dolly for boxes, snacks and water for yourself and your helper (plan for meals if not provided on site).
  

Branding and Community

• QR codes. Print one linking to your website, SRD, and socials. Even if they don’t buy, they can join your community.
• Attire. Wear something that gives people a reason to connect, band shirts, pride gear, a joke tee. Save your branded gear until your game is recognizable.
• Table identity. Keep things neat, eye-catching, and consistent with your brand aesthetic.

Staffing

• Have a helper. Someone knowledgeable and enthusiastic doubles your reach. Hiring a cosplayer dressed in-genre can be a great investment: they’re a walking ad, they can pull people in, and they can cover for you on breaks.
• Be human. Don’t just talk about your game like a walking adbot, compliment someone’s costume, ask about a patch, or share common interests. Connection comes first.
  

Sales and Interaction

• Elevator pitches. Prepare 10-second, 30-second, and 2-minute versions. Match the length to the person’s perceived interest and attention span.
• Carnival bark. When traffic slows, call out something light like, “Who likes horror RPGs?” (if that’s your style of game). Not everyone will stop, but it keeps energy up and someone will stop.
• Touch points. Avoid handshakes and hugs unless initiated, be mindful of consent and health risks. Keep sanitizer handy.
• Disruptions. Every con has at least one disruptive person and sooner or later it’s your table’s turn to be a problem at. If they monopolize your time, redirect politely. If they don’t take the hint and continue to be disruptive, calmly escalate the issue to security.

Networking

• Vendors are allies. Befriend your neighbors before opening hours. Refer customers to their tables and they’ll often return the favor.
• After-hours connections. Dinner, drinks, or casual hangs with other vendors and presenters can turn into valuable future collaborations.

Pacing Yourself

• Sleep matters. Day 2 often outperforms Day 1. Attendees buy what they came for first, then spend extra money on impulse buys the next day, so be rested.

Expectations of duties for solo publishing and professional production

So you’ve decided to make your game a professional product for release.  That’s great, but it’s very different from making your own home game or an indie free/PWYW game. If what follows looks like a lot of work, that’s because it is and why so few achieve this level of production.

This is “mostly” cribbed from this video by Taron Pounds (Vagabond TTRPG/Indestroboy) and I’ve included it here in simple text because it’s an hour long video, however, if you want more relevant details/context, view the video in full.  I’m certain I will expand on this section extensively once my game is published, but for now, Taron Pounds has some really good comprehensive data about what you’ll be doing to make a legit product as a solo dev.

Disclaimer: I am not a lawyer or financial advisor, this is not advice in any official capacity, but strong suggestions on things to look into.

Roles:
Executive/Financial:

• Establishing Legal Structure such as LLC/DBA (or equivalent in your country, consider possible other structures)
• Have a Lawyer prepare contracts for all contracted work
• Include sole proprietary ownership of all contracted works or negotiate usage clearly otherwise
• Everything paid for to produce the product is likely able to be written off in taxes
• Familiarize yourself with VAT, shipping & packaging (two separate concerns), print fees (note print on demand vs. offset).
• Establishes clear goals for the product for delegation and management by the product manager.

-Lead Game Designer:

• You design your game or contract and pay others to do so.
• Do not copy/paste text from anywhere, including AI chatbots.
• Game Mechanics cannot be protected legally but their specific expressions can. There are noted exceptions to this (Crazy Taxi’s direction arrow and the Nemesis System from Shadows of Mordor are noted historical examples, in the TTRPG space this is not as much a concern as with video games but there is concerns about specific IP being legally distinct, such as the Mind Flayer/Beholder/Mimic of D&D requiring other representation as legally distinct), but it’s more or less not legal but made legal through large cash infusions to lawyers. Note that copyright and other protections may vary in your country of origin.  Learn about this explicitly.

Project Manager:

• Product strategy: Translate/Define the product's vision, goals, and strategy as interpreted from the executive to functional terms relevant to each station (this role mostly exists for teams rather than fully solo devs since you don’t need to coordinate yourself with yourself).
• Cross-functional coordination: Manage and supervise cross-functional teams and ensure effective communications.
• Manage production pipelines: to avoid logjams whenever possible, and when not possible, communicate and redirect assets/resources/talent as needed to ensure productivity and deadlines.
• Product planning: Create a roadmap of the steps needed to achieve the product's goals
• Market research: Understand customer needs and market trends by conducting surveys, interviews, and analyzing competitor products
• Data analysis: Use data science and analysis to guide product development
• Customer service: Understand customer needs and preferences
• Competitive analysis: Monitor the market and develop competitive analyses
• Stakeholder alignment: Align stakeholders around the product's vision (relevant if you have investors or crowdfunding backers)
• Feature prioritization: Prioritize product features and capabilities
• Feature release management: Manage the release of new product features

-Narrative Lead:

• Worldbuilding
• Diegetics/Narrative Writing
• Ludonarrative Oversight (mechanics reinforce the designated intended game experience)
  

-Art Director:

• Establish and enforce an aesthetic identity for your game.
• Illustrate everything yourself or commission art, or use public domain art with proper crediting of source.
• Research/vet and Hire select creative talent for illustration.
• Negotiate fees and ensure contracts are managed effectively with hired talent.
• Deadlines are not the same as crunch. Account for reasonable expectation and projection of emergency scenarios and how to account for that in the contracts.
• Include sole proprietary ownership of all contracted works or negotiate usage clearly otherwise.

-Graphic Design and Layout:

• Design Typography and visual layout style
• Prepare Print PDFs
• Prepare PDF Interactables (fillable character sheets, JAVA, Bookmarks)
• Package INDD files for print
• Stipulate revision fees in the contract.

-Marketing

• Close Coordination with executive/logistics/financial
• CAQ (Cost of Acquisition) Management, ensures spending of marketing dollars translates to proportional/exceeding conversion/adoption rates (you make more money than you spend on marketing).
• Standard Expectation is at or above 3x ROI/ROAS (return on investment/return on ad spend).
• Note that ROI is calculated after recuperation of ad cost.  As such for 5 dollars, we must make 20 back, 5 to cover the ad, and 15 in return on investment.
• While lower than 3x ROI as long as it is net positive is “technically making money” it’s not functional as a long term marketing/investment strategy.  Marketing experts generally agree that making less than 3x ROI indicates something must change drastically about the marketing campaign to better entice prospects.
• Usually manages Kickstarter/crowdfunding campaigns.  KS in 2025 being named as the generally preferred popular route.

-VTT Developer

• Semi-optional, though highly likely to become less optional with time.
• Does system integration of base system and sheets converted to code into contracted VTTs.
• May or may not include automation, animation and other products, negotiated as desired.
• Fantasy Grounds, Roll 20, and Foundry all require different coding and thus different contracted development.
• May do integration of approved modules by other creators (depending on licensing and agreements).  Even if you don’t directly benefit financially from 3PP integration, you generally want to have high quality modules integrated, and the freedom for your coder to take those jobs as this expands your product and keeps your coder making money beyond simple rules adjustments/refinement and otherwise active on the project after the bulk of their work is done.

-Logistics Manager:

• Managing all stages of fulfillment (KS, Printing, Packaging, Shipping, Safe Storage of product, Product Insurance, other types of fulfillment such as sculpting of custom dice or other merchandise manufacturing).
• Establishing, Enforcing and Negotiating 3rd party contracts regarding manufacturing, may be tied into Executive duties/coordination due to large costs.

-Sensitivity Consulting:

• This is not a role you perform, but fill regarding your cultural blind spots.
• You have an implicit duty and responsibility to the public to not massively stereotype/misrepresent cultures and avoid patently objectionable materials for your target audience. This isn’t censorship, you can still publish all the awful things you might want, it’s being a thoughtful person aware of your cultural blindspots.  Failure to do so is how you get boycotts, cancelled, branded as a bigot, etc.
• There is no magic stamp of approval that makes something non-offensive.  People can and will be offended by anything or nothing rational. Your duty is to ensure you aren’t creating and releasing materials that cause harm.
• Workers should be well immersed in the culture and grounded in reality, and are not there as mechanics developers, but rather there to advise on issues of cultural sensitivity. This can bleed into advice around mechanics that might be patently offensive as a representation, but this should rarely be the concern.  Most of their duties will be analyzing narrative text and art depictions.
  

-Community Manager:

• Close coordination with Marketing
• Moderation of communication hubs (mono and dialog, ie, press release vs. forums and social media)
• Drafting and execution of public statements
• Engagement and relationship building with supporting content creators
• May include technical skills/positions for higher budget productions (such as lets-plays with paid actors that have makeup and wardrobe done, lighting, camera, digital techs, etc.)
  

Pricing your product as a small company

1. Account for total COGS (cost of goods sold). This is your total manufacturing, shipping, etc.  Whatever it costs to put a product in the hands of a consumer.  There are different ways to account for this, but in the end it doesn’t matter how you classify your expenses for various tax purposes as long as you determine your COGS per unit (which varies per product). Notably this does not include standard overhead, but does include specific commissioned costs.
2. Determine your MSRP (manufacturer’s suggested retail price).  In most cases this will be between 5x to 10x your COGS, and it varies a bit by MSRP and how slim your margins are.  On average 7x will be a healthy growth rate, while it’s more ethical and sustainable to lower your multiplier for larger scale and pricier products, while very cheap products might be on the higher side to make it worth producing at all, depending on audience size.  Keep in mind you do not make the MSRP unless you sell it directly (ie from your personal website or at a convention).
3. The MSRP is then generally reduced by 50% discount to a mom and pop business (FLGS) and usually 60% to a major retailer like Amazon or WalMart (the additional loss is generally made up by order volume and total sales and accessibility for buyers, so they get better negotiated rates as a standard. Digital only sales will generally be much cheaper but take a 20-30% cut (ie PDF only sales might be $15, have a $0 COGS, but payout $10 USD).
4. This means if you have a book you produce for $7 COGS (because you printed a bulk run of 10K) and use a 7x MSRP multiplier your MSRP will generally be $49 USD (or more realistically rounded to $49.99/50 bucks).  Now to put that in the hands of an FLGS you just sold them a unit for $25 USD, but you didn’t make 25 USD, first you need to deduct COGS, that brings you to $18.  Now consider your cost of doing business overhead (staff of writers/artists/legal/utilities/storage/other employees/advertising/etc.) and depending on your business model and how many units you move, and products you have, that may come out to $8-10 USD.  That leaves you roughly $8-10 USD to invest in other products and the future of the company and have some stashed away for a future crisis. Additionally consider that your major retailers with a 60% discount will leave you with $5 less per unit, making the margins $3-5 USD.  
5. Lets project what we make for 10k physical units sold at this ratio (this is not for digital sales):

• ~10% sales are direct (1k), ~35% sales are FLGS (3.5K), ~55% are retailers (5.5K). Individual breakdowns will vary by product and company, but this is a reasonable stand in estimate.
• Direct sales total gross: 42K, FLGS gross: 35K, Retail gross: 27.5K.  Total Gross: 104.5K USD.  Standard 21% corporate tax rate = ~22K, Total USD Net for 10K Physical units sold: 82.5K USD.
• Note that the above calculations are very generous and optimistic and you also paid yourself $0 USD to run the company. And this also means you sold the full run, but it doesn’t even account for how long that took to offload the full run (A quarter? A year?). Plus if we want to order another 10K run to have more product, at $7 COGS, or 70K, leaving us with 12.5k in the bank until we sell that run…
• Because people are bad at math and business and economics they see: 50 USD product x 10K units: “That’s 500K in profit you made! Just do that 2x and you have a million dollars!”  No, not even a little bit. This is why this is a business and labor of love, the margins are too small to generate significant profit and more realistically most gaming companies are bordering on bankruptcy at the slightest market disruption, and that’s presuming they can even get to the level of being a small business to begin with.

Side note: As of writing (2025) US tariffs which affect the global economy are shutting down many small indie TTRPG companies and major ones “may survive” but may not due to massive increase in manufacturing costs. This is likely to mean as a starter indie developer you might want to focus on PDF sales vs. physical products until the situation changes or dream up an alternate strategy if you know better.

Closing Thoughts

If you’ve made it through this guide and absorbed its contents, you now have a solid foundation for your journey as a designer. But remember: this is only the beginning. These are the basics—what I call the “general wisdom.”

General wisdom exists for good reason: it helps address common pitfalls and broad issues most designers face. But it also comes with a danger. It’s easy to get trapped in solving problems simply because you’ve been told they are problems, without understanding the deeper forces at play. This leads to what’s called medium maximization: focusing on the medium (money, mechanics, word count, or even “fun” as an abstract) rather than the outcome the medium is meant to support. When that happens, you risk optimizing for the wrong goal.

Design never exists in a vacuum. Context and intent matter more than any blanket rule. Something that failed in one game may succeed beautifully in another if the surrounding design values support it. Conventional wisdom should guide you, but it shouldn’t box you in.

The real key to thinking like a designer is to go deeper: ask why. Why did this rule, mechanic, or product decision succeed—or fail—in the past? What exact experience was it trying to create? What values was it serving? If you can understand the “why” behind a design choice, you’ll be far better equipped to challenge assumptions and make choices that truly serve your own game.

That’s the big takeaway: why a design decision was made is almost always more important than what the decision was.

Additional Resources

Free Software to consider:
GIMP, Midjourney, Scribus, Google Docs

It’s important to research any software solution to make sure it meets your needs.

For additional, more advanced information after completing this article I might recommend:

Design Patterns of Successful RPGs

There are also near infinite learning opportunities for various design concepts from youtube GDC talks. While the emphasis is usually on video games, a large majority of the lessons you might take from there are immediately transferable to TTRPG design. I would specifically highlight any discussions by Celia Hodent and 20 lessons from Mark Rosewater as high priority research.  Also on youtube I’d strongly recommend: RPG PHD, Tales from Elsewhere, and Design Delve series (produced by Second Wind starring JM8) for content that has strong design focuses.

Additionally, board game communities have had centuries longer to develop their design language and have a large advantage over modern TTRPGs regarding UX and learning from books, communities and blogs about board game design can vastly benefit your own designs.  As with video games, many of the lessons are directly transferable.

If you’d like a mountain of resources, check out this resource DB on itch.io

Lastly, the RPG Design Reddit Wiki also has a staggering amount of resources for your use and I’d strongly recommend that community. This is specifically where I learned about half of what was covered above.

For more information about my current development project, Project Chimera: E.C.O. (Enhanced Covert Operations) TTRPG please visit us on Facebook / Reddit or check out the Facebook Media Page for a general overview.

If you found this article useful/helpful and would like to support me personally you can buy me a coffee. I do not presently have a patreon or active youtube account but those are in the works when the time is right.