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