5. Not Taking Advantage Of Placeholders

Placeholder assets and code are used a lot in this industry, yet placeholder use often greatly diminishes once production starts. It is understandable. If a developer is working for a publisher, it's very important to show progress. Going from a nice shiny vertical slice to builds filled with jerky animations and flat-shaded backgrounds can look like a step backward.

Internally, team members, particularly artists and animators, generally prefer working on final assets than low-quality ones that will have to be replaced later. Producers generally prefer something done once rather than twice. Unfortunately under-use of placeholders reduces final game quality and slows down the design process.

The basic scenario goes like this: a designer wants to see an asset in game -- be it a 3D model, an animation, a gameplay mechanic, etc. Rather than wait a few hours for a placeholder, he must wait a week for the finished asset. If what he receives isn't as fun as he had imagined, that will be a week of work wasted.

To avoid this from happening, long approval processes are often implemented with the intention of weeding out all but the best ideas. In practice the approval process can shear off all but the least risky elements of the idea until it's lost its originality.

So now instead of trying out an idea with a placeholder and moving on, the designer must wait a week to receive a final asset that is often far less interesting than what he would have discovered through experimentation with placeholders.

Working without placeholders wastes time in many ways. Levels made up of hundreds of 3D meshes take longer to load and test than those that are made of simple BSPs. They take much longer to modify because they're made of 100's of pieces instead of a few simple shapes.

Finally less experienced mission designers will waste time showing off their interior decoration and lighting skills when they should be focusing on making fun gameplay. Some flat-shaded textures, a pool of placeholder 3D objects, and a watchful eye of an artist to make sure things are architecturally sound should be all a mission designer needs to make fun environments.

A placeholder-heavy game design process requires a lot from a lot of people. It requires a studio that can shuffle artists to other duties while the design team settles on what they want for the "final" level.

It requires faith that the higher-ups (be they an external publisher or an internal studio head) are not as superficial and can appreciate the value of a fun, if ugly, level filled with placeholders. If you don't have this faith, outside playtesting can be used to quantify the "fun" in lieu of showing polished graphics.

6. Allowing The Story To Control The Game Design

In television and film a writer writes a script and hands it off to a producer. The crew then uses the script as a map for telling a story to the viewer. This process can work for video games so long as the main purpose of the game is to tell a story to the player.

Games such as those in the Final Fantasy series as well as many JRPGs and adventure games can succeed on a great story alone. If the main purpose of your game is put your player into the middle of a highly interactive experience, than this method is inappropriate.

If your game is Halo, Call of Duty, or God of War, the script should be shaped around the gameplay and not the other way around. Things such as level design, play mechanics, and pacing are the most important factors. If these things aren't solid, no amount of storytelling can pick up the slack. This is not to say story isn't important, but rather the writer should be flexible enough to change the story based on what presents the player with the most compelling interactive experience.

Giving the story priority over other elements of game design can lead to trouble. A classic example is the 2003 title Enter the Matrix.

The plot of the game and its live-action cutscenes were made to weave in and out of the movie The Matrix Reloaded; the movie's creators were heavily involved.

The result was levels that made sense from a story perspective but had no purpose from a gameplay one. Furthermore the dev team was stretched thin creating three different game types -- in car, on foot, and in hovercraft -- because the story demanded it.

I once worked on a third-person action project with a script that was handed down to us by a Hollywood writer. While an interesting story, it conflicted with a lot of the gameplay elements that had been designed. The script called for levels in intimate locations with a handful of enemies when the game mechanics were set up for huge firefights large cover-filled locations.

The game had been designed with a partner in mind that the player could give orders to, but the script demanded that the player should be alone for a large part of the game's second half -- destroying the learning curve. The cancellation of the project was largely due to the design team being forced to follow the Hollywood script.

The story of an action game should be the responsibility of a game writer. A game writer is someone who's written for games before or at least is a gamer himself. A game writer will be with the team full time and understand why his story needs to be reworked continually.

He won't get flustered if the design team decides the airport level makes more sense in the beginning of the game rather than in the end. Writing for games is not the same as writing for films. Simply cutting a Hollywood man a check to deliver a script is not the way to go.