I've seen the numbers; they tell a clear story and it doesn't have a happy ending. The average person who wants to make a game doesn't. Only a fraction of aspiring gamedevs download game-making tools, a fraction of those open the tools, another fraction use them for more than a week and of those, a few finish and ship a game. This isn't a 80/20 split, it's more like 999/1.
The average person doesn't ship.
Jump in blindly and you'll fail. If you're reading this, then maybe this has happened already. I know it's happened to me, several times!
So what can be done?
Learn from other developers.
- Look at developers who didn't finish and ask why
- Look at developers who did finish and ask why
You can read about the common ways people don't finish in the articles "Not Your Problem" and "Seven Sins of the Eternal Dev". In this article we take a closer look at developers who do finish.
Developers that Finish
Gunpoint by Tom Francis is a great case-study for how to finish a project. As a case-study it has several attractive properties:
- Tom had never programmed before.
- It was developed in the open (blog posts, youtube videos).
- Tom has an excellent ability to prioritize his efforts.
- Gunpoint is a fun, innovative and did well commercially.
There's a good GDC talk by Tom here and if you've never read [Derek Yu's Make Games] article(derek_make_a_game>) then I highly recommend reading that too!
Timepoints
From the start of Gunpoint Tom sets a development timeframe from six months to a year. All games ideas are evaluated in regards to this timeline. This works far better than coming up with a unbounded game idea. With an unbounded idea you no understanding how long it will take to finish.
Try to absorb the concept of time as a finite resource as tool to evaluate any decision. You get so many time points that you can assign to this game. Spend them wisely and you'll work effectively on the game. Working effectively is working on things that matter to the player. If you have 100 time points to spend to get this game done and spend 25 on an opening cutscene the player only sees once - that's not a good investment! Spend that 25 on the core mechanic or how good the controls feel and that's something that player is going appreciate over and over again.
The Game Development Process
This checklist describes an ideal process of creating a game.
- Preproduction a. Analysis b. Premise c. Scope d. Game Design e. Break up game into self-contained layers f. Assign Milestones
- Production a. Consistent schedule b. Outcome for each block of time c. Build the layers d. Iterate e. Reevaluate milestones f. Prioritize player "fun"
- Last 20% a. What needs to be done to ship b. Update the ship-date c. Accept imperfection d. Prioritize player "fun"
- Release
In this article we'll dig into each step.
Preproduction
Preproduction is the period of time before a single line of code is written. It's the time to come-up with a premise, timeline and game idea.
Analysis
The analysis phase comes before you have an idea for a game. This is the fun bit. Play games and reflect on why you enjoy a particular game. Then ask "Could I take this mechanic, or a riff on it and put into my own game?".
With Gunpoint, Tom references Spelunky and Deus Ex as influences:
On some level, my game is going to be about fucking with people. When you get down to it, the reason I like Deus Ex isn’t because I have the choice of using a multitool or shooting a guy. It’s that I can trick the guy into doing what I want. If I don’t have the key to a door with a guard on the other side, I can just shoot a wall, and he’ll unlock it for me when he comes to investigate the noise.
Premise
With your discerning palate and eye for a good mechanic; it's time to come up with a premise. By premise I don't necessarily mean a game idea. Instead I mean something more like a theory. X is fun, but what if I changed it slightly; could it be done in 2d, or in real time, or turn based, or time-limited, or with action points etc.
Could I make something that gives a similar play-scape and engagement choice that Deus Ex gives, but in 2d? (Gunpoint)
Could I make a game that's about the emotional stress of dungeon crawling? (Darkest Dungeon).
Could I create something like the board game Dungeon Quest but with one player and on the computer? (Guild of Dungeoneering)
Your premise should simplify. Don't have a premise like "Could I have game like Deus Ex but as a MMORPG?" and that brings us nicely to scope.
Scope
Scope is the most important factor for finishing a game. When enthusiasm inevitably wanes it's easier to push on if the finish line isn't too far away.
Now you have premise it needs tempering with a realistic scope. Commit to a timeframe of no more than year. Then work backwards from and consider how much you can realistically get done.
The scope and premise form the boundaries for your game's design. Don't worry about this being restrictive. Restrictions help the creative process.
Game Design
Use your scope and premise to come up with an idea for a game you think you can complete. You don't need a massive game design doc, things are going to change, you just need enough to start and some idea where you'd like to finish.
Layers
There's a way of building games. Start a simple self-contained system - such as movement. Iterate on that until your happy (or not don't loathe it and yourself :)). Then build the next system on top of that.
When building systems stick to these rules
- At all times the game is playable
- New layers build on the previous ones
- It's expected you'll iterate on earlier layers are you add new ones
If you want more detail about this read the article Develop From a Kernel of Fun.
Gunpoint followed a similar path in it's development:
All my ideas for stuff like this have different modules: there’s a basic version I’m definitely going to try, then progressively fancier systems I could stack on top of it if it turns out to be interesting and fun.
Before writing a single line of code know what layers your game is made up from. To figure our which layers you need; consider what you want to make, then break it up in self-contained systems.
To begin with ask yourself "What's the most basic thing I can make that people could play?". And then ask "What's the next most basic thing?".
For Gunpoint the first few layers looked like this:
- Simple Movement and Collision
- Jumping
- Guard that shoots you on sight
- Jumping on to guard to disable him
- Guard AI - path to sound
- Doors and Switches
- Stairs and elevators
- Cross Link
As you move through the layers you get a new version of game slightly closer to the final product.
Milestones
Milestones are plot out how you're going to get things finish. You need to take your timeframe and layers and workout when you want each piece complete.
These are the Gunpoint milestones - each was probably ballparked at a weekend's worth of work.
- Milestone 1: movement fully working, however horrible it looks and shitty it feels.
- Milestone 2: one hostile who shoots on sight, and can be pounced on and beaten unconscious.
- Milestone 3: two devices that are interactable. I’ll talk about devices once I’ve got them working.
- Milestone 4: one fully working level that’s fun.
- Milestone 5: a dialogue system why not?
- Milestone 6: narrative reduces grown men to hopeless fits of sobbing.
- Milestone 7: the Citizen Kane of games.
Don't worry too much about the accuracy of these, especially later ones. Do consider sharing your plan publicly and the results of each milestone as you arrive at it. It helps with marketing and also gives a little bit of outside accountability.
Production
You now have a game idea, a timeframe and set of milestones; it's coding time.
Consistent Schedule
You need space and time to write a game. Making time and space to create should not require any cognitive load from you. It should automatic. The easiest way to achieve this is consistency. Do a day a week, two hours a day, wherever you can carve out consistent time. If you honestly can't do this then finishing a game will be even more of a struggle. Consider staying in preproduction until you can block out the time.
Outcome for each block of time
Each time you work on the game, have an idea of what you want to achieve at the end of that period. Keep moving forwards.
Build the layers
Time to do the work. Build your layers. Basically functional is most important, not fun, not polished just working. You can iterate on working, you can't iterate on half done.
If you want some more practical tips try the article Want to Finish do This.
Iterate
After getting a system basically functional but kind of terrible. It's time to iterate on it until it feels better.
If you've iterated on your layer a lot and it still doesn't feel good, adding more stuff or new features rarely helps. Instead solicit outside feedback, rethink or rewrite. If you're early on in your development it's ok to restart - not all premises work out.
In Gunpoint, Tom is very good at evaluating the second-order effects of programming solutions to problems. For instance when iterating he'll often first think-up a simple hacky fix but instead of pursuing it, he thinks about it's effect on the entire project. For instance he may consider a feature in the light of:
Requirement: I want to continually tweak the game play systems
Reflection: Does this solution make tweaking game play systems harder in the future?
If the answer is yes, he thinks of a better solution. The goal of "making a fun" game is kept in-mind at all times. There's no drifting in writing cool-tech for cool-tech's sake.
Reevaluate Milestones
Constantly evaluate features and down-scope them if the implementation time does not give a large enough benefit to the final game. What's the value of this feature? If it's not a significant value you can't afford it.
Prioritize player "fun"
Concentrate effort on features that the player will be exposed to most.
Are you polishing a part of the game the players only see once? Or only 1% of player's see? Ask yourself honestly, given the time remaining; is this a cost effective use of your time?
Last 20%
At this point the game is playable. It has most of the content. There's just a a few rough edges and maybe a feature to put in.
The last 20% includes all the stuff that a released game is expected to have:
- Dealing with different resolutions
- Gamepad support
- Options (sound, subtitles etc.)
- Platform integration (such as Steam)
- Wider testing and bug-fixing
- Credits
... and all the stuff that you forgot.
At this point don't worry about localisation or other platforms after your primary one. These can be addressed post-release.
Be aware that it's well-known the last 20% takes more time than expected!
What needs to be done to ship
Don't let the 20% drag on too long. You need to ship. Create a burn-down list. A list of all the things required to ship. Sort by priority and work your way down the list.
Give yourself a ship-date
A game can be polished for ever, features can continue to creep but as time progresses your chance of shipping drops. Give yourself a deadline.
It's ok to change this deadline as it approaches but in theory, this is your release date, this is when you release it into the world.
A deadline has the advantage of capping the time remaining and allowing you to work on what's most important.
Accept imperfection
Here's a horrible secret of the game industry; games always have bugs. And here's a even worse secret; games are always released with known bugs. Bugs are categorised as Must-Fix at the top end and all other bugs are negotiable. There is no bug-free game. There's barely any bug-free software. It's a truth that's hard to accept but it is a truth.
Graphical glitches, sounds not always firing and other minor bugs such as these are not ship-stoppers. Better to release something less than perfect than never release at all.
Release
Congratulations, you've made it to release!
Release sounds like the end but that's not the case. Release your game into the world and prepare for a wave of responses. People giving you their impressions, people finding bugs, people asking for features or additional support. This can be hard to manage, so take your time.
Post-release you will probably end up patching your game and providing support.
That's it: Go Start
You can't finish if you don't start. Don't put if off, if you want it then block out the time and start! I'm rooting for you.