Great ideas are useless without great communication.
Great game designers will tell you that ideas -- even the great ones -- are a dime a dozen. Creating a great video game is not just about the quality of the idea. It's also about the execution of that idea. And the quality of game designers isn't based just on their designs. It's also based on their communication skills.
A huge portion of being a game designer is communicating your ideas and designs to other members of the development team. As development teams continue to get larger and larger, the importance of communication becomes greater and greater.
There are several ways designers can communicate their ideas to the rest of their development team.
5 Ways Game Designers Communicate
1. Conversation. Conversation is probably the most basic way to trade ideas back and forth. It's great because it's cheap, easy, and allows for dialog between all parties. Everyone knows how to talk.
However, verbal communication can be a double-edged sword. Some people have the ability to talk a good game about a bad idea. Others say more than they need to, giving their ideas credence simply by wearing down the other parties. And some people use volume to beat their listeners into submission.
Another downside to conversation is that there isn't a permanent record left behind of what was discussed or decided. While impromptu design meetings are great and should happen as often as necessary, having no record of what was discussed can cause huge problems later on.
Despite its pitfalls, verbal conversation remains a valuable, and most frequently used tool for game designer to communicate their design ideas. Break out a public speaking handbook, or join Toastmasters if you need to. It's worthwhile to learn to speak well, because as a game designer, you'll be doing it a lot.
2. Writing. Along with conversation, writing is probably the most common method of communicating design ideas. Most aspiring game developers have seen or heard about game design documents ("the GDD"), the infamous 400-page tome of knowledge that contains every bit of the game in minute detail.
There are a few great things about using the written word to communicate your ideas. It's cheap, and fairly quick and easy (compared to prototyping, which I'll discuss). Designers love it because they can sit at their desk, headphones adorned, and jam for hours cranking out game designs.
There are a few substantial drawbacks to the written word, though. For one, you have to convince people to read it, and some people just don't like to read, especially if the material is unwieldy. People are often intimidated by something that's 150,000 words long. If it looks too big or isn't organized in a way that's easy for the team to find the information they need quickly, they won't bother to read it at all.
One writing tool for game designers that's getting attention these days is the wiki. Wiki design documents have a few advantages over their paper brethren: they're searchable; you can parse relevant information into smaller and easier-to-read documents; and they're online, which means they are accessible from any connected device. On the downside, they can be hard to maintain. Furthermore, they can be very difficult to compile into a single GDD if you needed one.
3. Pictures. The old cliché of pictures being worth a thousand words definitely holds true in game design. With pictures, you can do rough mockups of user interface designs that will explain exactly what you want. When using text, there's a lot of room for errors, and mockups eliminate them.
In my experience, a lot of people in game development are visual learners, so being able to see an idea on paper, rather than trying to visualize it from words, works much better, especially if it's presented in a storyboard.
Since games are not static, as images are, one of the best ways to use pictures in game development is to create a series of storyboards that describe the game mechanics. Because storyboards are a step-by-step description of how a game mechanic should work, they leave almost nothing out. As I said before, simple text leaves a lot to interpretation. Interpretation has its good points, but it also can be a disaster waiting to happen.
The downsides to using pictures to explain game design ideas, is that they can be very time consuming to create. That's time that could have been spent creating other designs. As a designer, it's your job to always stay at least one step ahead of production, and sometimes speed is more important than pretty pictures.
Another downside to pictures is that some game designers (myself included) aren't particularly gifted artistically. Because of that, some visual learners may not understand the ugly "designer art" that you present to them.
4. Design Animatics. Design animatics are storyboards that move. Usually created in Flash or another simple animating tool, animatics are an outstanding method for conveying design ideas.
Games are a form of media that are generally more easily understood through showing rather than telling. Also, because video games are still fairly young, there does not yet exist a fully developed, specialized vocabulary -- a common language comprising terminology that always means the same thing to people within the community. Games have some specialized language, and some that's borrowed from film, but nothing so universal as to eliminate the need to show rather than tell.
The good news for game designers is that design animatics are now finally within our reach. Years ago, a designer would have to know a tool like 3ds Max, Maya, of Softimage XSI -- complicated tools that weren't exactly suited for creating simple animations to represent game design documents -- to create design animatics. These days, Flash and its ilk are becoming cheaper, more common, and simple enough that anyone can learn to use them. After I learned to use Flash, I realized how powerful a design tool it can be. I use it regularly to create animatics, mockup art, and figure out game balance.
For example, I recently had to work with a third party to create a simple mini-game for a product. I first sent them a written design document that explained all the features, a simple primary game mechanic, and the rewards and penalties in the game. In other words, they got a traditional GDD. They came back and told me they didn't get the idea. At first I blamed them. How could they not get it? It was a simple concept centered around a single game mechanic!
I teamed up with a producer, and together we sent them some flowcharts and some other step-by-step visual instructions. It was better, but they still didn't quite get the concept of the game. After suffering a little more frustration, I finally put together a Flash animatic that showed exactly how the gameplay was supposed to work, starting with the basic game concept, and increasing the complexity until it encompassed the entire game idea.
Success! They finally got it. A few days later they sent me back their treatment of the design that basically reiterated everything I had told them in the first hardcopy GDD. Since they clearly weren't the type of people who were fond of reading, I had to choose a better, more appropriate method to teach them how the game was supposed to behave. If I had to rely on a paper GDD, dozens of hours would have been lost trying to explain to them how the game was supposed to behave.
5. Prototypes. Prototyping is probably the best method for communicating a game idea that exists. A prototype is a simple working example of the game mechanic. Recently, rapid prototyping, or creating prototypes quickly and revising them frequently, has become all the rage, as it fits well with agile development methodologies, which have gained a huge following among game developers.
The benefit of prototyping is clear. It takes all the communication conflict and guesswork out of explaining a game mechanic. When you as a designer say you want your idea, whatever it is to work like this, and show your audience (a publisher, executives, the development team) an exact and functioning example of your idea, it's hard for anyone to say, "I don't understand how it works."
Tools that enable hobbyists and amateurs to prototype game ideas have become more widely available; these are the same tools game designers are adopting to prototype their ideas. The Torque line of game engines, Raph Koster's Multiverse, Unity, and others are all bringing one-man game development back into the reach of game designers. Designers would be crazy not to take advantage of these new tools for designing their games.
Using these tools, of course, takes a broad spectrum of skills. Count on having to learn a little programming or scripting, some modeling, some animation -- a little bit of everything required to build a game. The good news for designers is that nothing has to look or act perfectly. It just has to behave well enough for others to understand the game mechanics. Plus, a lot of these tools have pre-built assets and content packs that you can take full advantage of to reduce your workload.
Another great benefit to prototyping is that it allows designers to tweak their ideas over and over before anyone else has a chance to look at them. Not only does this save the designer time because he doesn't have to wait for other people to make tweaks he requests, but it also saves the company a lot of money that it won't have to spend in rework.
I just read an article on Gamasutra.com ("New Tricks: Scott Blackwood Talks Skate and Skate 2," by Christian Nutt, October 17, 2008) that explains a great implementation of this idea. The development team of EA's Skate designed a groundbreaking method of doing skateboarding tricks. Before they even had a game engine, they got their "flick-it" controls up and running with a simple text-based output. Even though there wasn't a skater, an environment, or even a skateboard, they could still work out the kinks in their control concept.
Of course, this method is not without its pitfalls. First off, it's still very complicated, especially for a single designer. There are very few game designers who have experience in both programming and art. More likely, as in the Skate example, it took a small team of developers to get the prototype up and running.
Compared to the other methods of communication, prototyping is astoundingly time consuming to get off the ground. If I'm describing a game mechanic in straight text, I can usually rip that out in a couple of hours. Images take me longer. Flash-based storyboards take longer still. If I'm prototyping a single game mechanic, even with help, my time estimates would probably be in the weeks, not days. Is it time well spent, though? You bet!
Working Outside Your Comfort Zone
When it comes down to it, unless you're a one-man shop, you're going to need to communicate your game designs to a group of people who will be tasked with implementing the design. The better you communicate that idea, the better the implementation of that idea is going to be. Remember that while ideas in game development are important, it's the execution of those ideas that makes a game great. There are plenty of examples of great ideas that were poorly executed. Many of us game designers have first-hand experience of that. Poor communication is often to blame for poor execution.
These ideas shouldn't be taken by themselves. Most often, you'll get the best results if you mix them. I've had great success combining pictures and animatics with text. Usually, I'll start with a text description of a game mechanic, and move on to images or animatics from there. That's a personal preference because I'm a terrible artist, and most comfortable designing in words. But it doesn't stop me from exploring other methods of design. I'm always interested in giving my team the information they need in the way they want to receive it.
As a game designer, your goal is simple: make the best game you possibly can. To that end, you should be willing to do whatever it takes.
Tim Lang is a game designer currently at Spin Master Studios in southern California. Previously, he was a game designer at Electronic Arts, where we worked on the Medal of Honor series. He started his career in game development as a level designer on several Might and Magic titles.
"Sharing the Design," Brandon van Slyke, April 3, 2008
"Types of Game Designers," Brenda Brathwaite, January 1, 2008
"Documents of newly Published Xbox Live Game Made Public," Jill Duffy, September 3, 2008
"Game Design: An Introduction," GameCareerGuide.com Getting Started material