gdd como hacerlo
Post on 02-Apr-2018
238 Views
Preview:
TRANSCRIPT
-
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 -
7/27/2019 Gdd Como Hacerlo
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.
-
7/27/2019 Gdd Como Hacerlo
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
-
7/27/2019 Gdd Como Hacerlo
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
-
7/27/2019 Gdd Como Hacerlo
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
-
7/27/2019 Gdd Como Hacerlo
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/27/2019 Gdd Como Hacerlo
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
-
7/27/2019 Gdd Como Hacerlo
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/ -
7/27/2019 Gdd Como Hacerlo
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
-
7/27/2019 Gdd Como Hacerlo
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:
-
7/27/2019 Gdd Como Hacerlo
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-
-
7/27/2019 Gdd Como Hacerlo
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
-
7/27/2019 Gdd Como Hacerlo
13/28
-
7/27/2019 Gdd Como Hacerlo
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.
-
7/27/2019 Gdd Como Hacerlo
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 toMuseOfFireProductions@yahoo.com.
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:museoffireproductions@yahoo.commailto:museoffireproductions@yahoo.commailto:museoffireproductions@yahoo.commailto:museoffireproductions@yahoo.com -
7/27/2019 Gdd Como Hacerlo
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
-
7/27/2019 Gdd Como Hacerlo
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.
-
7/27/2019 Gdd Como Hacerlo
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
-
7/27/2019 Gdd Como Hacerlo
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
-
7/27/2019 Gdd Como Hacerlo
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,
-
7/27/2019 Gdd Como Hacerlo
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
-
7/27/2019 Gdd Como Hacerlo
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
-
7/27/2019 Gdd Como Hacerlo
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
-
7/27/2019 Gdd Como Hacerlo
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.
-
7/27/2019 Gdd Como Hacerlo
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
-
7/27/2019 Gdd Como Hacerlo
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
-
7/27/2019 Gdd Como Hacerlo
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
-
7/27/2019 Gdd Como Hacerlo
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".
top related