The game design document is not something you simply dash off over the weekend. Instead, it is a process that must be carried out over time by a team of game developers for a game of modern complexity and scope.
This is the classic step of imagining a game that you would love to create, a game so compelling that you wish you could play it yourself, right now! This is the sort of task you could accomplish over the weekend or just an evening. At Taldren this usually occurs late at night after some milestone has been accomplished through a non-trivial amount of blood and sweat, and we lie there in exhaustion and begin to have glimmerings of what we would love to create next. This magical process I cannot help you with; you either have it in you or one of your team members has this juice. The next step is to document the vision.
Write out just two or three pages that describe the game to your most intimate development team members. Don’t take the time to justify anything just write. After you have nailed the core idea and the excitement behind your game, gather your team into a conference room with a whiteboard and stacks and stacks of different colored Post-it notes. What, didn’t you know that Post-it notes stick well on whiteboards?
I have designed games by myself and with others. Games that are designed by committee are usually horribly muted game designs and games that are designed by solo individuals often contain spikes of “game design noise.” Think of all of the minds churning out game design thoughts as sound sources making sounds of all different shapes, intensities, and durations. And now think of the process of culling these design thoughts down into a design document. It’s easy to see each individual will bring his own bias, perspective, wishes, and agenda to the design. If you allow a solitary individual to make the game, you have the purest expression of art in a game, and the game will simply hit or miss upon this one person’s vision. The trouble with this approach is that games are now very large projects. The Interplay game Planescape had over one million words of dialogue; that is enough for ten novels! It takes an exceedingly talented, skilled, and hardworking designer to perform the design solo. On the other hand, think of a committee of designers where each member has the ability to censor an idea. This will act as a low-pass and high-pass filter allowing only the ideas that everyone may agree on to pass through. The result will be insipid, derivative games without any reason for being created.
The game design process requires a lead designer with a team of designers below contributing to the overall design. Let me show you how this would work in the initial brainstorm session:
Open the brainstorm meeting, having already passed out the game design document some 2 to 24 hours beforehand so that the game concept is fresh in everyone’s mind. Next, take your stack of colored Post-it notes and create a colored key of topics along one of the lower corners of the whiteboard. (By the way, did I tell you to get a large whiteboard? We have found a great deal at the local Home Depot hardware store: 4-foot by 8-foot whiteboards in the raw without a border or frame for $11! Compare this to hundreds of dollars for a whiteboard of comparable size at the local office superstore.) This key of colors should include a color for audio, technical, art, game design, level/mission design, backstory, user interface, controls, marketing, and miscellaneous issues.
Now with your color key on the whiteboard, open the floor. You are now soliciting ideas, concerns, areas of discussion, notes, tasks, anything worth noting belonging to any of these categories. If you find there is no appropriate category available, use the miscellaneous category or create a new one. Anything goes; stand up there with a good fat felt tip pen and dash off the notes with only one concept per sticky and put it on the board. Continually rearrange your stickies for better logical grouping of the ideas. Here is a stream of possible ideas: power-ups, level designers, hire lead animator, 3D engine, user extensibility, new chat system, dark color schemes, transparent menus, Chinatown, Old West, steam locomotives, lip-synching, use Patrick Stewart for voice, finish by Q4 2008, and so on. Litter your whiteboard with concepts.
I have found this whiteboard brainstorm method to be a powerfully effective method for rapidly digging up tons of new issues that I and other members of the development team must follow up on in the course of the design process.
After about one to two hours of brainstorming, the quality of ideas will start to diminish; watch it carefully, allow some humor of course, but be careful not to allow it to devolve into a sillyfest. When it is time to wrap it up, delegate groupings of stickies to be followed up by individuals and subgroups. Make sure every single sticky has an owner who is responsible for carrying out the idea or issue to resolution.
Be sure each individual understands what specific deliverables he or she must produce for the design document, from staffing plans to memory tests on the PlayStation2. Each of these design tasks must be scheduled and have a due date. It may be useful to lay all of these design tasks out in Microsoft Project or some other project planning software if the number of design tasks is large or represents more than three to six man-months of effort.
Managing the Design Document
The design document is referred to in the singular as if it were a massive tome only suitable for the largest three-ring binders your office superstore carries. I think it is wrong to keep the design document as one massive document. As such it is much harder to delegate sections to be worked on by various team members. Break the document up into as many discrete building blocks as possible. Place your design documents into a version control system such as Perforce or Visual Source Safe from the very first iteration. This of course prevents losses and allows you to go back and understand what the changes have been and perhaps revert to an older document if you find yourself in a design cul-de-sac.
Consider connecting all your documents, spreadsheets, diagrams, sketches, and notes into a web of documents using HTML (after all, HTML was designed to assist scientists in connecting their research papers). It is up to you and your organization to determine what the overhead costs are for connecting all the documents through web links.For each individual document I recommend listing the controlling author and one-line descriptions of the revision history including dates.
60 Seconds of Gameplay
A defining document of the game detailing 60 full seconds of every bit of gameplay and response crystallizes the game experience and leaves no room for individual interpretations of what the game could be about. I remember reading the postmortem of Tropico in Game Developer magazine. The author of the postmortem was courageous enough to admit that after one full year of development on Tropico it became evident that the development team was not working together to create a game of a single shared design, but rather individual members were pursuing their own game design for Tropico and were actively and passively campaigning for features and assets that would support their vision of the game! I have never seen this written down in print anywhere else, but I have seen this wholly unproductive behavior in action on several teams. I think of it almost like the quantum description of electrons flying about the nucleus of an atom, each electron representing a member of the team and his personal design for the game, and factoring in the Heisenberg uncertainty principle, no one really knows where anyone else is and what their velocity is at the sametime. Obviously this is a misunderstanding at best and a dysfunctional team at worst.
With dysfunctional teams, the producer and management must be merely hoping the team will accidentally come together and produce a commercial game. And for teams suffering from misunderstanding, think of all the wasted effort pursuing bits of games that almost were. The 60 seconds of gameplay document will nip these scattered games before they start growing by making the actual gameplay clear. This sort of document is a little difficult to write with certainty from day one, and it may take many iterations before the 60 seconds of gameplay settles down to its final form.
As a side benefit to the marketing team, console manufacturers and the executive management team will be grateful for (or sometimes demand) the 60 seconds of gameplay, and you will have it on hand to pass out to these stakeholders.
Building upon the 60 seconds of gameplay, create a document to flesh out the core gameplay with a complete description of all of the interactions, behaviors, and controls for the game. Take a car racing game for example; describe all of the controls for maneuvering the car, and describe all of the interactions with the environment such as bumping into other cars and walls and traveling across gravel, sand, and wet pavement. Perhaps the game will feature time of day, weather, and glare from the sun. For a role-playing game note melee, ranged, and spell attacks, healing spells, information gathering spells, walking, running, speaking to nonplayer characters, traveling to new cities, gaining experience, allocating experience points, buying new armor, buying food, and so on. Don’t take the time to detail all of these activities to the finest detail; create separate documents for each of these. For example, after listing that the player is able to buy weapons, armor, and magical items in the town in Diablo, create separate documents that list the details for each of these items and the vendors for each of these subtypes of equipment.
Now you have a high-level design document describing all of the core gameplay for the game. This high-level design document will then act as a finding guide to the rest of the subgame design documents.
I highly recommend using UML use case diagrams to document each and every one of these core interactions with the game. These use cases are readily usable by the programming team to flesh out a technical design, and the use cases will also serve as the platform for developing the QA plan for the game.
Note just by looking at the following use case diagrams for the three genres of real-time strategy, roleplaying, and first-person shooter, we are able to discern at an analytic level what these genres are about and the gameplay experience delivered by these three genres.
The core use cases of Doom
The core use cases of Gran Turismo 3
The core use cases of Diablo
One of the most valuable parts of the game design document will be the asset lists, which I cover in the next section. However, to create comprehensive asset lists you will need an understanding of the complete gameplay experience. This is the walkthrough for the entire game.
The walkthrough covers all of the gameplay experience the player would encounter through one pass through the whole game. Commonly this would be the documentation of the singleplayer campaign for games that feature campaigns. For our Black9 action-RPG game we took the time to detail every line of dialogue and every trap and challenge the player would face during each of the 16 missions that occurred during the single-player game.
JARGON: Walkthrough—the complete documentation of the player’s experience from the start of the game to the end of the game.
The exact format or type of walkthrough would differ dramatically between different genres of games. For the racing game of Gran Turismo, the walkthrough would consist of describing all the races, race series, championships, and licensing courses. The walkthrough would cover all the enemies encountered during the game: enemy cars, enemy superheroes, enemy goblins, or enemy disasters, such as in your SimCity game.
The completed walkthrough is a major accomplishment deserving of a fine meal! This walkthrough acts as a travel guide for the rest of the team with the very first application of the walkthrough being the asset list compilations.
Asset lists are the spreadsheet lists of all the little bits that comprise the game such as spell effects, characters, racecars, car parts, crowd cheers, tiles, movies, music, animations, AI behaviors, weapons, and so on. These asset lists are fun to pore over and dream about as the game takes shape. The walkthrough from above makes it easy to produce these asset lists as the AI programmer only needs to read through the walkthrough, highlighting AI behaviors as he comes across them. The lead animator will build the animation matrix from seeing the character list and examining all the moves that each of the characters must come up with. Without a walkthrough you will be limited in your ability to list all of the required assets. This is quite dangerous to maintaining a tight schedule. Without having all the information in front of you when making the development plan, you will inadvertently allocate too many resources for the creation of some secondary or even tertiary assets and only later find in the schedule that you have run out of time to complete some truly primary assets. This is one way game projects slip.
Here is a short list of some of the asset lists you should have (note that some of these may not be appropriate to the title you are creating):
After you compile your asset list, the producers and section leads can start to fill in time estimates and dependency information used later to build the production plan. Remember that so far in the process you have not formally sat down and cut any features or assets yet, and you don’t do that on your first pass with the walkthrough and asset lists. Instead of cutting right away, I recommend you get on with other areas of design while the asset lists stew for a bit, gathering flavor. After at least two weeks and preferably four, go back with a fresh eye and start to remove requested assets, both from the asset lists and the walkthrough, that are clearly superfluous and will have no meaningful impact on the game. There is a fine line between detailing a game world and creating asset verbiage that never needed to be created in the first place.
Use of Other Games
Using other games for inspiration and as guidance for the implementation of specific features is a good practice. For example, since Diablo the industry is pretty much settled on red-colored health meters and blue-colored mana meters. Don’t make yellow-colored health meters and brown mana meters, not even if you use nanotech, quintessence, spell points, or any other magic system—just use blue. For first-person shooters, default the left mouse button to fire the main weapon in normal mode; no one will appreciate the right mouse button being the default behavior.
If you are designing a role-playing game with an inventory system and you like the paper-doll mechanics of Diablo, take a screen shot from Diablo and annotate what specific features will remain the same and what you are modifying. Referencing other games and taking the game industry forward is not plagiarism; it is just practical use of time. Some other aspects of game mechanics may not lend themselves to a screen shot. In that case, make a written reference in your design document about a feature such as “the player should be able to lasso his units as in Warcraft III.”
Plagiarism is copying another game, making a few minor modifications, and peddling it around town as if it is something new. Many publishers are guilty of opening up their latest copy of PC Data or TRST sales data and looking at what the number one selling game is and then promptly setting off to green-light a new game project that is a clone of one that is already a major hit. Think about the poor timing: The hit game was conceived atleast 24 months ago, and now the publisher will play catch-up and fund a new title that will take another 24 months to reach the market. Meanwhile, the guys who made the original are wrapping up their sequel and securing their position on the franchise. This seems dumb to me; I would rather be making the hit game that others are chasing.
All games have some sort of menu system, and in general the fewer menus the better. The trend nowadays is to embed as much of the menu system as possible into the actual game. I remember how brilliant it was in Quake I where id had the player choose his difficulty level by running through a small level and jumping through a teleporter. It was interesting to note that the insane difficulty setting was hidden by the use of a traditional secret along the path of choosing hard.
By current tastes the Quake I method of choosing a difficulty level would probably be considered laborious; however, it is even more popular to use the 3D engine of the game to render the menu interfaces. Dungeon Siege from Gas Powered Games featured animating chains and gears pushing and pulling the menus around, and many games now have the player choose their character model only after seeing the character models on display in their “living” format with sample animations and facial expressions. In Grand Theft Auto 3 the player bought weapons not through a 2D menu like the weapon dealer in Diablo, but rather by entering Amunation in Liberty City and simply walking through and colliding with the object of their choice.
The design of the menu system might be a drag, but it is very important to creating a clean, professional gameplay experience for the player. Creating slick menuing systems is more difficult than one would first think. The process I employ is to enlist my trusty friend the use case diagram and note all of the steps involved in getting the player from startup to all of the various modes of play and options.
Game Mechanics Detail
The game mechanics detail is probably what most people think of when they hear game design document. This document details all of the itty-bitty mechanics of your combat system, your sell system, or your racing model. All games are a simulation of some sort of activity, and the game mechanics detail is the formal analysis of that simulation and the description of how that model will be realized in your game. The game mechanics are much too specific to a particular game for me to be able to develop a generalized plan or format for its presentation.
Write the Manual?
One interesting suggestion from Steve McConnell that I have yet to try out on a project is to write the manual for the game during the game design process! If I were to try that, I think the best place is after the core gameplay, walkthrough, asset lists, game mechanics, and menu designs have been laid to paper.
The use cases of Gran Turismo 3’s menu system
Concept Sketches and Art Style Guide
The art director should be leading the art team through a series of sketching, prototyping, and visual design tasks while assisting in the overall production planning process. The sketches will help all involved understand the look and feel of the game. The user-interface prototypes dramatically assist in the communication of the core gameplay.
On Completeness and Uncertainty
As the author of a book on how to go about doing something, I am obliged to assume the role of someone pontificating. In the real world you will have many competing time pressures. Instead of carrying everything out to full completion, you must use your judgment and determine what areas of the design require the most game design resources. If you are making a sequel to a game that your team has already made, then you should not spend time creating documentation for the parts of the game that are not changing; instead, focus on the creative differences the new version is bringing to play. In areas of the game design document that still need more design effort but that you don’t have time to address at the present time, simply note the incompleteness, assign it to a member of the team, and suggest a date for completion.
The twin brother of incomplete work is uncertain work. Games are art forms realized in a piece of engineering brought forth by team effort. There is no way anyone has ever written down at the start of the project every detail about a game without changing his mind on the way to making a great game. It’s fine to note straightaway in the game design document areas that you feel need further examination or are dependent on learning new facts that will be unveiled at a later point in the project. As with incomplete work, be sure this area of uncertainty has an owner and a suggested date when the issue will be reexamined.
Cut Features Even Before Considering the Schedule
After laying out all this game design material on paper, most people would go straight to time estimates and project planning without considering cutting features. I hold a fervent conviction that the world’s great games do not have an abundance of features, rather they have just the right amount of features polished to an uncommonly high standard! To help make your game a great game, rather than just plugging in every single feature you and your team can think of, instead consider your process to be like sculpting the perfect game out of game developer mind-stone. As these extraneous features are cut from the project, the true beauty of a great game will shine. By cutting now, without any pressure from a time resource point of view, your feature cuts will be more pure and objective. Go ahead and cut big features as well as small features. No worries if you cannot bring yourself to make permanent cuts; simply designate truly great features as primary, the lesser ideas as secondary, and the most obviously weak features as tertiary.
You will no doubt have to repeat this process of prioritizing and cutting features later in the production process, but that task will be much easier with all of this thinking about what really needs to be in the game already completed.
Maintain the Game Design Document
Ah, so you are all done; HTML everywhere, no one has ever pushed UML use cases to the limits you have, and you are prepared to have an auditing company review your asset lists. Fantastic! Congratulate your team and have a beer. Now get on with the rest of the production plan and production in general. Oh, wait, there is one thing left to do with the design document: Keep it up to date. This can be difficult, tedious busywork for a team, and you must decide what level of formality and rigor must be applied to maintain your own game design document. However, the moment a game design document is saved and checked into the source control system it starts to diverge. This is due to people finding their own improvements to the design. Perhaps the design was vague, or perhaps the developer learned of a better technique, or perhaps someone ran low on time and cut some features. All of this activity should be documented to assist developers downstream. Think of the QA team that must update the testing plan, the manual writer, the voice director who must plan the dialogue sessions; there are a good many people who need an up-to-date design document.
Game Developing Related Interview Questions
|CSS3 Interview Questions||Android Interview Questions|
|SQL DBA Interview Questions||SQL Interview Questions|
|Java Design Patterns Interview Questions||Design Patterns Interview Questions|
|Game Graphics Designer Interview Questions||Advanced C++ Interview Questions|
Game Developing Tutorial
What Does This Book Cover?
Why Make Games?
What Makes Game Development Hard?
Game Project Survival Test
What Is A Game Made Of?
Business Context First
Key Design Elements
Game Design Document
The Technical Design Document
The Project Plan
Shipping Your Game
The Design Document
Unified Modeling Language Survival Guide
Putting It All Together Into A Plan
Controlling Feature Creep
Alpha, Beta, Go Final!
Point Releases Vs. Patches
Garage Development Spans The Internet
Getting A Job In The Game Industry
Starting A Game Development Company
Outsourcing Sound Effects
Outsourcing Cinematics And Models
Outsourcing Motion Capture And Animation
All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd
Wisdomjobs.com is one of the best job search sites in India.