Communication in Game Design (part 2): Communicating with your Development Team
In my previous post I discussed Communicating with Your
Publisher. Let’s assume you’ve cleared that hurdle, a publisher has agreed to
fund the project, contracts are signed, hands shaked, you’re good to go. Now
you have to make the game.
What do you have to communicate to the team that is actually
going to make the game? I don’t mean just generally being polite and
communicating nicely. What information about the game do you actually need to
convey?
You will have programmers writing code, writing scripts,
getting the engine to function or customizing an existing engine. They need to
know what they are coding.
You have artists that need to develop or follow a consistent
visual style and build all the assets going into the game. They need to know
what art they are creating.
Designers all need to be using the same tools, following the
same guidelines, so the game flows from one area to the next. They need to know
what content they are creating.
Everyone needs to stick to a schedule so the project gets
done, milestones met, so the money keeps coming from the publisher. So the
producers need to know how big a game you are making.
No matter how large your development team, there are a few
key documents that you will need.
For the purpose of this post, I’m using the word document
to mean information consolidated into a single place. It may be a Word
document. It make be a wiki page or Confluence page, a PowerPoint slide,
whatever method you are using to communicate your design.
To start, you need to create a High Concept Document.
The High Concept Document
There is no single correct format to any of this
documentation. It’s not like writing a screenplay for a Hollywood film, which
has a rigid standardized format. You create what will work best for your team.
The High Concept document lists all the major features of
the game. At this point you don’t need to go into details. You are describing
at a high level each of the components of the game. You establish the Design
Pillars of the game. The Design Pillars are the core foundations for the game,
the vision, and every feature should follow them.
List the genre of the game, describe the key gameplay
features, any new gameplay mechanics that will be used, the high points of the
story, key characters, descriptions of levels and gameplay areas. List any
risks associated with the design (will cinematics need to be outsourced, will
specific software be required, with the timeline to meet the final milestone be
tight, etc.).
The High Concept should be enough that teams can begin work
building prototypes of the core features.
The Pre-Production Phase
The design of the game needs to be in place before full
production of the game can begin. This is the time where gameplay prototypes
are being made, art is creating concepts for all the assets that will need to
be created (environments, objects, characters, interfaces). By the end of
Pre-Production, everything should be defined in such a way that the development
of the game can go full-steam ahead. The artists will know what models and
animations they will be making. The designers will know what levels they are
building and what the core mechanics of gameplay are. Any new gameplay
mechanics should be prototyped. Managers have a production schedule in place so
they can allocate people and meet all the goals.
The place that contains all the information to explain the
design to all these different disciplines on the team is the Game Design
Document (GDD).
The Game Design Document
The GDD contains all the information necessary to explain
the design of the game to the team that is making it. This is where you explain
each piece of the game, each gameplay mechanic, in detail. Again, there is no
rule on how the GDD needs to be formatted. It doesn’t even need to be a
document! On the first few projects I was involved with, we would print out the design document on paper and keep it in a giant 3-ring binder. It's been years since I've done that. Now, you can build a Confluence page, a wiki, PowerPoint slides, whatever
method you choose. In a later post, I’ll discuss some possible options (I’ve
used many different methods with different teams).
The GDD can be a HUGE document, and it’s easy for
information to get lost. Some projects like to boast how immense their GDD is,
and compiling a massive GDD can be a good resource. The bigger the document
doesn’t necessarily mean it is better, though. Make no mistake, you are likely
to be the only person on the team that reads your GDD front to back. The
majority of the people on your team are only going to read those parts of the
GDD that describe the features they are specifically working on.
There are a few things to keep in mind when building your
GDD.
Information must be easy to find
The first time someone on your team is assigned a feature, and they go
to your GDD to find out how to build it, and they can’t find it… they will
never look for information again. They will always just come and have
you explain it to them. On a small team, maybe that’s not a problem. But on a
large team, having to verbally explain a feature over-and-over to each person
that asks is exhausting.
Make sure you have a Table of Contents or Index that is easy
to read. Use hyperlinks and photos/mock-ups whenever possible. You want it to
be as easy as possible for someone to find the information they are looking
for.
Information must be up-to-date
The first time someone on your team is assigned a feature, and they go
to your GDD to find out how to build it, and they read the information that
describes the feature, but it’s out-of-date… they will never look for
information again. They will always just come and have you explain it
to them. This is even worse than not being able to find the information. If
they start working on a feature based on outdated information, they will never
trust anything that is written in the GDD again.
Be diligent in maintaining the GDD and keeping it current.
Update it immediately after any change to the design. Because make no mistake,
the design will change A LOT during the process of creating the game.
Information must be easy to understand
The first time someone on your team is assigned a feature, and they go
to your GDD to find out how to build it, and they can’t understand how you’ve
described the feature… you get the picture. They won’t bother trying to
read your GDD anymore.
Be thorough. Use images. Compare it to similar mechanics in
existing games. Make flowcharts, mock-ups. Don’t make them try and guess what
you’re describing. Keep it clear.
I read one GDD on a project that was written entirely in the
voice of the wise-cracking main protagonist. It was funny for a paragraph or
two, but can you imagine a couple hundred pages of features being described
like that? It was useless to anyone on the team trying to figure out what they
needed to make. That voice would be great for a Pitch or – if done well – even
a High Concept Document. But spare your co-workers the effort of trying to
decipher something like that.
Is it Set in Stone?
Absolutely not! Do not treat your GDD like it is etched in
stone. By necessity, features will shift and change during development of your
game, and your GDD will need to be updated to reflect that. The GDD is a snapshot
of the current state of the game, but expect to continually make modifications
to it.
Know the Needs of Your Team
You need to be flexible to meet the needs of your team. If
you are working on a team of several hundred people, you will have different
means of communication than if you are working on a team of ten.
I don’t like to be overly critical of other designers. I
would prefer to point out examples of good design by others, and I’ll use my
mistakes as examples of what to avoid. (Rest assured, I think I create the
occasional example of good design too). Let me give you two examples of bad
ways of communicating to your team, based on my personal experience.
The Flashlight in Far Cry
One of the first tasks I was asked to do when I began work
on the original Far Cry was to write up how the Flashlight needed to work in
the game. Simple enough, right? I mean, it’s a flashlight, everyone understands
the concept. But I wanted to be thorough.
I wrote up a three-page description of every possible
scenario I could imagine that would involve the flashlight. How did you hold it
in a first-person shooter? What kind of range should it have? Did it work
underwater? Three pages.
For anyone that was responsible for implementing the feature, this was overly complex. I also didn’t take into account was that I was working on an
international team, and for many of my co-workers English wasn’t their native
language (not to imply they didn't speak English well, they all spoke English very well. But having to read anything not in
your native language can be extra work). Having to wade through all that text
just to figure out how I wanted the Flashlight to work was a waste of their
time. It was over-kill.
I came back with a different approach. I made a bullet-point
list of about 6 items. I kept the descriptions I had already written, it was
still valid information. But I led with the short bullet-point list. If the
programmer or artist needed further information on any of the points, they
could read the more detailed description. I avoided using slang and idiomatic
expressions in my writing that might be unfamiliar. I kept it clear and
concise. This was much more useful.
Feature Slide Show for Toy Story 3
We had a huge team working on Toy Story 3 and I was
responsible for some of the design in the Toy Box mode of the game, which was a
sandbox mode with several overlapping game mechanics. We wanted to spark
emergent play by allowing players to use the handful of simple gameplay
features in creative combinations. I decided the best way to explain those features
was to put together a small Primer explaining each of the gameplay mechanics we
were going to use. My goal was to explain each gameplay mechanic on a single
page with a supporting illustration.
This was largely successful, and if you were sitting at your
desk and needed to get an overview of a particular gameplay feature, this was a
great way to understand it.
So what’s the problem?
I was asked to give a presentation to the Art team on the
features, and instead of creating a Slide Show specifically for this
presentation, I decided to use my Primer instead. I’d already done all this
work on it, and it basically covered the same information, so it should work,
right?
No. No it did not. Why?
When you give a presentation to a room full of people, you
are not going to hold their attention by putting up slides with walls of text.
Even though each slide described a single feature, some of those slides
contained paragraphs of information. Projected up on a screen like that, some
of it wasn’t even legible. It was completely useless in that setting.
I made sure that moving forward, I had the information
organized in a format better suited for presenting like that. I used concept
images and mock-ups, and kept my descriptions to a couple of bullet points per
slide. Something that they could read easily while I was talking.
Summary
You’ll notice that in both of my bad examples, it wasn’t
that the information I had written was bad or incorrect, it was that the way
that information was presented wasn’t useful to my team. You want to make it as
easy as possible for the people developing the game to get the information they
need. That is your primary responsibility for communicating with your team.
In my next post I’ll discuss some ways of communicating with the designer’s
third audience: the player.
Comments
JackpotCity Casino review, including 구리 출장안마 bonuses and 김천 출장안마 promotions. 계룡 출장마사지 Check out the casino's bonuses for new players, current bonuses, free 울산광역 출장샵 spins, 통영 출장마사지