Time bandits making your game project take longer than it should

Let's be real. Making a video game takes time, and lots and lots and lots of time. So it only makes sense to not waste any.

But how can time be wasted on a project like a video game? There are many ways, but here are a few:

  • Feature creep
  • Obsession with clean code
  • Unnecessary polish

I'm not going to talk about feature creep in this article. That is the most common time bandit that you read about. Google will give you pages and pages of articles on it I'm sure.

Instead, I'll write about some less known ones that I've encounter often. These others can sneak into your project and suck your time away like a black hole. They make you to wonder, after years of working on a game project, "why is this not done yet?" Let's take a minute to understand these time bandits so we can stomp them out before they become a problem.

Obsession with clean code

Clean code is precious. It's beautiful. Where spaghetti code gives you lemons, clean code gives you lemonade.

I'm a vigilant supporter of writing clean code. I'm always up for reading a good article on how to improve code quality. But this takes time. It's definitely worth your time, but code can always be improved. There is no end to making clean code cleaner. At some point, it's good enough and you should move on. As long as its not an unholy mess, take a moment to decide whether it's something that needs your attention now, later, or at all for that matter. Keep in mind that your end goal is to finish a game, not to submit your code to some organization to win awards for code perfection.

Unnecessary polish

You may get new ideas during development. Some ideas don't work, so you scrap them. But if you've spent hours-on-end polishing a facet of your game that you toss out in the middle of development, then you've just tossed out all that time with it.

Polish is attention to detail, taking the time to fix and improve all the minor imperfections. This separates the lackluster "maybe I'll check it out if I have the time" games from games that demand your attention. Polished games feel professional, look sick, and speak for themselves.

I encourage every game developer to invest as much time as they can to polish their game to perfection. However, there's a time for this. It's *not* during the first two-thirds of core development. That time should be spent working on content and fleshing out your game. Once your game is complete, start-to-finish, then take the time to polish it and make things shine. Otherwise, you're touching up a painting where half the canvas is blank.

Let's be fair. You want your game to look good, sound good, and be an overall good experience while you're working on it. It's no fun to work with crappy graphics and sound, for example. And why work on a project that's no fun?

You're game should look good during development. This gives you inspiration to keep moving forward. But only keep it good, not stellar. Save that for later.

Bringing it all around

This wasn't a big list of items, but I've noticed these on my own as contenders to feature creep in terms of how much time they waste. If you have experienced any other time bandits, feel free to share.

Moved to a new place

I just spent the last fews weeks moving to a new place. But that's all done now, except for a couple unpacked boxes. Now I have time to finish working on Toadman 3.

Here I am, three months into the new year. Will Toadman 3 ever be finished? It seems close, but time keeps ticking away. What needs to be done? For starters, there's an issue list on Github that I need to complete. I have added issues to the list as I found ( or though about ) them. Besides that, it's mostly just content. The game gets somewhat boring after three levels. I need to find ways to keep it interesting. Once I have enough widgets and bad guys, extra levels should come easy. By "widgets" I mean things that the player can interact with, like keys/doors, items to pickup and use, ways to explore the map ( like teleporters ), etc. Without these, the levels are just boring mazes. I have a few widgets, but I should add many more.

How long will all this take? I can probably clear the issue list by next month, and have enough extra content in another two months. Ugh. I wish it could be sooner. That's also a gracious estimate, assuming just a few hours a week. Maybe I'll pull a couple all-nighters.

Some stats

Toadman 3

22 source files
3,989 lines of code
144 commits (since July)

Not including level editor

21 source files
3,442 lines of code

Have you seen the graph feature on Github? Since I'm hosting my project there, I can see some cool graphs of my activity. I have six months of project activity I can look at.


The punch card says I'm most productive on Saturday and Sunday. Hmm...go figure.

Three good project habits

Today, I'd like to share some habits I use for software development. These are version control, logs, and bug tracking.

Version Control

If you haven't started using this, now is a good time. What is version control? It's basically a backup program. Instead of having backup files and folders -- if that's been your backup system -- version control takes a snapshot of your project with every change you make. Every snapshot is a version of your project in development, and you can go back to it at anytime.

I used to backup my projects with zip archives (backup-2012-01-01.zip, for example). This is better than nothing, but frustrating. If I went of the rails on some new feature and need to roll back, it might be to a backup a week or month ago -- whenever I saved it last. It's too much work to back it up every day, let alone for every change this way. It can be demotivating to work back to where you were from when you last backed up (which could have been days, weeks, or longer). But with version control, every change is recorded, so I don't run into this problem -- or if I do it is just a couple changes needed to get back to where I was.

I use Git. If you develop on Windows, then Mercurial is a good alternative. SVN is okay, but Git and Mercurial are much better. This article isn't a tutorial on version control. You're on your own here, but there are great articles on the web. Just Google them.

Keep a Log

Keep a log of your project. I don't mean some boring summary every day. Whenever you make a change, just note it. This makes it easy to get back up to speed in case you left your project for longer than a week. You can look back at what you did without struggling to remember.

Version control programs let you take notes with each commit (version, snapshot, etc.). I use this feature in Git to keep notes on the changes I make. Sometimes it's just a one-line summary, other times a couple paragraphs. Writing something someone else would understand is a good rule.

Here's an example of some notes for Toadman 3:

commit 561f32bd9b5ad211055b53d08e68a87e9d066b94
Author: Joe King
Date:   Sun Nov 18 12:09:53 2012 -0700

    Add title background
    This will be used for the game menu.

commit 44b1af17d755e8f9d0630e5f6ce31ae7c4b7404d
Author: Joe King
Date:   Sun Nov 11 20:46:42 2012 -0700

    Add font module
    I consolidated the font rendering responsibilities into this module.
    I also added a text centering method.

commit b840795611af50f19dc6c350f70f2ed1e8a28107
Author: Joe King
Date:   Thu Nov 1 23:01:26 2012 -0600

    Fire puffs of smoke when tree is destroyed
    It looks cool and gives a more rewarding feel to the destruction.

commit 1705174faa5288f44fb6c83fa48b5f0d9e3a8a28
Author: Joe King
Date:   Thu Nov 1 22:58:22 2012 -0600

    Give ice-brick graphics winter theme
    For the ice-brick levels, I updated the tiles to reflect a more winter
    type of theme.

Keep track of your bugs!

Write down every bug you encounter. These are easy to forget. Yes, you don't completely forget all of them. But it's easy to release a demo with some bug you meant to fix, sometimes finding that no one could get passed level one because of it.

Not only this, but I bet you'll record more bugs than you thought you had. You can only juggle so many bugs in your head at a time; it's easy for the not-so-annoying ones to slip under the rug. Once you clear your head of the bugs that are currently bothering you (by writing them down), you're able to spot more bugs. These might have been bugs you spotted before, but subconsciously ignored because of more pressing bugs.

Once you have them all written down (or as many as you can), you now have a list of bugs you should fix before releasing your game. Or you could at least prioritize them and take care of the ones that are worth fixing.

Basic Gaming Issue #9

I wrote an article for Basic Gaming. It's about making code organized and reusable. Exciting, I know!

Checkout the latest issue, or go straight to my article here.

Toadman 3 is on Facebook!

Have a Facebook account? Good! Then "like" the Toadman 3 page to get awesome updates in your news feed: