TOM FRANCIS
REGRETS THIS ALREADY

I’d never made a game before, and all I really knew when I thought about making one was that I’d like to fling myself around the screen by clicking with the mouse. This was just going to be a little test project, so my only ambition was to make it feel good. Traditional platformer jumping, where you’re launched upwards with a button press and then move left and right mid-air, doesn’t feel good to me. It doesn’t fit with my intuitive understanding of physics, so I don’t feel it. So all I wanted to do was make a jumping mechanic that felt physically right, even if it was super-human and crazy.

Originally the game was going to be about a robot in space who could climb on ceilings, crush people’s heads with his metal claws, or drop fridges on people. That was just a random first idea, and quickly started to feel arbitrary and vague. I was more excited about some kind of detective story, so I made him a robot pretending to be a PI. At some point I realised there was no longer any reason for him to be secretly a robot, and it was making it hard to come up with reasons why he would care about any of his clients’ troubles, so I made him a human with improbable gadgets.

As soon as it became a private eye game, I started writing reams of script for scenes where you meet with clients, dozens of separate storylines about cheating husbands and double agents. Almost all of it turned out to clash with the tone and structure of the game as that came together, and in the end I scrapped all of it except the opening:

“Rainy street, short pause. A man in a trenchcoat comes crashing out of a plate glass window, slams into the building opposite, and falls to the ground.”

I couldn’t afford to waste that kind of time again, so I stopped writing any story until almost all of the rest of the game was in place, two years into its three-year development.

About three months in, once I had both super-jumping and a real-world setting, I added armed guards and the ability to pounce on them. I let you pin them to the ground and click to punch them, and I saw no particular reason to force you to get off once you’d done so. The natural consequence is that you can punch them in the face as many times as you like. I laughed for about five minutes the first time I tested this, and from that point on the game was always fun to play.

The real-world setting immediately had me imagining a game that was more about infiltration than platformer-style obstacle courses. The idea of a simpler 2D Deus Ex was hugely exciting to me, and I particularly love hacking that game’s security systems to work for me. I tried to think of the simplest, most flexible way to do this, and wondered about every electronic device having ‘inputs’ and ‘outputs’. I enjoyed tinkering with that stuff in level editors for Blood and Quake. What if the player could decide how every functional thing is hooked up?

The idea for the interface for that was just the simplest version I could think of: switch to hacking mode, drag a line from any device to any other. I implemented it exactly as I imagined it, it worked exactly as I imagined it, and it never changed or broke or needed rethinking. Testers loved it, the video I made of it got popular, and the whole game started to form around it, to become more of a creative puzzle game. It started to feel like an actual game, rather than just a test project.

I used Game Maker 8.0. My only previous programming experience was a brief course in Visual Basic in school, which I’d forgotten. Game Maker was very easy to learn using the built-in tutorial and help files, plus Derek Yu’s tutorial. I started by using the drag-and-drop interface, then slowly eased into writing code as I wanted to do more complex stuff.

These days Game Maker Studio is a much better option: supports Mac and Linux, Steamworks, fewer compatibility problems, games run much faster, version control. I’ve since made a video tutorial series on how to make a game in the free version of Game Maker Studio, aimed at people with no experience.

That said, I don’t plan to work with pixel art again. It’s too difficult to get it to look right on the insane range of possible resolutions a PC gamer might be using, because you can’t smoothly resize it without ruining the look. Gunpoint doesn’t scale it at all, so high res screens see more of the level. That makes things hard to see on high res monitors and getting an overview is difficult on lower res ones.

I was working a full time job while I made Gunpoint, so I only worked on it at weekends. I didn’t work on it on weekday evenings – I thought that would burn me out – and I also stopped doing any overtime or freelance work for my day job.

I didn’t work on it if I really didn’t feel like it, and I stopped if I got frustrated. I didn’t cancel any social plans I really wanted to go to, and I never cancelled any family plans for it. In the first year I estimated I worked on it about one weekend a month, and I once forgot about it for two months.

As it came together in the second year, I got more excited about it and worked on it more consistently. I learned to stop judging myself by whether I finished what I expected to in a weekend, and only ask myself two questions:

1. Did I work efficiently?
2. If not, what can I change for next time?

If I only finished 10% of what I expected to, that’s fine. Time estimates are wild guesses. But if I spent the weekend on something I later realised wasn’t important, I had to change my process. I couldn’t afford that kind of waste.

In the third year, I started working on it more intensively from my own desire to get it finished. At one point late that year, it looked like I had almost a year’s worth of work still to do. I couldn’t face that, so I cut all but one of the game’s planned scripted scenes, a few planned features I thought were essential at the time, and booked a three-month sabbatical from my day job to get it finished. I released it two months later.

I write every idea into a Google Doc before I try making it. Often writing it down lets you see an obvious problem or unwanted consequence of it. I’m a slow and bad programmer, so I couldn’t afford to waste time implementing things that didn’t work for design reasons. The only things I coded that didn’t work in practice were a few gadgets that didn’t take long to implement.

When I’m weighing up a few possible ways to design something, I write out each option and put the pros and cons underneath them, and have a little argument with myself.

    – This would be a potential problem with this approach.

        + This would be a possible solution to that problem

    + This would be an advantage of this approach.

Usually by the time I’ve written that out for each option, it’s obvious which one I should do.

The document is very fluid and I check it and change it every time I come back to Gunpoint. I also try to keep it in priority order, so the top thing on there is the thing I am most sure will have the biggest positive impact on the overall game, or an absolutely necessary pre-requisite to that. Things I’ve already done go green and move to the bottom. I question and tweak the ordering of the outstanding stuff every time I look at it.

The design doc only specifies what I want to achieve, so once I start up Game Maker I have to think a bit about how I’m going to approach it. I enjoy this part. There are a million ways to do anything, so it becomes a question of which interlocking systems would feel clean, efficient and logical, which is very similar to how I think about game design too.

The style I settled on was to call very descriptive and readable functions I haven’t written yet. So:

if !MusicIsPlaying(oMusic.TrackName) {

    UnloadAllCurrentMusic()

    LoadMusicFromFile(oMusic.FileName)

    PlayMusic(oMusic.TrackName)

}

Then I go and write those individual functions to do what their name says they do.

That example is nonsense, but you get the idea. For me it’s more important that I can read what I’ve written than doing it with the fewest functions or lines of code. It also helps me keep track of whether the structure makes sense when it’s all written out explicitly like that. And it breaks a big problem up into lots of smaller, simpler, solvable problems, which makes it less daunting and more satisfying to work on.

I started external testing as soon as I had jumping and climbing working, less than a month in. I asked for testers on my blog, and 8 people signed up. That grew steadily, then leapt when videos of the game started getting attention, ending with a mailing list of 15,500 testers by the final beta.

I e-mailed a new version to testers every few months, for three years. Later builds went to between 1,000 and 2,000 people each, and I mostly excluded those people from future tests. I used MailChimp to manage this mailing list.

Less than 10% of testers gave me any feedback, and almost every test version was leaked to torrent sites. My guess is that this only helped promote the game – I made sure each version clearly stated it was a prototype, and pointed people to the official site. Several pirates e-mailed me to say how much they loved the game and said they’d buy it on release.

The only major in-person testing I did was at the IGF Pavilion when we were nominated. We had to show the game there for three days, so I took thousands of words of notes on how people were playing and what tripped them up.

My conclusion was that large-scale external testing is best for identifying which problems are most important to solve, and in-person testing is best for figuring out how to solve them. When you see someone have a bad experience, it’s usually clear what change would have helped them avoid it.

Once the numbers got big, I set up a Google Docs Form (an online questionaire) to process their feedback, asking things like “What is most limiting your enjoyment right now?” and “Which were the best/worst levels?”

The answers to these questions come out in a spreadsheet, so it was easy to tally up which levels were working and which weren’t. After most tests I scrapped or completely reworked the two or three least popular levels, and tried to learn from what people liked about the best ones.

I also asked testers to score the game out of 10, and it was satisfying to see the average of this jump by at least 0.5 points with each version.

I ignored any feedback I disagreed with. The types of feedback I acted on were complaints that I’d also worried about, or things I couldn’t judge myself, like intuitiveness. Everything I changed due to feedback resulted in the game being more enjoyable for me too.

This Penny Arcade strip accurately reflects the emotional experience of processing feedback.

Once we had an almost gameplay-complete build in 2012, I took a few days to hammer out the plot and how it tied to these 20 missions. It was trickier than I realised to design a good plot that required you to break into 20 buildings one after the other, without getting repetitive.

It ended up as three storylines, but rather than keeping them separate, I kept seeing natural ways to intertwine them and have them all stem from the same inciting event. I removed about 5 separate twists, revolving around characters turning out to be dead, evil, imaginary, AI, the same, etc. They all felt clangingly dumb, and I started to realise plot can still be surprising without trying to trick you into a false expectation.

Once the plot made sense, writing the script itself was easier. It probably took 10-20 hours – spread out over a lot of bus rides, plane journeys, and gaps between other jobs – and came in at around 10,000 words.

The story and dialogue are the only parts of the game that only went through one round of testing. People liked the dialogue much more than expected, but a lot of people found the plot hard to follow. I clarified a few lines, but to really fix that would have taken a total rewrite I didn’t have the time or motivation for. I’d always built the game to work even if you didn’t care about the plot, so I didn’t worry about it not being everyone’s cup of tea.

The first video I made of Gunpoint had my terrible programmer art. I was only really showing off the concept, but I asked in the video if anyone wanted to help with the art. If they did, I asked them to send in a sample of what they would do for Gunpoint – a character and some environment stuff.

Gunpoint was going to be free at this point, so I couldn’t promise any money. But on the concept alone, we got 34 artists who created samples and sent them in. That left me completely spoiled for choice, so I was able to pick two people perfect for the job: John Roberts for characters and levels, Fabian van Dommelen for backgrounds.

Once their art was in, I made a new trailer to show it off, and asked if anyone wanted to provide music. If they did, I asked them to try scoring that trailer. Again, I was spoilt for choice, and again, I couldn’t pick just one: Ryan Ike for the main mission music, John Robert Matz for the theme, and Francisco Cerda for the menu music.

Letting anyone in the world submit a sample of what they’d do for Gunpoint meant we got a huge selection of talent despite not being able to guarantee pay at that point. It also meant I could pick the best people for this specific game, not just the ones with the best resumés. That was especially helpful given that we ended up with a team scattered all over the world. We only communicated by e-mail, but everyone was already in sync artistically, everyone already knew exactly what the game was, and everyone was perfectly suited to it – so not much back-and-forth was needed.

When we did decide to sell Gunpoint, we agreed to split the revenue according to the size of each of our contributions. Since it was very successful, that’s meant our artists and composers will get paid far more than they would have under a salary or commission basis.

I blogged about the development of Gunpoint from the first weekend I started working on it, all the way through its three year development. I didn’t try to stick to any regular schedule, I only wrote posts when I had something to say: usually something I’d learned about game development, or some design thing I wanted to discuss. You can still read the blog from the very start.

I did this mainly for fun, and to keep myself motivated, but I think it probably helped those who were interested in the game keep tabs on it, and not forget it existed. Almost nobody cared early on, but after each video I released the number of regular readers and commenters jumped.

Once I had the Crosslink hacking method working, and a few puzzles to show it off, I made a video of me playing the game and talking over it to explain what was going on. It wasn’t slick or commercial, but it did explain how the game worked and what was different about it. And it got an unexpectedly great response, even getting covered by some major gaming sites. It’s got about 50,000 views now.

That was enough to get me some great artists, and their art was enough to make the next video gorgeous. Combined with the concept I already knew people liked, it went crazy. Almost every big gaming site posted about it. It’s up to 420,000 views now.

That video’s responsible for almost all the subsequent coverage it got, including being featured by big YouTubers and press. It’s also responsible for our first 7,000 Twitter followers, our 15,000 testers, and 1,000 comments on our blog telling us to sell the game instead of releasing it for free. And again, it’s not a trailer: it’s long, badly produced and nerdy. But again, it explains the game as clearly and thoroughly as I can.

Shortly after I released that second video in November 2011, Valve got in touch to offer us Steam distribution. This was before Greenlight existed. If we were in the same situation today, we’d still have got through when we were named an IGF Finalist. Humble Bundle also offered us distribution through the Humble Store widget, which we took them up on.

I contacted the press three or four times during Gunpoint’s development, when there was something I particularly wanted to promote. Things I did right:

• Included YouTubers as particularly important members of the press.
• E-mailed individual people at the sites, rather than their generic address.
• Wrote an e-mail, not a press release. Nothing is less interesting to the press than a press release.
• Explained the game and its newsworthiness in the subject line – eg. “New trailer for Gunpoint, an IGF-nominated stealth game about rewiring things and punching people”
• Always put a YouTube link in the first few paragraphs. Busy people get more info faster from video.
• Included at least one free copy in every e-mail, loads later on. Making a journalist or YouTuber ask you for a copy reduces the chances of them playing it by around 99%.

Things I won’t do again:

• Wrote a different e-mail to every publication. This took ages. I knew different journos had different levels of familiarity with Gunpoint, and didn’t want to patronise the ones who already knew what it was. On reflection, though, that never bothered me as a journalist.
• When YouTubers didn’t have an e-mail address, contacted them through YouTube or Facebook. I now realise these are the two least-checked inboxes, I should have messaged them on Twitter instead.
• Put a lot of effort into giving out preview code. Wrote to 25 outlets in the last preview mailout, 10 said they’d cover it, only 2 did. I don’t think previews even help that much, I’ll just do more trailers next time.
• Sent all the free copies for each publication to the one person there who I knew liked Gunpoint. I wanted as many press playing it as possible, and figured the other staff would be more likely to pay attention if they got the code from their colleague. In practice, many of these people missed the e-mail or never got around to forwarding them, and I shouldn’t have been asking them to do my work for me anyway. Next time I’ll mail everyone, and probably give them a few codes each.
• Didn’t dictate a review embargo at first. I didn’t want to seem self-important, but Oli Welsh at Eurogamer suggested it might be better for me if reviews went up when the game was available to buy. I expect he is significantly right. From then on I asked people to do this if they wanted to help me out, and they all did.