Building a Shed

So my wife and I built a shed on the weekend. It was a precut package, so on the surface it seemed relatively simple, just a bit of hammering and whatnot, but we needed it in between the garage and the fence, so some customization was required to make it fit into such a small space.

I spent an hour or so sorting all the pieces, getting my tools prepared. My wife made a couple sketches on the instructions to account for the changes we needed (moving the doors from the sides to the ends, et cetera).

And then we built it. It took some doing, I made a few mistakes and had to make some changes to adjust. But we pushed through and finished most of it over a day and a half. And that’s with two toddlers underfoot.

Could we have avoided some of the mistakes had we spent more time prepping and discussing things? Possibly. Would the shed be a bit cooler with a window? Sure. Maybe we could have discussed the shed with the neighbors so they weren’t surprised when my wife dropped a bucket of nails into their yard. Yep, could’ve done that.

But we never would have finished the shed over the weekend.

This post, of course, has nothing to do with building a shed. See, building this shed reminded me of the way I think videogames should be made. An approach that has worked for me in the past, and one that when it hasn’t been followed has seen game development fail with extreme cost overrun.

See there are a couple approaches you can take — one involves spending years constantly changing vision; making dozens of schedules, asset lists, design documents to account for the changing team and requirements; ballooning the team size unnecessarily early and then being unable to grow it when required. It involves consultation, days full of discussion, a constantly transforming design. And maybe at the end you do create something, it might be inconsistently designed, awkward, and expensive but it’s finished.

Alternatively the approach I prefer is to do a reasonable amount of preparation and spend an equally reasonable amount of time prototyping — deciding exactly what the final look of the game needs to be, the writing quality, the pace, the types of action, the player types supported. All of it.

You don’t make a schedule while prototyping. You don’t make promises while prototyping. And you don’t leave the prototyping phase until every department can begin making production/shippable quality content. Every department. They need their tools, their pipelines, all of it working properly.

If the artists and programmers tell you that they are in production and the designers tell you that they are still prototyping then you are not making a game. You’re wasting time and money. It gets worse when all the departments think they are all in production, but some are not. Trust me, that’s fun.

And when you are finished prototyping, you make a schedule, and then you make the game.

Of course you make adjustments, based on what the people playing the game suggest (not people sitting in offices, spending too much time thinking). But the game you make is inherently the game you started out making, the one everyone agreed to. And this game gets done in a year or two. It doesn’t languish through a half-decade or longer.

And maybe the game isn’t perfect. But if it gets finished in half the time it would have if you had used the first approach, go make a sequel! Make two games in the time it might have taken you to build one! That might seem impossible, but it isn’t. Because once you get that first game down and you build a sequel without changing your engine or development pipeline too much, it goes fast. Really fast.

The longer a game takes to make, the harder it is to finish it. Sometimes, in my opinion, it is a hell of a lot better just to trust your gut, finish what you started and do better next time.

“Building a Shed” copyright 2009 by Brent Knowles