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
I think the last part ‘trust your gut and finish what you started’ is very true, and in most lines of work, not just game development.
My question is – in the world of AAA games – where marketing needs to have some crazy new tech or gameplay innovation to hype during pre-release, and where being the shiniest and loudest game at E3 translates directly into big $$$, how do you know when to stop prototyping?
Isn’t getting to the prototyping stage just as big a hurdle as populating the game with content when you don’t know exactly how to build something because your game is so cutting-edge? So then wouldn’t a schedule be needed to say ‘if we can’t do x,y and z by DEADLINE then the game mechanics are simply going to make use of x and y’… and now start making the game.
I also wonder if some companies (Valve, Bioware) have so much on the line with their reputations that this is why they are prepared to spend 5-6 years to release a title?
To answer your second question first, sometimes it has to be examined whether the company is actually spending 5+ years to make a quality game or are they simply spending 5+ years due to fiddling with things, bad decisions and sometimes even mismanagement.
As for the prototyping stage being important… I agree. But the time required to ‘prove the concept’ really depends on the scope and number of new features. Most games resemble other games (for bad or good) in many ways. Not every feature in the new game will be unique. Focus on the new stuff in the prototype. If the game is an entirely new concept, or the studio brand new with little experience, then certainly the prototyping time will be longer.
Where project’s fail, I think, is when they go ahead on content they don’t need to start yet to meet a schedule that *everyone* knows is going to fail… but they feel the need to pretend like it will succeed… maybe some of the participants even think it might succeed. So one group or another effectively wastes time and effort, throws their work out and starts again once the next tech hurdle is reached. Sadly, this happens in all types of industries, but I think it can be avoided or minimized in the gaming industry.
The problem with starting full bore development and still having ‘big features unproven’ is that those missing features could force changes to content already produced, causing huge delays. Imagine if ‘jumping’ was a feature that was added late into a game… the implications to design and art once this feature is implemented would be huge. But this kind of late-in-the-day stuff always happens and sadly in my experience the crammed in features on the titles I’ve worked in have often proven not to be that popular/successful.
As for marketing, I’ve found most capable marketing departments can find an angle to hype anything. It all comes down to how much money is available. That said, I think it is beneficial for new projects to at least have some marketing mind share at the beginning so that the developers understand what marketing expects, what excites marketing. A good designer won’t simply do what marketing tells them, but instead they should try and understand how get marketing excited in the project. Once marketing is excited, the project will gain more internal support.
And I think most marketing departments would be happy with faster product turnaround, which would allow them to examine the sales data and have more concrete “we should improve this/do this next” types of analysis.