One of the questions I’m asked a lot is what it takes to make a game. After more than a dozen years as a game developer, I’ve finished a lot of games (and I'm currently working on 2+).
This blog post covers my process of making a game from start to finish, along with thoughts and stumbling blocks along the way! Of course, this isn’t the only way to make games. But it’s the way that works for me!
The Idea
The idea stage is my favorite. Some people struggle to come up with new ideas, but personally I never have - ideas come to me faster than I know what to do with. Because of this, I try to at least keep my ideas organized. I keep all of my ideas in a spreadsheet, with a genre, score (how much I like the idea), description, and link to a game design document if it exists. I also keep notes, mainly things the idea is missing or needs to improve.
When I have a new idea, I add it to the sheet, or perhaps merge with and edit previous ideas. I also update the scores periodically to keep the best ideas at the top (there are currently 64 ideas in the list… the bottom ones will never see the light of day).
This also lets ideas age - when you have a new idea, it always feels special, like the best idea you've ever had. After a few months sitting in the ideas list, the novelty of some of the ideas wears off and it goes down the list, while some stay as interesting and exciting as ever.
When it's time to start a new game project, I have a list of ideas to look through that have had edits, improvements, and have weathered the test of time.
Finally, at the top of the list, I have a reminder for myself:
A good game idea
Is something I'm excited to make
Capable of making
And has a viable market
These may all seem pretty obvious, but it's surprising how many times I come up with an idea that doesn't follow one (or any) of them.
The Prototype
When I’ve settled on an idea, the first thing I do is make a prototype. The goal of the prototype is to see - vaguely - how the game plays and whether it is actually fun. I often share prototypes around with friends, and if there's something missing, I put a note in the ideas document and put that idea on hold until I come up with a potential improvement. While it's sad to put an idea on hold, it's always better to rethink things during the prototype phase - this is when you can change things with the least amount of work. Worst case, it's better to drop a prototype than a half-finished game. A poor idea almost never gets better with additional work and content.
The Honeymoon
I like to call early development on a game the honeymoon phase - that's because it's the most exciting part. The idea is still new, and a small amount of work can make huge improvements. Everything feels like it's going quickly and smoothly, and motivation is high. A short enough project can live entirely in this phase, although I rarely see that outside of game jams.
The Grind
Eventually, the honeymoon phase ends, and you need to start finding ways to motivate yourself to continue. New ideas beckon, and you see less and less progress for the work you put in. This is a normal part of the development process, and you have to learn how to stay focused and persevere, or you may never release a game. Keeping projects short reduces the grind, but even though I told myself I'd never make a 3+ year project again after Aground, I am currently working on two of them! The most exciting projects tend to take time, and they can be worthwhile, but you do have to find ways to deal with project fatigue.
Other than having self discipline (to motivate yourself and stay focused), there are two things that help me the most with project fatigue. One is to break tasks into meaningful and bite-sized pieces that I can check off and feel accomplished for finishing. The other is alternating between tasks I want to and don’t want to do throughout the project - if you always focus on the tasks you want to do first, you’ll end up with a large stretch of tasks you DON’T want to do. There are three things that cause the most grind for me - content, technical debt, and polish, which I’ll detail below.
Content
For me, the grind is often caused by content. The game is feature complete, the gameplay and aspects that are fun to code are complete and the game feels "done" in my mind, but it still needs a lot of content added. While it varies from project to project, I've found in general 1 hour of gameplay (for the player) takes about 1 month to develop. Without content, players won't know how to interact with all of the interesting mechanics you've added, and there won't be any cohesion to the game.
Mixing content and gameplay tasks makes a lot of sense - especially since new content usually unlocks new gameplay. However, if you're not doing a solo project, you often need to wait for art/content to be created by other team members, so sometimes I frontload all the gameplay tasks anyways. However, in this case, it can still be fun to see the new art and content made by others and integrate it into the game.
Technical Debt
Throughout a project, you will notice things that need to change or have feature suggestions or bug reports. Sometimes you fix these right away, but more often than not, you add it to a TODO list so you don't distract yourself from what you're currently working on. This is called Technical Debt - by putting it off, you have added tasks that you will have to complete later - and this can quickly get overwhelming.
Keep this list organized, be thoughtful before adding things to the list (does it REALLY need to be added), and clear items in it periodically to keep technical debt down.
Polish
There are two main kinds of polish:
- Juice - Making the game more exciting and actions you take feel more impactful.
- Oil - Removing stumbling blocks and making the game (and user experience) flow smoother.
You'll need both - as without oil, no matter how fun the game is, players will get frustrated and quit, and without juice, almost any gameplay loop will feel grindy. However, you can't just add "polish" as an item on your TODO list, it requires experimentation, feedback and iteration.
Here's a really good article about oil: https://www.gamedeveloper.com/design/oil-it-or-spoil-it-
Testing
Once you have something you're ready to share, I strongly recommend running a playtest and getting feedback from players - as you can never see your own game with fresh eyes. You'll rarely notice when your game is missing polish, as you're too used to the game and UI to notice a lack of oil, and you're too invested in the game to notice a lack of juice. However, during testing you'll get more feedback, suggestions, and bug reports than you know what to do with. If you're not careful, you could easily end up in an endless loop of technical debt and polish.
The Finish Line
At some point, you have to say the game is done. It will never be 100% - there will always be things you could do to improve the game. There's also a boost to motivation when you are near completion, so setting a firm launch date and choosing what final changes you want to make will often push you through the last bit needed before launch.
There will always be people wanting more (especially now that game as a service is a thing, and players are used to endless updates). So, find a place where you personally feel satisfied to call it done. You can always do a sequel or spinoff, if the right idea strikes you.
Conclusion
This blog post focused on the development side - as that is my forte. There's a whole list of marketing, publishing and post-launch stuff that's necessary too. Making a good game gives you the potential to succeed, but there's never any guarantee - even with a big marketing budget. But, I feel like just making it to the finish line of a large project is a huge achievement to be proud of.
