9. Not Keeping Design Documentation Up-To-Date

How many times have you heard someone say, "Don't read those. They're not up-to-date"? If the answer is zero, you're either not in the games industry or you're very lucky. Out-of-date design documents are a common fixture in development teams.

It may seem like an unavoidable failing. Features almost never ship exactly as they were designed on paper. Rather they change many times after their original implementation. Keeping the documentation in step with the changes can be a real chore. Time-consuming as it may be, the consequences for not doing so are fairly serious.

When documentation is not kept up-to-date, people lose faith in it. They assume that whatever is in the source control isn't valid. They don't bother using it as a reference when they have a question.

Rather they will prefer to ask a member of the design team directly. Once the designers realize that their documentation isn't being read, they will put even less energy into maintaining it. Eventually the team will come to the clichéd conclusion that "design documents are worthless".

There are inherent problems with transmitting ideas through word of mouth. A designer may give a programmer a description of the feature that isn't exactly what was originally agreed upon.

The programmer will then implement that feature based on what he remembers of the designer's description. This will cause conflicts when the lead designer looks at an implemented feature that's different from what was discussed.

Another issue is that information becomes fragmented -- with only one or two people knowing how everything is supposed to work. I was four months into the production phase of a project when I needed a list of which levels were to be included in the game and their order.

The only method of getting this info was to email the design lead who then emailed me a spreadsheet from his desktop. The two level sequence documents in the source control were out of date.

Keeping design documents up to date isn't easy, but technology can help. I worked for a company that had a system for automatically giving a document an "out-of-date" tag if two weeks had passed since the document had last been modified. Out-of-date documents couldn't be opened until a designer marked them as current. It was a success, for the most part.

10. Not Making Outside Playtests Part Of The Process

More and more companies are realizing the value of making regular playtesting part of the design process. Valve, for example, is well known for the rigorous playtesting it used in the creation of Half-Life 2 and Portal. Ubisoft is also well known for placing a high priority on playtests.

Unfortunately this practice is not as widespread as it should be. A lot of developers see it as unimportant, and some as downright harmful. An experienced game designer should see playtests as one of the most valuable tools in his tool belt.

If the intended player is not within the traditional "hardcore" demographic -- casual gamers or children, for example -- then playtesting is indispensable. Attempting to see a game through the eyes of a casual player requires the designer to block out 15+ years of accumulated game-playing knowledge. In other words, it's impossible.

Even if you think you've made the most straightforward interface possible, you'll be amazed how much you take for granted the first time you hand the controller over to a 40 year old mother.

If you're making a children's game, then prepare for an even bigger adjustment -- a six year old will have trouble with anything more than the most straightforward concepts. Their brains just aren't developed enough to comprehend things we understand naturally.

Even if designing for a hardcore audience, playtesting is still incredibly important. Over the course of production every game designer will become a master of the game he's developing.

Things that would challenge a new player will become boring to the designer. He'll start to create setups that he can complete with a little bit of finesse but are way too hard to be included in the shipped game.

If the team doesn't start outside playtesting until beta, these bits will have to be smoothed over hastily. Often the result is a game whose changes in difficulty level doesn't seem to follow any plan.

If playtesting is part of the design process throughout, on the other hand, the design team can carefully craft an experience with a difficulty level that steadily climbs until the game's climax.

I've worked with designers that prefer not to do playtests during development because, they claim, relying too much on playtests during development is akin to making a movie through focus groups -- it will water down the artistic vision. This argument only considers a game's fun factor and ignores the comprehension side.

If the designer doesn't care if Billy thought the game was fun or not, don't ask him. If he can't get past the first level because he can't get his head around the dual analog stick aiming system, then we have a problem. And it's better to know that sooner than later.

Conclusion

If you work as a game designer, I imagine you've come across some, if not all, of these design process pitfalls. I've been in situations where the money was there and the talent was there, but the project still failed to come together because of bad design processes.

The most important thing to take away is that a lot of the important elements mentioned in this article, such as peer review and keeping documents up to date, do happen come naturally -- they require discipline and enforcement.

When the game development is being managed by individuals with the experience necessary to recognize and practice good design processes, there is the potential for truly amazing content to be created.