How to Finish a Game

I posted a tweet yesterday which offered some advice concerning finishing games:

How to finish a game: get part way through a project, get an awesome idea for another game, ignore it and finish the one you’re working on.

It ended up getting retweeted quite a few times, so I guess it kind of struck a chord with people. With that in mind I got to thinking about other barriers to completing games I’ve encountered over the years and figured it would make a good blog post.

Having tried to start this whole game development thing once before in the late 90’s, I’ve done quite a few things that have derailed me from actually completing a game. When I started again in 2009, I knew I had to avoid all of these pitfalls in order to actually get a game out the door, so that was my biggest priority, actually finishing a game. I’ve finished 2 games since then, and I’m on my way to completing my 3rd, so hopefully this advice may prove useful to you as well.

Limit your Scope

Quake is awesome! I know I’ll make a first person shooter!

That would be me, shortly after playing Quake, getting ready to embark on one of a series of unfinished game projects. At the time, instead of trying to make a game I could finish at my then current skill level I shot for the moon and, unsurprisingly, didn’t make it very far. I learned a lot of important skills, but I failed miserably at actually making any games.

That said, the first thing you need to do before you even start a game is at least plan what kind of game you want to create. The most important part of this planning step, as hinted at above, is to understand your limits as a developer or a team and make sure you pick a project that you can complete in a reasonable time-frame.

What’s a reasonable time-frame? For some people that might be six months, for others it could be a year, and for others still it could be two years or more. The point is: don’t bite off more than you can chew. You might learn a lot doing it, but if you’re seriously trying to make games all you’re going to do is waste your or your team’s time that could be better spent actually working on a game you can complete.

I’m not rightfully sure that you can really understand your limit unless you run into it a few times, leaving a few unfinished games in your wake, but at least be aware of it so you can begin to get comfortable with setting goals and making games.

Avoid the Creep

The evil twin of our friend Scope above, is Scope Creep. What is Scope Creep? It’s when you start working on your project and that little voice in your head goes “Wouldn’t it be cool if…” and then you’ve got something else to add to your game. If this keeps happening, you may end up spending way more time working on your game than you expected.

Sure, it might be cool, but before you start adding things to the original plan make sure you understand the implications. If it’s not absolutely necessary consider adding it to a list of things you can add after the game is released. In this day and age of digital distribution and patching there’s no reason why you can’t keep adding cool stuff to your game after it’s out. It’s not like people don’t enjoy getting new things to play with.

Resist Temptation

As hinted at by the tweet that inspired this post, game designers are almost always thinking about making games. Combine this with the fact that certain aspects of making games are just not very much fun and you have a potential recipe for disaster. At some point, you’re going to get an idea for a really awesome game in your head, right in the middle of doing something else on the game you’re currently working on, and it’s going to be really tempting to start doing the interesting groundwork on the new game to distract you from the monotony of the current project.

It takes discipline, but the best thing you can do at this point is add the idea you just came up with to your list of future games you want to make and get right back to working on the game you set out to finish in the first place.

Don’t Re-invent the Wheel

It seems like the temptation to create your own middleware and tools is common among game developers. It’s a weird affliction in a way, as you don’t often see carpenters building their own table saws or, in keeping with the wheel analogy, car makers manufacturing tires. I understand the reasons one might want to do this, and sometimes they’re quite legitimate. Other times, it’s more of a case of the Not Invented Here syndrome, where people seemingly mistrust anything they didn’t create themselves in-house. Yes, creating your own rendering engine or 3D modelling software (both of which I myself am guilty of) is a great way to learn new things and be in complete control of your project, but my point is you’re trying to create a game not middleware or tools!

The important thing here is to keep in mind that a lot of common problems in game development have already been solved, and probably more completely and robustly than you ever could do yourself. Some of these solutions cost money, some are free, but understand that your time is valuable and it is better spent actually working on finishing your game. So always spend some time before tackling a difficult problem evaluating if adopting an available solution will end up bringing you closer to finishing your game or not.


This is by no means meant to be an exhaustive list of things to think about when trying to finish a game, but I hope it will be useful to those out there trying to get their games off the ground. As well, by all means, feel free to suggest additional things you’ve learned that help you finish your games in the comments below.

Update: I was just about to post this to /r/gamedev on Reddit when I noticed a link on the sidebar to a post called “Finishing a Game” by Derek “mossmouth” Yu. I had actually read it ages ago, and it’s a very good post and covers some of the same ground I’m covering here, except more in depth… and with better pictures and diagrams. So, when you’re done here, I’d highly recommend you check it out.