gdd como hacerlo

7/27/2019 Gdd Como Hacerlo

1/28

The Anatomy of a Design Document, Part 1:Documentation Guidelines for the Game Concept andProposalbyTim Ryan[Design,Production]

5 comments

October 19, 1999 Page 1 of 4

The purpose of design documentation is to express the vision for the game, describe the

contents, and present a plan for implementation. A design document is a bible from

which the producer preaches the goal, through which the designers champion their

ideas, and from which the artists and programmers get their instructions and express

their expertise. Unfortunately, design documents are sometimes ignored or fall short of

their purpose, failing the producers, designers, artists, or programmers in one way oranother. This article will help you make sure that your design document meets the

needs of the project and the team. It presents guidelines for creating the various parts

of a design document. These guidelines will also serve to instill procedures in your

development project for ensuring the timely completion of a quality game.

The intended audience is persons charged with writing or reviewing design

documentation who are not new to game development but may be writing documents

for the first time or are looking to improve them.

Design documents come in stages that follow the steps in the development process. Inthis first of a two-part series of articles, I'll describe the purpose of documentation and

the benefits of guidelines and provide documentation guidelines for the first two steps in

the process - writing a concept document and submitting a game proposal. In the next

part, I'll provide guidelines for the functional specification, technical specification and

level designs.

The Purpose of Documentation

In broad terms, the purpose of documentation is to communicate the vision in sufficient

detail to implement it. It removes the awkwardness of programmers, designers andartists coming to the producers and designers and asking what they should be doing. It

keeps them from programming or animating in a box, with no knowledge of how or if

their work is applicable or integrates with the work of others. Thus it reduces wasted

efforts and confusion.

Documentation means different things to different members of the team. To a producer,
http://www.gamasutra.com/view/authors/915461/Tim_Ryan.phphttp://www.gamasutra.com/view/authors/915461/Tim_Ryan.phphttp://www.gamasutra.com/view/authors/915461/Tim_Ryan.phphttp://www.gamasutra.com/features/design/http://www.gamasutra.com/features/design/http://www.gamasutra.com/features/production/http://www.gamasutra.com/features/production/http://www.gamasutra.com/view/feature/3384/the_anatomy_of_a_design_document_.php#commentshttp://www.gamasutra.com/view/feature/3384/the_anatomy_of_a_design_document_.php#commentshttp://www.gamasutra.com/features/production/http://www.gamasutra.com/features/design/http://www.gamasutra.com/view/authors/915461/Tim_Ryan.php


2/28

it's a bible from which he should preach. If the producer doesn't bless the design

documents or make his team read them, then they are next to worthless. To a designer

they are a way of fleshing out the producer's vision and providing specific details on how

the game will function. The lead designer is the principle author of all the documentation

with the exception of the technical specification, which is written by the senior

programmer or technical director. To a programmer and artist, they are instructions for

implementation; yet also a way to express their expertise in formalizing the design and

list of art and coding tasks. Design documentation should be a team effort, because

almost everyone on the team plays games and can make great contributions to the

design.

Documentation does not remove the need for design meetings or electronic discussions.

Getting people into a room or similarly getting everyone's opinion on an idea or a plan

before it's fully documented is often a faster way of reaching a consensus on what's

right for the game. Design documents merely express the consensus, flesh out the

ideas, and eliminate the vagueness. They themselves are discussion pieces. Though

they strive to cement ideas and plans, they are not carved in stone. By commenting on

them and editing them, people can exchange ideas more clearly.

The Benefits of Guidelines

Adhering to specific guidelines will strongly benefit all of your projects. They eliminate

the hype, increase clarity, ensure that certain procedures are followed, and make it

easier to draft schedules and test plans.

Elimination of hype. Guidelines eliminate hype by forcing the designers to define the

substantial elements of the game and scale back their ethereal, far-reaching pipe

dreams to something doable.

Clarity and certainty. Guidelines promote clarity and certainty in the design process.

They create uniformity, making documents easier to read. They also make documents

easier to write, as the writers know what's expected of them.

Guidelines ensure that certain processes or procedures are followed in the development

of the documentation - processes such as market research, a technical evaluation, and a

deep and thorough exploration and dissemination of the vision.

Ease of drafting schedules and test plans. Design documents that follow specific

guidelines are easy to translate to tasks on a schedule. The document lists the art and

sound requirements for the artists and composers. It breaks up the story into distinct

levels for the level designers and lists game objects that require data entry and

scripting. It identifies the distinct program areas and procedures for the programmers.


3/28

Lastly, it identifies game elements, features, and functions that the quality assurance

team should add to its test plan.

Varying from the guidelines. The uniqueness of your project may dictate that you

abandon certain guidelines and strictly adhere to others. A porting project is often a no-

brainer and may not require any documentation beyond a technical specification if no

changes to the design are involved. Sequels (such as Wing Commander II, III, and so

on) and other known designs (such as Monopoly or poker) may not require a thorough

explanation of the game mechanics, but may instead refer the readers to the existing

games or design documents. Only the specifics of the particular implementation need to

be documented.

Guidelines for the Game Concept

A game-concept document expresses the core idea of the game. It's a one-

to two-page document that's necessarily brief and simple in order to

encourage a flow of ideas. The target audience for the game concept is all

those to whom you want to describe your game, but particularly those

responsible for advancing the idea to the next step: a formal game

proposal.

Typically, all concepts are presented to the director of product development

(or executive producer) before they get outside of the product development

department. The director will determine whether or not the idea has merit

and will either toss it or dedicate some resources to developing the game

proposal.

The director might like the concept but still request some changes. He or

she may toss the concept around among the design staff and producers or

open it up to the whole department or company. The concept can become

considerably more compelling with the imagination and exuberance of a

wide group of talented people.

A game concept should include the following features:

Introduction

Background (optional)

Description

Key features

Genre


4/28

Platform(s)

Concept art (optional)

Introduction: The introduction to your game concept contains what are

probably the most important words in the document - these words will sell

the document to the reader. In one sentence, try to describe the game in

an excited manner. Include the title, genre, direction, setting, edge,

platform, and any other meaningful bits of information that cannot wait

until the next sentence. The edge is what's going to set this game apart

from the other games in the genre. For example:

"Man or Machine is a first-person shooter for the PC that uses the proven

Quake IIengine to thrust players into the role of an android space marine

caught up in the epic saga of the interstellar techno-wars of the thirty-

seventh century."

Breaking the introduction up into several sentences for the sake of clarity is

acceptable. Just know that the longer your introduction, the more diluted

your vision will seem.

Background (optional): The background section of your game concept

simply expands upon other products, projects, licenses, or other properties

that may be mentioned in the introduction; so it's optional. The background

section is physically separated from the introduction so that readers can

skip it if they already have the information presented. But the background

section is important for licensed properties and sequels and concepts with

strong influences from previously released titles in the same genre. If you

intend to use an existing set of code or tools or to license a game engine,

then describe these items and their success stories here.

Description: In a few paragraphs or a page, describe the game to the

readers as if they are the players. Use the second-person perspective --

"you." Try to make this section an exciting narrative of the player's

experience. Encompass all the key elements that define the core game play

by describing exactly what the player does and sees. Avoid specifics such

as mouse-clicks and keystrokes, but don't be too vague. You want the

readers to become the player's character. Hover your detail level right

above the GUI interaction. You would say something such as, "You scan

your tactical radar and pick up two more bogies coming up the rear,"

instead of "You click on your tactical radar button and the window pops up

revealing two bogies coming up the rear." The description section should


5/28

make the content and entertainment value of the game obvious and

convincing.

Key features: Your game concept's key features section is a bullet point

list of items that will set this game apart from others and provide goals to

which the subsequent documentation and implementation should aspire.

It's a summary of the features alluded to in the description. These bullet

points are what would appear on the back of the game box or on a sell

sheet, but include some supporting details. For example:

"Advanced Artificial Intelligence (AI): Man or Machine will recreate and

advance the challenging and realistic AI that made Half-Life game of the

year."

Determining how many features to list is a delicate balancing act. Listing

only one or two key features is a bad idea if you're doing anything more

complex than a puzzle game; listing more than a page of features implies

that the project would be a Herculean task and may scare off the bean

counters. Listing too few features might sell your concept short; listing too

many waters down the concepts' strongest features.

Keep in mind that you need not list features that are given, such as "great

graphics" and "compelling music," unless you really think such features are

going to be far superior to those of the competition. Great graphics,

compelling music, and the like are the understood goals of every game

project. On the other hand, if the particular flavor of graphics and music

provides your game with an edge in the market, then you should spell that

out.

Genre: In a few words, define the game genre and flavor. Use existing

games' classifications from magazines and awards as a guide. For example,

you could choose one of the following: sports, real-time strategy, first-

person shooter, puzzle, racing simulation, adventure, role-playing game,

flight simulation, racing shooter, god simulation, strategy, action-strategy,

turn-based strategy, side-scrolling shooter, edutainment, or flight shooter.

Then you can refine your game's niche genre with these or other words for

flavor: modern, WWII, alternate reality, post-apocalyptic, futuristic, sci-fi,

fantasy, medieval, ancient, space, cyberpunk, and so on.

Platform(s): In a few words, list the target platform(s). If you think the

game concept is applicable to multiple platforms, you should also indicate


6/28

which platform is preferred or initial. If you intend multiplayer support on

the Internet, indicate that as well.

Concept art (optional): A little bit of art helps sell the idea and puts the

readers in the right frame of mind. Use art to convey unique or complex

ideas. Screen mock-ups go a long way to express your vision. Art for the

game concept may be beyond most employees' capabilities, so requiring it

would limit the number of submissions; thus, it is optional. If a concept has

merit, the art can come later from a skilled resource. Often art from

previous projects or off of the Internet will jazz up a document. Just be

careful with any copyrighted material.

Common Mistakes

Here are some common mistakes that developers make in creating a game

concept:

The concept is totally off base or inapplicable to the company's

current plans. If you don't want to waste your time writing up

concepts that get tossed, find out what the company in question is

looking for and keep an ear to the ground for opportunities with

which your idea may be a good fit.

In terms of resources, the document asks for the moon. Try to keep

your concept within the realm of possibility. Keeping the budgets

down by suggesting existing tools or properties to reuse is helpful.

Limit your ideas to that which can be accomplished in a timely

fashion and with a reasonable budget. Limit experimental

technologies to one area. Don't suggest revolutionary AI as well as a

new, state-of-the-art 3D engine. If you are being solicited to produce

the game concept, find out what the time frame and budget

expectations are first.

The document lacks content. Simply saying, "It's Command &

Conquermeets MechWarriorwhere you order your 'Mechs in tactical

combat," is insufficient. Your description has to explain the actions

that the player will perform and make them seem fun. A good

description might read, for example, "You order your 'Mech to fire at

point-blank range on the exposed right torso of the Clan MadCat


7/28

OmniMech." This kind of descriptive content will help mitigate

misinterpretations of the core game play that you envision.

The game isn't fun. A useful exercise is to break down all of theplayer verbs (such as shoot, command, run, purchase, build, and

look) and envision how player performs each. Then, for each verb,

ask yourself if it's fun. Then ask yourself if the target market would

find it fun. Be objective. If the action that the player takes isn't fun,

figure out another action for the player to take that is fun or drop the

verb entirely.

The game-concept document employs poor language and grammar.Don't make yourself look like an ass or an idiot. Check your grammar

and spelling and avoid four-letter words and sexual innuendo. You

don't know who will ultimately read your document or whom you

might offend with some particularly expressive words. Even the

macho, politically incorrect, culturally insensitive, slang-using

manager with whom you exchange dirty jokes over a beer at

lunchtime can get quite sensitive with documented verbiage.

The designer gives up. Don't give up submitting ideas. You never

know when one of them will take off. Persistence pays off, believe

me.

Guidelines for the Game Proposal

A game proposal is a formal project proposal used to secure funding and

resources for a game development project. As a game proposal takes time(and therefore, money) to do correctly, it should only be developed for

promising game concepts.

The proposal is an expansion upon the game concept. Writing a proposal

may involve gathering feedback and information from other departments,

especially the marketing department (if it exists). You may need your


8/28

marketing department to perform some market research and analysis on

the concept. If the game requires licensing, you may need your finance and

legal departments to investigate the availability and costs involved in

securing the license.

The programming staff, typically senior programmers or the technical

director, should perform an initial technical evaluation of the concept. They

should comment on the technical feasibility of the concept and the

programming areas that may require research. They should assess the

risks and major tasks in the project and suggest solutions and alternatives.

They should give a rough estimate as to the required research and

development time and resources.

The game proposal should include a revised version of the game concept.

Technical, marketing, and finance feedback to the concept document might

force you to scale back the concept. It might also suggest modifying or

adding features. These changes should not take anyone by surprise, as this

is the first time that the concept has been subjected to major criticism and

the collaborative process. Giving copies of the feedback and analysis to the

director of development (or whoever asked for the game proposal) before

they are folded into the game proposal or effect changes in the concept is a

good idea. This process not only provides written confirmation that the

concept has been reviewed by certain people or departments, but it arms

the director with the knowledge to veto, alter, or otherwise approve any

proposed changes.

The game proposal includes the following features:

Revised game concept (preceding)

Market analysis

Technical analysis

Legal analysis (if applicable)

Cost and revenue projections

Art

Market analysis: The marketing department and/or a market research

firm, assuming your company can afford it, should compile this information.

If you are compiling this information yourself, you should try to avoid pure

guesses on numbers. Look for info on the Internet (www.gamestats.comis

a good source) and use existing hits in the same genre as indicators for

market performance.
http://www.gamestats.com/http://www.gamestats.com/http://www.gamestats.com/http://www.gamestats.com/


9/28

Target market: The target market is defined by the genre and the

platform, issues that have been already addressed in the concept

document. You can qualify this definition by mentioning specific titles

that epitomize this market. The most successful of these titles will

indicate the viability and size of the market. Also mention the typical

age range, gender, and any other key characteristics. If this game

involves a licensed property or is a sequel, describe the existing

market.

Top performers: List the top performers in the market. Express their

sales numbers in terms of units, breaking out any notable data-disk

numbers and any successful sequels. Include their ship date. You can

be vague -- Q1 1998 or spring 1998. This research can go way back,

so present your data in chronological order.

List their platforms if they vary from the platform for the proposed

game. However, because the markets change depending on the

platform, you should always present some title of the same genre on

the target platform, even if it didn't perform as well as the others.

Such data may indicate a sluggishness for that particular genre of

games on the platform. For example, turn-based strategy games

may have great sales on the PC platform, but have terrible numbers

on the Sony PlayStation. This list of top performers should indicate

this discrepancy if you're doing a turn-based strategy game.

Feature comparison: Break down the selling features of these top

performers. Compare and contrast them to the key features

described in the concept document. Try to provide some specifics.

For example:

Tactical Combat: In Command & Conquer, Dark Reign, and Myth, you

order your units to attack specific targets and move to specific places

or ranges for an advantage. Most units have a unique strength and

weakness that become apparent during play, thus encouraging you

to develop superior tactics. Tanktics has a wider variety of orders to

allow you to apply superior tactics, such as capture, ram, and hit-

and-run. Unit position and target selection become even more

important due to terrain, movement, and range bonuses; firing arcs;

and soft spots in rear- and side-hit locations. All of the units have

distinct weaponry, armor, and speed to differentiate their strengths


10/28

and weaknesses and encourage tactics. Not only do you learn to

master these tactics over time, but you can also script these tactics

into custom orders.

Technical analysis: The technical analysis should be written by a

seasoned programmer, preferably the technical director or a lead

programmer, and then edited and compiled into the proposal. Reviewers of

this proposal will use this technical analysis to help them make their

decisions. Be honest; it will save you a lot of grief in the end. Overall, this

analysis should make the reviewers optimistic about the game's chance of

succeeding.

Experimental features: Identify the features in the design that seem

experimental in nature, such as untried or unproven technologies,

techniques, perspectives, or other unique ideas. Do not include

features that have been proven by existing games, even if they are

new to the development team. For example, if the team has never

developed a 3D engine, don't list it as experimental. Rather, list it in

one or more of the other categories in the technical analysis section.

On the other hand, if your development team is working on a 3D

engine using the theoretical system of quads, then this effort should

be listed as experimental. Of course, by the time you read this

article, quads could be in common use.

Include an estimate of the time that it will take to bring the

experimental feature to an evaluation state, as well as an overall

time estimate for completing the feature. Experimental areas

generally need more time in the schedule, so the more experimental

features you list, the longer the schedule will be. While some

companies shy away from such 18- to 24-month projects, many see

these experiments as worthwhile investments in creating leading-

edge titles. So tell it like it is, but don't forget to tell them what they

will get out of it. Make them feel comfortable that the experiments

will work out well.

Major development tasks: In a paragraph or a few bullet points,

make clear the major development tasks. Use language that non-

technical people can understand. Major means months of

development. Give a time estimate that assumes that you have all of

the resources that you'll need to accomplish the task. You could also

give an estimate of the resources that you'll need. For example:


11/28

"Artificial Intelligence Script Parser: Three to four months with two

programmers. The parser reads and compiles the AI scripts into

lower-level logic and instructions that are executed at run-time."

Risks: List any technical risks. If you don't foresee any technical

risks, by all means say so. Risks are any aspect of research and

development that will cause a major set back (weeks or months) if

they fail. List technologies that, though they've been proven to work

by competitors, your company has never developed or with which

your company has little experience. List, for example, real-time

strategy if your team has never developed a real-time strategy game

before; or 3D rendering if this is your first foray into 3D. List any of

the major development tasks mentioned previously if you perceive

any risk. All untried off-the-shelf solutions (3D engines, editors, code

libraries and APIs, drivers, and so on) should be listed as risks

because they may end up not fulfilling your particular needs. Any

development done by an outside contractor should also be listed, as

that's always a big risk. When assessing risks, you should also

indicate the likely impact that fixing or replacing the technology will

have on the schedule. Indicate the time in weeks or months that the

ship date will slip. List the time impact on specific resources. List any

new resources (people, software, hardware, and so on) that would be

required to fix it. This section may seem pessimistic, but it creates a

comfort level for your document's reviewers - they will come away

with the impression that the game implementation is under control,especially if they can perceive these risks themselves. Plus you'll

have the opportunity to say, "You can't say I didn't warn you."

Alternatives (if any): Alternatives are suggestions for working around

some of these experimental or risky features and major development

tasks. By presenting alternatives, you give the reviewers options and

let them make the choices. List anything that might cost more money

or time than desired but might have better results, or vice versa (itmay cost less money and time but it may have less desirable

results). Whatever you do, be sure to spell out the pros and cons.

Estimated resources: List the estimated resources: employees,

contractors, software, hardware, and so on. Use generic, industry-


12/28

standard titles for people outside of the company: for instance, the

publisher or investor who might read your document. List their time

estimates in work months or weeks. Ignore actual costs (dollars), as

that comes later.

Estimated Schedule: The schedule is an overall duration of the

development cycle followed by milestone estimates, starting with the

earliest possible start date, then alpha, beta, and gold master.

Guidelines for the Game Proposal, continued

Legal analysis (if applicable): If this game involves copyrights, trademarks,

licensing agreements, or other contracts that could incur some fees, litigation

costs, acknowledgments, or restrictions, then list them here. Don't bothermentioning the necessity of copyrighting the game's title or logo, as these are par

for the course and likely to change anyway.

Cost and revenue projections: The cost and revenue projections can be done in

conjunction with the finance and purchasing departments. This data should give the

reader a rough estimate of resource costs based on the technical analysis's

estimated resources.

Resource cost: Resource cost is based on the estimated resources within the

technical analysis. Employee costs should be based on salaries and overhead,which the finance or payroll department should provide. You can list these as

average by title or level. Any hardware or software that you purchase should

be listed as well, even if it will ultimately be shared by other projects or

folded into the overhead budget. Use a table or embedded spreadsheet as it

is easier to read and edit. For example:

Employee Cost Per Month Work Months Total

2D Artists $4,000 35 $140,000Lead Artist 7,000 14 98,000Level Designers 3,000 35 105,000

Total: 343,000

Hardware/Software Price Qty. Total


13/28


14/28

Presentation: The whole proposal, including the revised concept document,

should be printed on sturdy stock and bound in a fancy report binder along with

copies of the art. This document is to be presented to business people - you know,

those people who walk around your office wearing fine suits to contrast with the t-

shirts and cut-offs that you normally wear. Don't forget that you're proposing a

major investment, so make the proposal look good and dress well if you're going to

handle the presentation. Preparing a slide show in a program such as Microsoft

Persuasion is helpful for pitching your key points and art.

Common Mistakes

Some common mistakes in preparing a game proposal include:

The analysis is based on magic numbers. Try to back up your numbers by

listing your sources or explaining how you came up with them. Watching a

producer pull some numbers from thin air and throw them in the document is

almost laughable.

The proposal is boring. This is a selling document. Don't bore the readers.

Give them facts, but make these facts exciting, concise, and convincing.

The proposal fails to anticipate common-sense issues and concerns. You

should find out what this proposal is up against -- other proposals,

competitive products, financing concerns, cost and time expectations, game

prejudices, and historical mishaps. Your proposal will stand a much better

chance of being approved if it addresses these issues preemptively rather

than getting besieged by them during the review process.

The proposal writer is overly sensitive to criticism. My experience might be

unique, but don't be surprised if the major promoter for your game proposal

decides to play devil's advocate. Make sure your proposal is solid. Believe in

it and remain confident, and you'll weather the criticism and make believers

out of those reviewing your proposal.

The proposal writer is inflexible to changes to the game. Often during the

process of gathering research or receiving criticism from the review

committee, some reasonable suggestions will arise for changing or scaling

back the design. Game development is a collaborative process. Take the

feedback and change the design, or the game could die right there. The key

word here, as tattooed on the arm of my buddy who served in the Vietnam

War, is transmute. He had to transmute to stay alive and keep going, and

your game idea may have to do the same.


15/28

This concludes part one of a two-part series on the anatomy of a design document.

In the next part, I'll taunt you with some more colorful metaphors interspersed

with some useful guidelines for creating functional and technical specifications and

level-design documents. I'll also give you an overview of the document review

process and how it facilitates the game development cycle.

Tim Ryan is a freelance game developer and software consultant. He has

produced and designed computer games since 1992. His recent work can

be seen in the PC game MechCommander: The First MechWarrior Game of

Tactical Command. Please send your feedback, questions, and business

inquiries [email protected].

El propsito de la documentacin de diseo es expresar lavisin de juego, una descripcin del contenido, y presentar unplan para la implementacin. Un documento de diseo es unabiblia de la que el productor predica la meta, a travs del cuallos diseadores defienden sus ideas, y de la que los artistas yprogramadores obtienen sus instrucciones y expresar susconocimientos. Por desgracia, los documentos de diseo son aveces ignorados o no llegan a su fin, a falta de los productores,

diseadores, artistas o programadores de una manera u otra.Este artculo le ayudar a asegurarse de que el documento dediseo se ajusta a las necesidades del proyecto y el equipo. Sepresenta las directrices para la creacin de las diversas partesde un documento de diseo. Estas directrices servirn tambinpara inculcar en los procedimientos de su proyecto dedesarrollo para asegurar la finalizacin puntual de un juego decalidad.Los destinatarios son las personas encargadas de la redaccino revisin de documentacin de diseo que no son nuevos enel desarrollo del juego, pero puede escribir documentos porprimera vez, o est mirando para mejorarlas.Los documentos de diseo vienen en etapas que siguen lospasos en el proceso de desarrollo. En esta primera de una seriede dos partes de artculos, voy a describir el propsito de la
mailto:[email protected]:[email protected]:[email protected]:[email protected]


16/28

documentacin y los beneficios de las directrices y proporcionardirectrices de documentacin para los dos primeros pasos delproceso de escritura - un documento de reflexin ypresentacin de una propuesta de juego. En la siguiente parte,

voy a proporcionar directrices para la especificacin funcional,especificaciones tcnicas y diseos de nivel.El propsito de la documentacinEn trminos generales, el objetivo de la documentacin es paracomunicar la visin en detalle suficiente para aplicarla. Seelimina la incomodidad de programadores, diseadores yartistas que vienen a los productores y diseadores y pedir loque deberan estar haciendo. Se les impide la programacin ola animacin en una caja, sin saber cmo o si su trabajo esaplicable o se integra con el trabajo de otros. Por lo tanto,reduce el desperdicio de esfuerzos y confusin.Documentacin significa cosas diferentes para diferentesmiembros del equipo. Para un productor, es una biblia de la quedebera predicar. Si el productor no bendice a los documentosde diseo o hacer que su equipo leerlos, entonces ellos estn allado de nada. Para un diseador que son una manera de darcontenido a la visin del productor y los detalles especficos

sobre cmo el juego funcionar. El diseador en jefe es el autorprincipal de toda la documentacin, con la excepcin de laespecificacin tcnica, que est escrito por el programadorsenior o director tcnico. Para un programador y artista, son lasinstrucciones para su aplicacin, sin embargo tambin es unamanera de expresar su experiencia en el diseo y formalizacinde lista del arte y la codificacin de las tareas. Documentacinde diseo debe ser un esfuerzo de equipo, ya que casi todos enel equipo juega y puede hacer grandes contribuciones al

diseo.Documentacin no elimina la necesidad de reuniones de diseoo discusiones electrnicas. Hacer que la gente en unahabitacin o similar conseguir la opinin de todos en una idea oun plan antes de que sea plenamente documentado es amenudo una forma ms rpida de llegar a un consenso sobre lo


17/28

que es correcto para el juego. Los documentos de diseo selimitan a expresar el consenso, profundizar en las ideas, yeliminar la vaguedad. Ellos mismos son piezas de discusin. Apesar de que se esfuerzan por consolidar ideas y planes, no

estn talladas en piedra. Al comentar sobre ellos y editarlos, lagente puede intercambiar ideas con mayor claridad.

Los beneficios de las DirectricesLa adhesin a las directrices especficas de enorme beneficiopara todos sus proyectos. Eliminan el bombo, aumentar laclaridad, asegrese de que ciertos procedimientos se siguen, yque sea ms fcil para los proyectos de listas y planes deprueba.Eliminacin de bombo. Directrices eliminar publicidad,obligando a los diseadores para definir los elementosimportantes del juego y reducir sus etreos, de gran alcancecastillos en el aire a algo factible.La claridad y certeza. Directrices promover la claridad y certezaen el proceso de diseo. Crean uniformidad, por lo que losdocumentos ms fciles de leer. Tambin hacen ms fcilescribir documentos, ya que los escritores saben lo que se

espera de ellos.Directrices asegurar que ciertos procesos o procedimientos sesiguen en el desarrollo de la documentacin - procesos como lainvestigacin de mercado, una evaluacin tcnica, y unaexploracin profunda y exhaustiva y la difusin de la visin.Facilidad de redaccin de los horarios y planes de prueba. Losdocumentos de diseo que siguen los lineamientos especficosson fciles de traducir a las tareas en un horario. En eldocumento se enumeran los requisitos del arte y el sonido de

los artistas y compositores. Se rompe la historia en distintosniveles para los diseadores de niveles y objetos de las listasde juegos que requieren entrada de datos y secuencias decomandos. En l se identifican las distintas reas del programay los procedimientos para los programadores.


18/28

Directrices para el concepto del juegoUn documento de juegos concepto expresa la idea central del

juego. Es una relacin uno a dos pginas del documento que esnecesariamente breve y sencilla con el fin de fomentar la

afluencia de ideas. El pblico objetivo para el concepto deljuego es todos aquellos a quienes se quiere describir su juego,pero en particular a los responsables de promover la idea con elsiguiente paso: una propuesta formal de juegos.

Por lo general, todos los conceptos son presentados al directorde desarrollo de productos (o productor ejecutivo) antes de quelleguen fuera del departamento de desarrollo de productos. Eldirector determinar si la idea tiene mrito y, o bien se lo tire odedicar algunos recursos para el desarrollo de la propuesta de

juego.El director le guste la idea, pero todava solicitar algunoscambios. l o ella puede lanzar el concepto en torno entre elpersonal de diseo y los productores o abrirlo a todo eldepartamento o empresa. El concepto puede llegar a sermucho ms convincente con la imaginacin y la exuberancia deun amplio grupo de personas con talento.

Un concepto de juego debe incluir las siguientes caractersticas:IntroduccinFondo (opcional)DescripcinLas principales caractersticasGneroPlataforma (s)

Arte conceptual (opcional)Introduccin: En la introduccin de su concepto de juego

contiene lo que son, probablemente, las palabras msimportantes del documento - estas palabras vender eldocumento para el lector. En una frase, trate de describir el

juego de una manera emocionada. Incluya el ttulo, gnero,direccin, ajuste, borde, plataforma y cualquier otrosfragmentos significativos de informacin que no pueden esperar


19/28

hasta la siguiente frase. El borde es lo que va a establecer estejuego, aparte de los otros juegos del gnero. Por ejemplo:"El hombre o la mquina es un shooter en primera persona paraPC que utiliza el motor de Quake II probada para empujar a los

jugadores en el papel de un marine espacial androideatrapados en la saga pica de los interestelares tecno-guerrasdel siglo 37o. "Rompiendo la introduccin en frases varias en aras de laclaridad es aceptable. Slo s que el ms largo de suintroduccin, ms diluido su visin se parecen.Fondo (opcional): La seccin de fondo de su concepto de juegosimplemente ampla los otros productos, proyectos, licencias uotras propiedades que se pueden mencionar en la introduccin,por lo que es opcional. La seccin de antecedentes estfsicamente separado de la introduccin para que los lectorespuedan omitir si ya tienen la informacin presentada. Pero laseccin de fondo es importante para las propiedades delicencia y secuelas y conceptos con fuertes influencias de losttulos lanzados anteriormente en el mismo gnero. Si va autilizar un conjunto existente de cdigo o herramientas o lalicencia de un motor de juego, a continuacin se describen

estos elementos y sus historias de xito aqu.Descripcin: En unos pocos prrafos o una pgina, describa eljuego a los lectores como si fueran los jugadores. Use laperspectiva de la segunda persona - "usted". Trate de haceresta seccin un relato emocionante de la experiencia del

jugador. Abarcar todos los elementos clave que definen el juegobsico, describiendo exactamente lo que el jugador hace y ve.Evite especficos tales como clics de ratn y pulsaciones deteclas, pero no seas demasiado vaga. Usted quiere que los

lectores a convertirse en el personaje del jugador. Pasa el nivelde detalle justo encima de la interaccin GUI. Se podra deciralgo como, "usted Analizar el radar tctico y recoger dos bogiesms prximos en la retaguardia," en lugar de "Se hace clic en elbotn de radar tctico y en la ventana emergente que revelados bogies viene la parte trasera." La seccin de descripcin


20/28

debe hacer que el contenido y el valor de entretenimiento deljuego evidente y convincente.

Caractersticas principales: La seccin clave de su concepto

de juego de caractersticas es una lista de puntos de bala deelementos que marcarn este juego, aparte de los dems yproporcionar objetivos a los que la documentacin eimplementacin subsiguiente debe aspirar. Es un resumen delas caractersticas aludidas en la descripcin. Estos puntos sonlo que parece en la parte posterior de la caja del juego o en unahoja de venta, pero incluyen algunos detalles de apoyo. Porejemplo:"Inteligencia Artificial Avanzada (AI): El hombre o la mquinavolver a crear y fomentar la IA desafiante y realista que hizoHalf-Life juego del ao".Determinar cuntas caractersticas a la lista es un delicado actode equilibrio. Aadir una o dos caractersticas clave es unamala idea si usted est haciendo algo ms complejo que un

juego de puzzle, lista ms de una pgina de funciones implicaque el proyecto sera una tarea herclea y puede ahuyentar alos contadores. Caractersticas del inmueble muy pocos podran

vender su idea a corto, aguas abajo listado demasiados losconceptos ms fuertes de caractersticas.Tenga en cuenta que no necesitan funciones de lista que sedan, como los "grandes grficos" y "msica convincente", amenos que usted realmente cree estas caractersticas van a sermuy superiores a los de la competencia. Grandes grficos,msica convincente y similares son los objetivos de cadaproyecto entendidos juego. Por otro lado, si el sabor particularde los grficos y la msica le brinda a su juego con una ventaja

en el mercado, entonces usted debe escribir eso.Gnero: En pocas palabras, definir el gnero de los juegos ysabor. Utilice las clasificaciones juegos existentes "de revistas ypremios como gua. Por ejemplo, puede elegir una de lassiguientes: deportes, estrategia en tiempo real, disparos enprimera persona, rompecabezas, simulacin de carreras,


21/28

aventura, juego de rol, simulacin de vuelo, tirador carreras,simulacin de dios, estrategia, accin y estrategia, estrategiapor turnos, shooter de desplazamiento lateral, edutainment, o eltirador de vuelo. Entonces usted puede refinar su gnero juego

nicho con stas u otras palabras para dar sabor: moderno, laSegunda Guerra Mundial, la realidad alternativa, post-apocalptico, futurista, de ciencia ficcin, fantasa, espaciomedieval, antiguo, cyberpunk, y as sucesivamente.Plataforma (s): En pocas palabras, la lista de la plataforma dedestino (s). Si piensa que el concepto del juego es aplicable amltiples plataformas, tambin debe indicar qu plataforma espreferido o inicial. Si tiene la intencin soporte multijugador enInternet, indican que tambin.

Arte conceptual (opcional): Un poco de arte ayuda a vender laidea y pone a los lectores en el marco derecho de la mente.Usar el arte para transmitir ideas nicas o complejas. Pantallamaquetas recorrer un largo camino para expresar su visin.

Arte para el concepto del juego puede estar ms all de lascapacidades de la mayora de los empleados, por lo querequiere que limitara el nmero de presentaciones, por lo quees opcional. Si el concepto tiene mrito, el arte puede venir

despus de un recurso especializado. A menudo el arte deproyectos anteriores o fuera de la Internet voluntad jazz encimade un documento. Slo ten cuidado con cualquier material conderechos de autor.Errores comunesstos son algunos errores comunes que hacen losdesarrolladores en la creacin de un concepto de juego:El concepto es totalmente fuera de lugar o inaplicables a losplanes actuales de la compaa. Si usted no quiere perder el

tiempo escribiendo conceptos que se botan, averiguar lo que laempresa en cuestin est buscando y mantener el odo en elsuelo para las oportunidades con las que su idea puede ser unabuena opcin.

En trminos de recursos, el documento pide la luna. Trate de


22/28

mantener su concepto dentro del reino de la posibilidad.Mantener los presupuestos por lo que sugiere las herramientasexistentes o propiedades de reutilizacin es de gran ayuda.Limite sus ideas a lo que se puede lograr de manera oportuna y

con un presupuesto razonable. Limite las tecnologasexperimentales para un rea. No sugiera AI revolucionario, ascomo un nuevo estado-of-the-art motor 3D. Si usted est siendosolicitado para producir el concepto del juego, descubrir cul esel marco de tiempo y presupuesto son las expectativas enprimer lugar.

El documento carece de contenido. Simplemente diciendo: "EsCommand & Conquer cumple MechWarrior donde pedir sus'Mechs de combate tctico," es insuficiente. La descripcin tieneque explicar las acciones que el jugador va a realizar y hacerlosparecer divertido. Una buena descripcin puede leer, porejemplo, "ordenar su 'Mech para disparar a quemarropa sobreel torso derecho expuesta del Clan OmniMech MadCat". Estetipo de contenido descriptivo ayudar a mitigar las malasinterpretaciones de la jugabilidad bsica que usted imagina.

El juego no es divertido. Un ejercicio til es romper todos losverbos jugadores (tales como brotes, comando, ejecutar,adquirir, construir, y mirar) y visualizar cmo cada jugadorrealiza. Luego, para cada verbo, pregntese si es divertido.Luego pregntese si el mercado objetivo le resultara divertido.Sea objetivo. Si la accin que el jugador toma no es divertido,encontrar otra accin para que el jugador que es divertido tomaro dejar el verbo completo.

El documento de concepto de juego emplea un lenguaje pobrey gramtica. No te hagas ver como un culo o un idiota. Revisesu gramtica y ortografa y evitar palabras de cuatro letras einsinuaciones sexuales. Usted no sabe que en ltima instanciava a leer el documento o quien pueda ofender con palabrasparticularmente expresivos. Incluso el macho, polticamente


23/28

incorrecta, falta de sensibilidad cultural, la jerga que utilizangerente con quien intercambiar chistes verdes con una cervezaen el almuerzo puede llegar a ser muy sensible con verborreadocumentado.

El diseador se da por vencido. No renuncie a la presentacinde ideas. Nunca se sabe cuando uno de ellos va a despegar.Persistencia vale la pena, creme.

Directrices para la Propuesta de JuegosUna propuesta de juego es una propuesta de proyecto formalusado para asegurar la financiacin y los recursos para unproyecto de desarrollo de juegos. Como propuesta juego tienetiempo (y por lo tanto, dinero) para hacerlo correctamente, slodebera ser desarrollado para conceptos de juegoprometedores.La propuesta es una expansin en el concepto de juego.Escribir una propuesta puede implicar la recopilacin deinformacin y la informacin de otros departamentos,especialmente el departamento de marketing (si existe). Esposible que su departamento de marketing para llevar a cabo

una investigacin de mercado y anlisis sobre el concepto. Si eljuego requiere de licencia, es posible que tenga sus finanzas ydepartamentos legales para investigar la disponibilidad y loscostos involucrados en la obtencin de la licencia.El personal de programacin, por lo general los programadoresde alto nivel o el director tcnico, debe realizar una evaluacintcnica inicial del concepto. Se debe comentar sobre laviabilidad tcnica del concepto y las reas de programacin quepueden requerir investigacin. Se deben evaluar los riesgos y

las tareas principales en el proyecto y proponer soluciones yalternativas. Se debe dar una estimacin aproximada en cuantoal tiempo requerido investigacin y desarrollo y recursos.La propuesta de juego debe incluir una versin revisada delconcepto del juego. Informacin tcnica, marketing y finanzaspara el documento de reflexin podra obligar a reducir el


24/28

concepto. Tambin podra sugerir la modificacin o la adicinde caractersticas. Estos cambios no deben tomar a nadie porsorpresa, ya que es la primera vez que el concepto ha sidoobjeto de gran crtica y el proceso de colaboracin. Dar copias

de la informacin y el anlisis para el director de desarrollo (oquien le pregunt a la propuesta de juego) antes de que sedoblan en la propuesta de juego o efectuar cambios en elconcepto es una buena idea. Este proceso no slo proporcionauna confirmacin por escrito de que el concepto ha sidorevisado por ciertas personas o departamentos, sino de armarel director con el conocimiento de veto, alterar o de otra maneraaprobar los cambios propuestos.La propuesta de juego incluye las siguientes caractersticas:Juego revisado concepto (anterior)

Anlisis del mercadoEl anlisis tcnico

Anlisis jurdico (si procede)Proyecciones de costos e ingresos

ArteAnlisis de mercado: El departamento de marketing y / o unafirma de investigacin de mercado, asumiendo que su empresa

se lo puede permitir, debe recopilar esta informacin. Si estcompilando esta informacin usted mismo, usted debe tratar deevitar conjeturas sobre puros nmeros. Puedes buscarinformacin en Internet (www.gamestats.com es una buenafuente) y utilizar los accesos existentes en el mismo gnero quelos indicadores de desempeo del mercado.Mercado de destino: El mercado objetivo se define por elgnero y la plataforma, temas que han sido abordados en eldocumento de concepto. Usted puede calificar esta definicin al

mencionar ttulos especficos que personifican este mercado. Elms exitoso de estos ttulos indican la viabilidad y el tamao delmercado. Tambin menciona el rango de edad tpico, el gnero,ni las caractersticas clave. Si este juego consiste en unestablecimiento con licencia o es una secuela, describir elmercado existente.


25/28

Intrpretes principales: listar los de mejor desempeo en elmercado. Expresar sus cifras de ventas en trminos deunidades, rompiendo las notables discos de datos los nmeros

y las secuelas de xito. Incluya su fecha de envo. Puede servago - Q1 1998 o primavera de 1998. Esta investigacin puedeir camino de vuelta, por lo que presentar los datos en ordencronolgico.Enumere sus plataformas si varan desde la plataforma para el

juego propuesto. Sin embargo, debido a que los mercadoscambian dependiendo de la plataforma, siempre debe presentaralgn ttulo del mismo gnero en la plataforma de destino,incluso si no funcionan tan bien como los otros. Estos datospueden indicar una lentitud para ese gnero particular de

juegos en la plataforma. Por ejemplo, a su vez basados en losjuegos de estrategia pueden tener grandes ventas en laplataforma PC, pero tienen nmeros terribles en la PlayStationde Sony. Esta lista de alumnos de alto rendimiento debenindicar esta diferencia si usted est haciendo un juego deestrategia por turnos.Comparacin de caractersticas: Analice las caractersticas de

venta de estos a los mejores. Compare y contraste a lasprincipales caractersticas se describen en el documento deconcepto. Trate de proporcionar algunos detalles. Por ejemplo:Tactical Combat: En Command & Conquer, Dark Reign, y elmito, te pide tus unidades para atacar objetivos especficos y setrasladan a lugares especficos o rangos para una ventaja. Lamayora de las unidades tienen una fuerza nica y debilidadque se manifieste durante el juego, as que le animan adesarrollar tcticas superiores. Tanktics tiene una variedad ms

amplia de las rdenes que le permite aplicar tcticassuperiores, tales como la captura, ram, y hit-and-run. Posicinde la unidad y seleccin de objetivos cada vez ms importantedebido al terreno, movimiento, y las primas de pastoreo; arcosde tiro, y puntos blandos en el trasero-y el golpe lateralubicaciones. Todas las unidades cuentan con armamento


26/28

distinto, la armadura y la velocidad de diferenciar sus fortalezasy debilidades y fomentar la tctica. No slo se aprende adominar estas tcticas con el tiempo, sino que tambin puedesguin estas tcticas en pedidos personalizados.

Anlisis tcnico: El anlisis tcnico debe ser escrito por unprogramador con experiencia, preferiblemente el directortcnico o un programador jefe, y luego editado y compilado enla propuesta. Los revisores de esta propuesta utilizar esteanlisis tcnico para ayudarles a tomar sus decisiones. Seahonesto, sino que le ahorrar muchos dolores de cabeza alfinal. En general, este anlisis debera hacer que los revisoresoptimista sobre el azar del juego de xito.Caractersticas experimentales: Identificar las caractersticasdel diseo que parecen de carcter experimental, tales comolas tecnologas no probadas o no probadas, tcnicas,perspectivas, u otras ideas nicas. No incluya lascaractersticas que han sido probados por los juegos existentes,incluso si es nuevo en el equipo de desarrollo. Por ejemplo, si elequipo no ha desarrollado un motor 3D, no lo lista comoexperimental. Ms bien, incluirla en una o ms de las otrascategoras en la seccin de anlisis tcnico. Por otro lado, si el

equipo de desarrollo est trabajando en un motor 3D con elsistema terico de quads, este esfuerzo debe ser catalogadocomo experimental. Por supuesto, para cuando usted lea esteartculo, quads podra ser de uso comn.Incluyen una estimacin del tiempo que se necesita para traerla caracterstica experimental a un estado de evaluacin, ascomo una estimacin del tiempo total para completar la funcin.

reas experimentales requieren de ms tiempo en elcalendario, por lo que el ms funciones experimentales que

lista, mayor ser el horario ser. Mientras que algunascompaas evitan tales 18 - a 24-meses proyectos, muchos venestos experimentos como las inversiones que valen la pena enla creacin de vanguardia ttulos. Por lo tanto, decir las cosascomo son, pero no se olvide de decirles lo que van a salir deella. Hacer que se sientan cmodos que los experimentos


27/28

saldr bien.Las principales tareas de desarrollo: En un prrafo o unospuntos, dejan en claro las tareas de desarrollo ms importantes.Use un lenguaje que personas sin conocimientos tcnicos

pueda entender. Mayor significa meses de desarrollo. Dar unaestimacin del tiempo que se supone que tiene todos losrecursos que necesitar para llevar a cabo la tarea. Ustedtambin podra dar una estimacin de los recursos que ustednecesita. Por ejemplo:"Analizador de secuencias de comandos Artificial Intelligence:.De tres a cuatro meses con dos programadores El analizadorlee y compila los scripts de AI en un menor nivel de lgica y lasinstrucciones que se ejecutan en tiempo de ejecucin."Riesgos: listar todos los riesgos tcnicos. Si no prevn riesgostcnicos, por todos los medios decirlo. Los riesgos soncualquier aspecto de la investigacin y el desarrollo que harque un conjunto importante de nuevo (semanas o meses) encaso de que fallen. Lista de las tecnologas que, a pesar de quehan sido probados para trabajar por los competidores, lacompaa no ha desarrollado o con los que su empresa tienepoca experiencia. Lista, por ejemplo, la estrategia en tiempo

real si su equipo nunca ha desarrollado un juego de estrategiaen tiempo real antes, o 3D si esta es su primera incursin en el3D. Haga una lista de las tareas principales de desarrollomencionados anteriormente, si usted percibe ningn riesgo.Todos los inexpertos off-the-shelf soluciones (motores 3D,editores, bibliotecas y APIs de cdigo, conductores, etc) debeaparecer como riesgos porque pueden terminar no cumplir consus necesidades particulares. Cualquier desarrollo realizado porun contratista externo tambin deben ser mencionados, ya que

es siempre un gran riesgo. Al evaluar los riesgos, tambin debeindicar el posible impacto que la fijacin o sustitucin de latecnologa tendr en el horario. Indique el tiempo en semanas omeses que la fecha de envo se deslicen. Anote el tiempo deimpacto sobre los recursos especficos. Haga una lista denuevos recursos (personas, software, hardware, etc) que seran


28/28

necesarias para solucionarlo. Esta seccin puede parecerpesimista, pero crea un nivel de comodidad para los revisoresde su documento - que saldrn de all con la impresin de quela implementacin juego est bajo control, especialmente si

pueden percibir estos riesgos ellos mismos. Adems, ustedtendr la oportunidad de decir: "No puedo decir que no te loadvert".

gdd como hacerlo

Documents