Call Me Back
 
 
 
Tom Sloper is a versatile and prolific game producer who has developed electronic entertainment, games and toys selling over 5.5 million units. Those products generated more than $176 million in sales ($37.7 million in profits). His expertise includes outstanding project management, training, communication, and design skills.  Tom has consulted for game developers, publishers, and educational institutions internationally; wrote articles for books and magazines; gave lectures; maintained website where free information is offered to game industry aspirants.  For more information please visit him on the web at Sloperama.com



The Importance of Design Docs in Game Development

  By Tom Sloper

tomsloper

     I've been a game designer and producer since the early 1980s. I've designed 20 shipped games and I've produced 88 shipped games. I count only the "shipped" games because I'd rather not talk about how many projects never got finished. Project cancellation is one of the disasters that can result from having a poorly written design doc, or no design doc at all.

     The team who creates the game needs a unified vision of what the final game is going to be; a plan they can refer to throughout the project. Think of a game design document (GDD) as being like a blueprint, or sheet music, or a map. A construction team who tries to erect a building without any blueprints is going to have a rough time. How big a hole should they dig for the foundation? How many materials need to be bought?  A band that tries to play music together, without any sheet music, will sound terrible. Each musician would be playing his own tune. An explorer who tries to enter unknown territory without a map may not wind up in the place he intended - or may encounter nasty obstacles along the way.

It's the same with making electronic games.

     A solid game design document can be used to generate a technical design, programming task list, art list, sound list, and voiceover script. Experienced personnel can use those lists to make a firm budget and schedule for the project. 

     Two projects in particular suffered greatly because of this lack.

     I produced a Super Nintendo Entertainment System game, "Alien vs. Predator," with a Japanese company. The deal was that the Japanese company would first program the game for release in the Japanese market. Then we would localize the game for release in the rest of the world. The Japanese company did not believe in game design documents. When I demanded one, all they gave me was a 3- or 4-page outline. Reading the outline gave very little information about what the game would be. At the time, fighting games were popular. So the Japanese company had decided to make a game about Predators punching it out with Aliens, occasionally finding weapon pickups along the way. It was a terrible idea, but I couldn't tell from reading the outline that that's what they had in mind. I read it as a weapon-based game, not a punching game. As a result of this lack of a design doc, the game was mediocre when it was finished. The licensor, Twentieth Century Fox, wouldn't approve the game for manufacture and distribution in North America. We had to make substantial changes to the game in order to obtain licensor approval, increasing the number of weapon pickups (and the number of aliens), making the game better utilize the licensed properties.

     A bigger disaster happened the time I was assigned to produce an Activision in-house Sega Genesis football game. I was producing numerous games at the time, and was never a football fan. So I could not write a design doc for the project myself. There was nobody else on staff to write one, either. The team believed that they could manage it with only a basic list of features, despite my belief that a design doc was vital. I was reassigned to Japan before this project had progressed very far; someone else took over its production. While I was safely on the other side of the ocean, the project crashed and burned horribly, after much money had been wasted. In the fallout over this failed project, several people left the company. This kind of catastrophic project failure is hard on everyone involved. The company lost a lot of money, and the project didn't add value to the resumes of the individuals who'd worked on it. This particular catastrophe could be blamed directly on the lack of a unifying GDD.

     When can you proceed without a GDD? When money is no object, and you have all the time in the world, and you’re working on a new original concept in untested territory (there is no licensed IP involved, and platform holder approval is not a worry). But how often do you have an unlimited budget? How often does the publisher not care how long it takes, or if it's done in time for Christmas? If you are on a budget and a deadline, or if the game is based on licensed property, or if the game is for a console requiring platform holder approval, you absolutely have to write a solid game design document.

     Give your team the blueprint it needs to build your dream game. Give them the sheet music they need to make beautiful music together. Map your team's journey, or you may never get where you want to go.




Copyright (c) 2007. The Corpament | Privacy Policy | Terms Of Use