If you’ve played an indie TTRPG, whether it be one of mine or one of the thousands of other games out there, you may have been struck with the idea, “I could make one of these.”
And you know what? You’re right. You absolutely can make an indie TTRPG of your own.
The difficult part, of course, lies somewhere in the process of translating that idea into reality. It’s a chaotic process, and it’s different for everyone. I pulled together my personal design checklist some time ago to share on a private Discord server, and I found I was half describing what I consciously knew and half discovering the overview of what I had been doing as I wrote.
I must emphasize that this is not a comprehensive roadmap or an optimized step-by-step strategy. It’s simply my own process – and as a wise man once said, “My process is a mess and I don’t recommend anyone follow it.” Nevertheless, if you’re thinking about creating your first indie TTRPG or if you’re simply curious about what the process entails, I hope this checklist might give you some general waypoints.
- Determine the guiding flavor of the game.
- Determine the bones of the mechanics: e.g. choose an SRD, or a dice system.
- Research similar games to get ideas and to make sure you aren’t treading too close to existing work.
- Write out the rough rules for the main rules (aka the core gameplay loop).
- Write out the rough rules for any exceptions.
- Write out the rules for the frame: the setup, the end, and any turning points the game might have.
- Send the text of the game to an alpha reader for mechanical feedback. Make any necessary mechanical changes.
- Announce and promote the game.
- Refine the language of the rules for clarity, concision, and organization.
- Promote the game.
- Send the text of the game to playtesters for feedback on mechanics, general impressions, and text ambiguities. Make any necessary changes.
- Add flavor text.
- Promote the game.
- Send the text of the game to a copyeditor.
- Source art for layout and Itch assets.
- Make a cover.
- Promote the game, this time with 100% more cover art.
- Do PDF layout.
- Create an Itch page, upload files, set appropriate tags and confirm a release date/time.
- Promote the game.
- Keep promoting the game.
Some of these steps can be done in a different order. Making a cover might be one of the very first things you do, for example; I’ve had the cover for inHabitation completed for almost a year and haven’t written a single word of rules text yet. But some of these tasks really can’t or shouldn’t be moved out of order. Creating a polished PDF layout before you have your text fully edited means every subsequent text edit requires constant fiddling with text boxes, font sizes, or pagination to make sure that your text doesn’t overflow or underflow the space you had set aside for it.
That said, let’s delve a little deeper into each of these tasks.
Inspiration
- Determine the guiding flavor of the game.
- Determine the bones of the mechanics: e.g. choose an SRD, or a dice system.
Some people draw inspiration from a scenario or a kind of story that they want their game to portray, and then look for a system to support it. Some people draw inspiration from finding a new mechanical structure they love, and then think about what kinds of stories it would be well suited to tell. I typically spend 30-60% of my overall development time just in this stage, coming up with stray narrative and mechanical ideas and seeing how they fit with each other, then jotting down loosely-connected notes in a Google Doc.
Whether flavor or mechanics comes first is going to be personal to you, but once you’ve fallen in love with an idea from one side, I highly recommend ensuring you have an equally solid grasp on what you want to create on the other side before you move forward. Resist the temptation to keep building only on your inspirational idea. If you ignore the other side and just assume you can figure it out later, quite often you’ll find when “later” comes around that you’ve written yourself into a corner with what you’ve already established.
If you don’t feel up for creating and balancing all your mechanical systems from scratch, you can always use part or all of an SRD to guide your mechanical design. Be aware that the term SRD, or System Reference Document, connotes quite different things depending on your TTRPG background. If you come from a D&D or Pathfinder background, you might associate the term with a vast and sprawling network of rules text, meant to allow third-party creators to make supplementary content that is dependent on and compatible with the larger existing game. (You may even be accustomed to thinking of an SRD primarily as the database to consult when you need to double check the mechanics for your character.) However, in the indie TTRPG scene, an SRD is a small collection of interlocking mechanics that is made available for a designer to modify, use, and turn into a completely standalone game. An SRD in the indie TTRPG sense may be modeled on aspects of more than one game at a time, or it may not even have a mothership game from which it originated.
You can find plenty of SRDs to use on Itch.io. If you don’t know where to start looking, Kaden Ramstack has a decision-maker flowchart for some select SRDs, Fari RPGs has a directory of them, and I’m going to be writing SRD reviews soon here on my blog, focusing on what kinds of games each system is best suited for and how they can be modified to create something fresh and new.
Research
- Research similar games to get ideas and to make sure you aren’t treading too close to existing work.
This can be a frightening step, because it’s so easy to imagine this as the threshold where fresh young game ideas go to die. It’s disheartening to think about being struck by inspiration and then coming across an existing game written around the same inspiration, right?
But trust me, you cannot skip this step. If similar games have already been written, then even if you keep yourself unaware of them, the people who play your game will still know about them, and they will draw comparisons. It’s better to know. You want to be able to articulate how your game differs from other existing games, as well as how much they overlap.
During the course of your research, you may also come across games with details that inspire you or help solve a problem for your own game! Of course I’m not advocating for copying large fundamental portions of other games without permission. But you might come across little ahas that don’t belong to anyone in particular – “Aha, I can make hyperlinks out of the page number references that are supposed to guide the reader from one portion of the document to another!” or “Aha, I can have each player come up with the prompt for the next player in line!” or “Aha, I can tell a framing story between sections of my rules!” – that will guide your game’s development.
Drafting Rules Text
- Write out the rough rules for the main rules (aka the core gameplay loop).
- Write out the rough rules for any exceptions.
- Write out the rules for the frame: the setup, the end, and any turning points the game might have.
- Send the text of the game to an alpha reader for mechanical feedback. Make any necessary mechanical changes.
This may be a point where you prefer to do things in a different order. Perhaps you thrive on flavor text and need to have that in place first, or perhaps you really just want to write your text straight from beginning to end. However, I highly recommend writing rules text before any other text, and writing the rules text in this order: the main meat of the rules, then the exceptions and special cases, then the framing bits. At heart, a game needs to be playable, not just a pile of vibes*, so make sure your skeleton is solid before you start clothing it in beautiful ambience.
And once again, this process becomes vastly easier and faster if you choose to use an SRD rather than developing your own system. SRDs provide a ready-made mechanical framework, and in addition, they often provide helpful wording for concepts and directions, as well as helpful information about which portions can be customized without affecting game balance too much.
Once you’ve written your skeleton rules, choose an alpha reader whose opinions on how games work you trust. Be very clear that you’re looking for potential mechanical issues, not grammar corrections or general emotional support for the fact that you’re writing a game. Invite them to throw the weirdest, nastiest “but what if these happened?” edge cases at you. A trustworthy and thorough alpha mechanics reader or developmental editor is well worth cultivating a good relationship with, just as much as a reliable copyeditor or layout designer.
*Unless you’re writing a lyric game, in which case this is not the checklist you want to be referencing anyway.
Promotion
- Announce and promote the game.
Many more knowledgeable people than I have written eloquent and well-reasoned tips on when, where, and how much to promote. I’m not a marketing expert, so all I’ll contribute is that I generally keep quiet about games until I’m fairly certain they will be fully developed and released. It’s entirely possible that by doing this, I wait too long to start talking about a game. It’s entirely possible, even likely, that I haven’t emphasized the role that promotion plays with enough checkboxes in this list.
Talk about your game. Get other people excited about it. You know better than I do where you’re likely to find an audience willing to be interested in your work. Go forth and tell them all about it.
Rewriting
- Refine the language of the rules for clarity, concision, and organization.
At this stage, you may think your rules text is ready to go. In reality, it’s likely written in a kind of shorthand that you understand perfectly, but isn’t complete for anyone who hasn’t marinated in the ideas for the game as long as you have. In addition, during the writing process you might have changed your mind about terminology or moved sections around, and artifacts from older versions of your text may remain.
So go through and try to read your rules with fresh eyes. Envision the order in which the typical player will encounter your concepts as they’re reading through your game, and keep an eye out for any special terms that are used before they’re actually defined. Make sure you’ve used consistent terms for the same concepts throughout the text. Clarify what you mean by shorthand phrases like “on a failure”. Double check for any spots where you haven’t spelled out your implicit assumptions, such as whether the player takes a special action in addition to or instead of their normal turn. Partake in the time-honored tradition of tearing out your hair over the exact wording for shuffling the deck and drawing cards…
Playtesting
- Send the text of the game to playtesters for feedback on mechanics, general impressions, and text ambiguities. Make any necessary changes.
…and then the playtesters will let you know how well you succeeded at refining your language. In addition to the actual feedback they provide you, be sure to pay close attention to the mistakes they make while playing, which is valuable information about which portions of the rules still need more clarification.
Be considerate to your playtesters, and give them as much information as you can about what the game requires of them and what you require of them. For my games, the former typically includes a list of game materials they should gather, content warnings, and an estimate of how much time the playtest will take. The latter includes specific questions I want them to answer about their experience and the deadline for submitting their response.
Don’t skip playtesting. Don’t skip playtesting even if you’re pretty sure your game doesn’t need it. If you do, you’re essentially turning your customers into unwitting playtesters (and probably demanding money for this dubious privilege!) and consigning yourself to post-release customer support, dealing with any gaps that surface.
Don’t be afraid to ask around for playtesters. I’m truly fortunate to have a pool of people in my Discord server who are consistently interested in playtesting my games, and while not everyone has access to such a rich resource, you can ask your friends, family members, other TTRPG enthusiasts and game designers. If for some reason you truly have no one willing to playtest your games, and you can prove that you’ve made reasonable efforts to find people already, email me and I’ll test them myself.
And though I know it’s easy to get defensive about your game once the playtest reports start coming in, especially if they’re full of constructive criticism – don’t snap at the playtesters or dismiss their feedback with rationalizations that they just must not really get the game. The playtesters are doing what you asked them to do, and they’re likely very eager to contribute as many ideas and opinions as they can to your project. If you feel yourself getting sensitive, just thank your playtester for taking the time to play your game and provide feedback. Then come back to the feedback in a few days when you’re ready to start rewrites, or ask a trusted friend (like your alpha mechanics reader) to summarize the salient points for you.
Rounding Out the Text
- Add flavor text.
- Send the text of the game to a copyeditor.
Likely you have a good idea of your desired flavor text by this point – it’s just a matter of sitting down and actually writing it! You may also write the flavor text before this point; I tend to leave it late, because otherwise I run the risk of getting overly attached to the flavor corresponding to a mechanic that ends up needing to be changed or removed.
In either case, once your game is text-complete, send it to a copyeditor to do a close reading and fix spelling and grammar errors. Even if you are generally a good and clean writer, you’ve likely been working with that text long enough that by now you’re reading what you think it says. It’s important to get fresh eyes on the actual text on the page.
That said, I admit I skip this step because I am full of enough hubris to believe that my text has no errors. So far I have been punished with… discovering a double space in the middle of a sentence in one of my published games, and nothing worse.
(If you want to hire me to copyedit your games or any of your other written work, please see my rates on my Services page.)
Visual Design
- Source art for layout and Itch assets.
- Make a cover.
- Do PDF layout.
Sourcing art is a process that often runs parallel to much of the rest of development. As I get a better understanding of the aesthetic I want to evoke, I keep browsing for spot illustrations, page decorations, spacers, and even ornamental capital letters that support my vision. I generally find all my art assets from Unsplash, Pixabay, Pexels, Vecteezy, and Noun Project – all sites that grant permission to modify and use artwork in commercial projects for free. That said, it’s sadly common to find stolen and recolored art reposted as free, so keep a careful eye out and use reverse image searches when something looks too good to be true.
Personally I lay out my PDFs in Affinity Publisher 1. (I haven’t upgraded to Affinity Publisher 2 yet because I am a creature of habit.) While you could lay out your text in something like Microsoft Word or Google Docs and export a PDF when you’re done, I strongly recommend learning how to use dedicated layout software if you can; the extra array of tools they offer is lifesaving. The Affinity website has a lovely library of video tutorials that I have found very useful for learning more about the basics of layout and design, on top of learning how to use their software.
Going Live
- Create an Itch page, upload files, set appropriate tags and confirm a release date/time.
Itch.io is my sales platform of choice for several reasons. It has a thriving indie TTRPG scene already, tucked away in the “Physical Games” category. It allows you to set your own revenue split (including an option to give Itch 0% of the revenue). It offers a wide array of customization for the look of your game page and creator page. However, depending on your own circumstances and existing audience, you might opt to use DriveThruRPG or Ko-fi or another sales platform.
No matter what platform you use, however, the moment you upload your files and set a price (or no price!) and open up sales… is the moment that your work really starts! You haven’t forgotten about promotion, right? Promotion is the work that never truly ends, not until you’re ready to call it quits.
So congratulations! You’ve gotten through the easy part of the development roadmap. Best of luck and have fun writing your games!