8 Things I wish I knew before building an RPG

After working on a large scale RPG project for 2 years, I’ve learned quite a bit. Mainly through the process of making stupid decisions. Below I’ve catalogued 8 things I’ve learned that could save you up to 6 months or more on your next project.

Choose the correct game engine first

Originally we started with an HTML5 game and hit a wall with what we could do. Sadly this resulted in losing about 9 months of development work (some of which we refactored into Unity). The HTML5 toolset is a bit limited compared to lower level systems like Unreal and Unity (both of which now export to HTML5). If you want to work with a small team (less than 10) use Unity. If you want a larger team go with Unreal.

Also be sure to research that whatever complex features you need (UI, pathfinding, ect). Make sure they’re all readily available natively or as a plugin. The last thing you want to do is spend months writing a feature from scratch that may or may not work. Or waiting for months on a game engine’s feature to be released.

You’re running a game marathon, not a sprint!

I used to put in 60 – 70 hour weeks constantly. I had to in order to make pressing deadlines our team agreed on. While I still do this on the occasion, this is generally not a good idea. Putting in massive amounts of time on the game, I found myself emotionally unstable at the end of ever week and feeling extremely depressed. I know a few other developers who did this for about 2 years, all of them have burnt out and quit.

The first RPG a successful indie team makes, usually takes about 5 years or more. To keep up for that long you need to pace yourself at 40 hours a week. Remember that being excited to work on something again the next week is a good thing. Don’t work yourself in a way that causes you to hate what you’re doing.

Avoid Excel Spreadsheets like the black plague

One of my biggest regrets for data entry was using an Excel Spreadsheet. Importing them is a pain and incorrectly formatted information results in difficult to debug errors. Instead you should build all your data directly into your editor. Modern game engines like Unity support this functionality.

Not you should consider using Excel Sheets to translate your game’s text. But beyond that I haven’t found a concrete reason to use them.

Build for sustainability and refactoring

Having to rewrite lots of code can be the nails in the coffin for a project. I’ve rewritten far more than I ever should have. Mostly because I tried to cram too many bells and whistles into each feature. As I should have focused on building solid partial implementations that could be scaled as our code base progressed.

Create a prototype as quickly as possible

The faster you can build a prototype to test out your ideas the better. As a majority of this code, development, and art are going to be scrapped long term. I recommend using the Unity Asset Store to find plugins or pre-built projects close to what you’re already trying to achieve.

Note that we use about 8 Unity plugins on A Dragon Named Coal. A chunk of the plugins we attempted to prototype with had to be discarded due to a lack of updates from the developer or inflexible APIs. Test your plugins before you integrate them with your project’s core.

Use visual scripting libraries combined with scripts

Managing large amounts of code with a team is difficult. Remembering what your code does when you come back to look at it several months later is even more difficult. Because of this I recommend using Behavior Trees and Finite State Machines. In Unity you can achieve these through PlayMaker and Behavior Designer (both of which I recommend).

Visual scripting libraries are important, as they will abstract out your API logic for inventory and other features. Plus it saves you from writing tons of scripts into your games whenever you want a simple interactive feature.

RPGs are built by teams, not individuals

Even the big name indie RPGs built by one guy have others helping them. For example the famous Dust: Elysian Tale had multiple people working on the project near the end. Even though is was primarily one guy.

Get a team together when you think you have something solid to talk with others about. You should have a story outline and prototype of the game before trying to approach others.

Build a solid stats and inventory system early on

If your game has combat you’ll want to figure out the stats system early on. This means figuring out how defense, attacks, specials, equipemnt, ect, and how it all fits together. When I ask many indies about this subject they usually just draw a blank and say “I have no clue how that will work.” You can figure out a lot of this by running pen and paper comparison of how these stat systems could work together. DnD rules are also another great source of inspiration. Although DnD’s d20 system is targeted at much fewer encounters than your game will probably have.