This post is based on a suggestion from our Patreon Writers’ Room by patron Charlie Cox.
In this post I aim to run readers through the process of planning out and beginning work on a game intended for commercial release. I aim to keep “fluff” to a minimum here, but I will provide context where I think it will be beneficial, particularly while explaining my game project. This process looks different for each developer, and because experience leads to change, developers often alter their own process from one game to the next.
To help illustrate my process, I’ll be showing the steps I’ve recently taken with my own recent game project, a game I’m currently calling Cart King ’92.
Backstory
When I was a young kid first discovering the world of gaming, I think the physical act of playing games was a lot more interesting. Certainly, games have always been hanging around retail stores, but we also had the triumph and heartbreak of searching for hard-to-get titles at rental stores, the unique experience of going to other people’s homes and buying their games (okay, you can probably still find games at garage sales), and there was even a thriving underground economy of backpack-to-backpack buying and trading at schools that had largely outlawed gaming paraphernalia thanks to fear-mongering news outlets. Back then, our parents largely believed it.
For years I’ve wanted to find a way to capture this era in a game for other folks who recall those days and later so my son can get just a little hint of what life was like before the internet took us mostly digital. Recently I thought of turning this into a playable experience by blending the gameplay and style of a retro RPG with the inventory management and NPC interactions of a space sim game like Elite: Dangerous or, well, any of the others. The story that came to me was a kid from humble beginnings who set out to build the ultimate video game collection. They’ll compete with other notable kids in sort of an ongoing Civilization-style leader competition where multiple endings would be possible depending on what they accomplish. I eventually determined that, though the idea is unusual, it’s worth finally taking a run at it.
Planning
Let’s talk about game design documents.
In the pro game industry, a detailed game design document acts as a unified answer book to keep medium-to-large development teams on track once a game leaves the planning stage. But there’s another benefit, and a reason any indie developer, even as a soloist, should fill one out for any serious project: it will force you to answer questions that go beyond the idea in your head to get you thinking practically about your potential game as a viable product, what you would have to achieve to bring the idea to life, and what you would be able to do with it once you did. I think at best you can expect several major hurdles or drastic changes of direction in a project if you get an idea and just start coding without a design document. At worst, you realize the idea was much more complicated than you realize or find out there’s a good reason the idea doesn’t work in the real world at all.
To account for the differences in how professional teams and indies benefit from game design documents, I’ve been tweaking one to my liking for a little while now. To help with this post and my own upcoming project, I’ve cleaned up the document, added some template notes, and uploaded it to Itch.io where you can use it freely. It’s been very popular there!
My game design document template at Itch
I believe a game design document should be the first thing you will do after deciding for certain that you want to pursue a project. That’s because the document will require you to answer questions about what you want to achieve in your prototype, what you want the game to look and sound like, and how you want to put assets together with code or a game engine. In addition, it will take you through the roles you play as a marketing expert, a designer, a developer, and all the other responsibilities of an independent creator. Finally, it will have you look to the future to determine what will mean the project was successful, and what your priorities will be for the game after release.
If you get through the game design document and feel you’ve provided good answers that will set you up for success, you are ready to set up your project.
Setting Up the Project
Setting up a new development project is not a new experience to any developer, published or not. Most of us have set up countless projects, turning some portion of our hard drives into graveyards for wasted potential. But if you have a good design document under your belt, you should be eager to dig in at this point.
Needless to say, this part will look different for everyone, but I’m going to explain how I got started with my latest project, a couple of things I firmly believe everyone should do, and then a couple of things I’m trying that are giving me stellar results this time around.
I decided I wanted to have my hands on as much code as possible for Cart King ’92 because I don’t want to spend another project trying to figure out what Unity wants me to do when I would have known how to do the thing in code. That said, platform flexibility was important to me. If this game turns some heads on PC, I may very well try my luck on one or more consoles. So, I needed a toolset that would let me code the game the way I wanted, but was also mature and full-featured enough to give me some options at release time. Surprisingly enough, the leading way to achieve this is likely some version of Microsoft’s discontinued XNA framework. XNA’s demise led to the development community’s XNA extension project, Monogame, and a framework called FNA, which is a different extension focused on being the closest translation of XNA possible. FNA is often preferred for PC releases, where many folks like to use Monogame for console projects. If that sounds like a mess, then I’ve probably done a good job of explaining the situation. Basically I started this project in Monogame, went to our old podcast guest friend, Path of Motus creator Michael Hicks with some questions, and he happily answered them but warned me that FNA was probably going to give a more positive development experience, and he even had, not just A video series about FNA, THE video series about FNA that is advertised on the FNA homepage. God bless you, Michael Hicks.
Starting a new project should be done according to your engine/framework’s creator recommendations. Playing it by the book when you’re starting out will get you in the right frame of mind and will help get you the most out of your tools. I recommend following the directions to get a new clean project started, then immediately committing that starting point to the version control system of your choice. As I’ve mentioned before, I’m a Git man.
A quick aside on version control: I was a holdout for a very long time on using version control as a solo developer. To be completely honest, I made it through my first commercial release without it. I was using Lua at the time and the files and tools stayed simple throughout. I worked out of a Dropbox directory and even managed to use it to restore incomplete files or get rid of unwanted changes. There were also a couple of small issues I did not recover from that way. Nonetheless it allowed me to mostly protect my files and work smoothly between multiple machines right up through game launch.
Unfortunately, there are several reasons you should not depend on a service like Dropbox for a software project. First off, the services are not designed for this purpose, so using them this way becomes inconvenient in a hurry. The various snapshots Dropbox takes of a file, for example, are not perfect. There were a couple of times I tried to restore a file at a certain save point and it simply existed nowhere. You’re not really in control of how a service like this manages your files, it simply works on its own schedule which will eventually be at odds with what you need from it. Real version control, on the other hand, allows you to determine when to commit changes and create a project-wide snapshot of the entire project directory exactly as you want it to look. No matter what you do to the project in the future, you will be able to return to this precise state as long as the repository exists. Second, big game engines like Unity and Unreal hate when you work out of a directory being managed by a service like Dropbox. I don’t know what the experience looks like now, but there was a point in time when I tried this and I literally got non-stop notices from Dropbox about files being saved, synced, resynced, and occasionally, complaints that they were locked or in use. It becomes a nightmare fast. Unity loves Git and includes a variety of tools you can use to manage your repository right there in the editor. Finally, using Git or Subversion gives you an opportunity to sharpen a valuable skillset that stays in demand on professional teams of all shapes and sizes. Maybe you will never work on a software team in your life, but you may collaborate with someone who would love nothing more than to “go pro,” and this will set them up for success as well. Finally, learning and using Git is weirdly fun to me. I prefer the command line. It’s dead simple to learn and I just enjoy it.
Before we move on, I also recommend a solution like Git’s Large File Storage system. If you’re not familiar with the “large file problem” in version control, we covered it pretty well in my #GameDev Breakdown chat with Edward Thomson and Kayla Ngan of Microsoft Visual Studio Team Services at GDC ’18. Basically, using version control for game design often causes you to commit copies of large asset files like images and sound files repeatedly as you save changes to the repository. If you’re not careful, this will cause the size of your repository to explode. Some people, as Edward Thomson explains, will configure Git to simply ignore these asset files, creating a situation where they commit code to their version control repository and leave asset files in a Dropbox directory or on Google Drive. This seems like a nightmare scenario to me as well. Fortunately, Git Large File Storage will allow you to commit asset files to your repository once, then your repository will simply maintain links to those files unless direct changes require them to be committed again. I’ve been using this for a short time now, and for game development, this causes Git to behave exactly the way you want it to.
So what about hosting for your version control repositories? GitHub is an awesome site and I think just about every developer should have an account there for fun, collaboration, and portfolio purposes. Unfortunately, any repository you maintain there for free will be public, meaning anyone can go to your profile and see what you’re up to. You may determine that that’s totally fine with you, and then your problem is solved. Bitbucket is a get-started-free option that gives you a certain amount of room, particularly if you’re using Git LFS there, where you can maintain private repositories up to that point. I’ve had a Bitbucket account forever and have not run into any limitations.
There’s another option that I discovered in conversation with Microsoft cloud advocate, Jessica Deen, also at GDC: If you set up a workspace at Microsoft’s Azure DevOps site, they offer unlimited private repos just to have you in their sandbox. I wanted to try this, because eventually leveraging some cloud services for my games is well within the realm of possibility and I like what I’ve heard about Azure for this purpose. I found loads of benefits to doing this. I don’t know what the future holds for this offer, and maybe one day I’ll have to migrate out, but I love using the Azure site. Starting a new project gives you a project dashboard with several nice features. I was able to start a task board for work items which I consider another absolute must for a new project. Trello is a great alternative, but this turned out to be a great way to have everything integrated. You can also start a Wiki for your project, so if I were to bring anyone on to work on Cart King with me, I would absolutely go into my design document and turn the sections of the doc into Wiki entries, capture concepts about the game, and would maintain that all the way through the project. I also recently learned I can have multiple repositories in the same project. Why would you ever want that, right? Sadly, I got a decent amount of work done before I thought to go talk to Michael Hicks about my current project. When he showed me FNA, I decided to start a new project his way, follow through his video series, and then bring over as much of my work from the original project as I could, so in my Cart King project I have a repo called CartKing92 and now a second called CartKingFNA. It’s nice that this didn’t have to go in a completely new project. The DevOps site certainly goes even further, but these are the features I’m happy about right now. However you decide to start, at minimum, I strongly advise a version control system and a task board like you can use at Trello.
Working Toward the Prototype
With our game design document safely tucked away, our project started and established in a repository, the scope of the prototype should already be established, only leaving you to decide what to work on first. I often find myself working in a new engine or coding with a new framework, and when this is your situation, I’m known to take things very slow. A lot of developers like to invest a ton of time up front, deciding what helper functions they need on day one, mapping out object-oriented class hierarchies in detail, and even making plans for custom editors before they’ve done too much of anything on a new project. Michael’s FNA video series on YouTube does this, because he’s a very bright programmer and has intimate knowledge of the framework he’s using. If you are already reasonably comfortable with your tools, I’d encourage this. Who wants to rework something later for no reason, right? Work smart, come up with a great plan of attack, and use the hell out of that task board we talked about. Not committing everything to memory means your brain gets to stay nice and relaxed throughout your project. If you’re more like me and usually learning something new while you’re working, I’m a huge advocate for baby steps. My initial task list literally contained work items like “Get project to build without errors. Draw one frame of a sprite on screen. Get character to respond to keyboard events. Get spritesheet animations to work. Get character animated correctly based on direction.” As I worked on these and tested them, invariably I’d find two new things I needed to do for each time I test the game. Which is good! On to the task board they go. I strongly believe in establishing positive momentum when you’re not confident. In this scenario, I think it’s okay to go back and clean things up and refactor code later when you feel very good about what you’ve already achieved. Worrying too much about whether the player character extends the animated character class template or the projectile character class template while you’re still not sure how spritebatch drawing works is a great recipe for feeling overwhelmed and possibly quitting before you really do anything.
Once my task list is established on the board, one task usually stands out as being the most important thing I can do next, so I move it to the “doing” column, finish it and test it, commit my changes to the version control repository, move the item to the “complete” column, and move on to the next one. This loop can be repeated until your prototype is completely done.
Other things I strongly believe in: Use as much dirty programmer art as you want so you can get things moving. You have the project’s whole development cycle ahead of you to source art or perfect your own. Use asset packs from absolutely anyone who will give you permission. There is zero shame in this. I ran across an online tirade from an artist one time declaring “any developer who uses Fiverr to get cheap art is not a true creator!” He seemed to believe he could rant a magical budget into people’s pockets which they’d, for some reason, spend on him. That is not real life. Who wouldn’t want to do work with a great artist? In reality, most of us have to work our way up to that, and it does not make a lot of sense to me that an artist would be trying to stop the train that’s eventually going to reach their station. I look at resources like OpenGameArt, Kenney.nl, and any others I can find without a care in the world for what someone else might be doing with them. I give credit, I thank people, I use the material in accordance with the license, but I know that what I do with it will be uniquely mine. I try to make each decision feed into momentum and productivity. If one choice lets me work, that’s the choice I make. Everything else is secondary. This is how muscles are grown and milestones are achieved.
And Beyond
The prototype point looks different for each project. Initially I wanted to be done with a prototype before putting together this post. For Cart King, however, I realized a lot of intricate subsystems actually need to be functional before I can give players a sense of what the proper game is going to feel like to play, including a fairly mature inventory system, dialogue, a system that maintains loads of data about the in-game video game market, all in addition to the standard retro RPG controls of walking around, colliding with doors, pressing A to talk, etc. For this reason, what you’ll do with feedback to continue work on the final game will be unique to your project also, but you will largely continue the same work item -> code -> test -> commit -> Update tasks loop until the last problem is solved and you are ready to get a great Early Access campaign going, look for funding, Beta test, straight up launch the game, whatever you want to do next.
Whatever your strategy, make sure you’re taking plenty of time to update players and friends on what you’re doing with the project so you can build an excited community of true believers ready to dive in head first and help you tell the world about what you’ve done. Precious months and years of your life are invested into these projects—take it seriously, do it well, and understand that even if you work solo, you do not live through the experience alone.
Cover photo: “GDC Online 2011_Tuesday_Show Environment” by Official GDC is licensed under CC BY 2.0
