Creating a game is no small feat—anyone who has tried knows this firsthand. During the development of Veilrunners RPG, I learned a lot. There were principles I already understood, but had to proactively apply and defend under real development pressure. Others were genuine surprises—areas where the complexity, effort, or uncertainty created challenges to be overcome. What follows is a candid look at my experience as an indie game developer, including mistakes, tradeoffs, and insights that might save you time (and frustration) as you bring your project to life. For more about Veilrunners see DriveThruRPG.com.
Defining Vision Is Foundational
This is one thing I think I did reasonably well. Before I earnestly started the development of Veilrunners RPG, I carefully and thoughtfully considered what I wanted to create and why it should be created. My wife helped me frame the vision by telling me to “create the game you want to play.” I knew it was to be a solo, sci-fi RPG, but I had to really think about what would differentiate Veilrunners from other excellent games.
For Veilrunners, that meant:
- Solo-first design, with co-op and GM-led sessions a possibility
- A rich, believable setting
- A PG-13 feel—excitement, danger, but without much gore
- Sessions that are playable in one sitting
There were other driving concepts, but you get the idea. Everything that I created had to measure up to this vision. If it didn’t, it was added to a futures list or just discarded. When I didn’t listen to my own advice, I invariably ended up wasting time and effort on things that were too complex, didn’t fit well within the game’s context, or were an unnecessary time sink.
Once your vision is clear, write it down and refer to it often. Think very carefully before you revise it.
Define Scope and Stick to It
When I am designing a computer program, the first thing I do after defining the vision is to decide the scope of work. What’s going to be in and what’s going to be out. This isn’t easy to do, especially when you are the only designer. Ruthlessness is needed here. Unless something adds to the player’s enjoyment of the game, leave it out. There were too many temptations to count where I could have added this or that “to make it better.”
I call this gold plating—continuing to add things or change things after the project meets the stated goals. Here’s one example from Veilrunners. One of my favorite factions is the Suiren-Ka, a descendant of old-earth Yakuza traditions, but refined and gentle in appearance. The name means “Water Lily Society.” But under the surface, they are dangerous and ruthless, exercising control from afar. As the full scope of Veilrunners became apparent, I cut the Suiren-Ka mission thread from the game. I really hated to remove it, but I had to draw a line. I decided to release a set of missions or perhaps a mini-campaign based on the Suiren-Ka at a later date but removed it from the release version.
Like you did with your vision, write down the project scope and refer to it often.
Another way to limit scope is to reuse something that already exists:
Don’t Reinvent the Wheel
For me, this means the game system—the mechanics of play. When I started development, I put many hours of effort into creating a unique game system that mimicked systems I knew and liked but also added my own unique twists (in reality, I was actually creating a new system). After going through numerous iterations of design—test—evaluate—tweak, I was frustrated and somewhat disheartened. I learned that creating a new system of game mechanics is time-consuming and difficult to get right.
Then the light dawned. In software development, I have a guiding principle—if you can reuse something that meets the project’s needs, leverage it instead of creating something from scratch. Reusing existing systems provides an economy of effort and is a safeguard against new bugs.
I should have started with this principle in mind when I was deciding on a game system. Once I came to my senses, I quickly realized that one of my favorite solo RPGs—Hostile Solo—was built on the Cepheus Engine. This is the same system behind the incredibly successful sci-fi game Traveller. And so, I adopted Cepheus as the foundation for Veilrunners’ game mechanics (Cepheus is released under the Open Game License).
If I had heeded my own advice to start with, I would have saved many, many hours of frustration. That said, there are tradeoffs to consider when releasing a game under the OGL. I made sure I understood what they were and how they may affect the game. In the end, it was a no-brainer for me.
Things Take Longer Than Expected
This didn’t completely surprise me, but even so, I didn’t expect it to take as long as it did to design, create, and get the game ready for publishing. One of the biggest delays in finishing Veilrunners was something called life. Because of unavoidable and unpredictable life events, there were about three months in which I could spend almost no time on the project. Things happen—expect it and then roll with it. But don’t lose your vision and drive.
There will be some things that just take a lot longer than you thought they would. That’s to be expected if this is your first game. Don’t be surprised, just roll with it. Creating the mini-campaign in Veilrunners took more time than I envisioned. What I had in my head proved to need a lot more refining to make it “right”.
Also don’t underestimate the time it will take to get the manual laid out for publication. I’ve done a large number of PDF magazines, so I had a handle on my expectations, and I had experience creating layout templates for publication. Don’t skimp here – take the time to do it well.
Leverage Automation
I have a lot of spreadsheets related to Veilrunners. All of the tables (there are many), all of the enemies, and more were created and managed in spreadsheets. Being a programmer, I asked myself: what can I automate to make things easier, better, or faster?
I created a template for enemies that followed the same format for each enemy type. This way, I always began a new enemy faction design from the same baseline. I also created a formula to perform a rough calculation of an enemy’s relative threat level. This estimate is based on their raw stats plus their abilities. It isn’t perfect, but it is very useful when designing encounters. I tweaked the formula as combat testing proceeded and changed the weight of stats that had the most impact on threat level.
I know this next tip might not work for everyone: I created a program to automate combat testing. It was not intended to be a perfect replication of combat, but it did use most of the combat rules and the attributes of the PCs and NPCs. It gave me a quick way to narrow down the design of enemy factions by weeding out overly complex or unnecessary factors. Once combat testing validated the results, it also gave me a way to prequalify any changes I made to enemy design.
Leverage AI Wisely and Openly
If you leverage AI to create the final product (e.g., generated images), disclose its usage. Using AI to create images is frowned upon in the gaming community, and understandably so. I have an image I “created” with AI that is, frankly, a perfect representation of the feel of Veilrunners. It would have made a great cover image, but I didn’t use it. I don’t have the budget to hire an artist, so my workaround was to use image libraries like Shutterstock, ensuring that the images I chose were created by Mark 1 humans.
I also bounced ideas off of AI, used it to help test combat, and to help me calculate percentages. I used it to help refine my words and keep them within my declared writing style—but I did the writing and design work. Don’t fall into the AI trap and give up your creativity. AI can be a big help—but it must be limited to the role of a helper, a tool. You must be the creative designer and author.
Have No Sacred Cows
This may prove difficult to implement, but it is truly important. It’s easier to do if you have a vision and scope clearly defined in writing. Keep your goals in mind and remember you are creating a game for others, not just for yourself. If something you really want to include is actually getting in the way—by adding complexity, breaking scope, or you feeling like you’re jamming a square peg in a round hole—set it aside.
I think the biggest sacred cow for me was the design of a custom game system. It was hard for me to lay my unique ideas aside. Even after I knew (in my head) that Cepheus was the way forward, I kept coming back to my custom system. I just really wanted to create my own unique system, even though it didn’t meet my own criteria.
In Conclusion
These are just a few of the things I learned from the design and creation of Veilrunners RPG. I hope they are helpful to you, but the most important thing I can share with you is this: If you have an idea for something, whether it’s a game or anything else, go ahead and bring it to life. Don’t put it on eternal hold. Go for it!
