GUNPOINT

How I Am Working

Gunpoint is going amazingly well. I’ve been splitting what’s left to do into little monthly task lists, and I’ve already finished everything I had down for March. I started making the game in May last year, and said I didn’t want it to take more than a year. So my aim is to release it this May. Expect it in July.

I typically only work on it about one weekend a month, and I forgot about it completely for two months last year. The two days I spent on it during the holidays shot it forwards to a really exciting point, and the feedback from testers on that version was amazing. So lately I’ve been spending about a third of my spare time on it – what we in the lazy industry call ‘crunch’.

Things are going so quickly partly because I’m excited, but mostly because I’ve figured out a good way to work. Some of it is obvious stuff that you know but don’t actually do until you learn it the hard way, some of it is specific to making a game, some of it is just generally useful. Here’s what I’d tell the Tom of May 2010 about getting shit done.

• I am from the future. Your local lib dem MP will turn out to be a supervillian, but there isn’t really anything you can do about it.
• Staying excited about a thing is a question of having a really attractive and friendly to-do list. Use bullet-points and shit. Put spaces between clusters of things that it’d be easier to do together, and split them into “This month”, “Next month”, and “Final features”. Five or six things in each, don’t make it scary.

  This thing is the focal point of everything you do on the project, and how it makes you feel is usually the deciding factor in whether you work on it or watch another episode of Downton Abbey. Downton Abbey is fucking superb, but there’s only like seven episodes so you really have to pace yourself.

• Nothing is hard to do. If something seems hard, give up. You’ll come back in two days and solve it with three lines of code.
• Some things are hard to fix, and fixing isn’t fun. If you don’t fix something immediately, give up. Move back to diagnosing the problem better by setting up little bits of debug text and disabling chunks of code. Almost every hard problem is solved by a tiny and easily attainable piece of knowledge.
• Don’t write. Every word of fiction you type before making the game is a poison that will warp and deform it in ways that have nothing to do with fun. Make the game, see what’s fun, zero in on that, then write only what it needs to tie it together.
• Don’t tweak. Get something working, then move on to getting the next thing working. Instead of spending three hours now fine tuning a few values, you’ll be playing a better game three hours later and suddenly know how that thing should look, feel and fit in. Or better yet, testers will complain about it in useful ways.
• Talk about it. It’s worth the risk of boring your friends. I was planning to cut the ‘gunpoint’ mechanic from my game ‘Gunpoint’, until I explained my thought process to Graham. He said I should do the hardest version of the options I’d planned, I looked at it again, and realised it easy. Three lines of code.
• Work towards a build, not the finished thing. Having a working build you wouldn’t dream of releasing is massively more useful than having nonfunctioning tatters of a game you probably would. Making Scanno Domini in a weekend taught me how finishing what you can often shows you that some of the other stuff you had planned isn’t necessary anyway.
• When you’re done with something big, or well ahead, it is time for scotch, rain and smooth jazz. Sometimes it is that time anyway.

More Gunpoint