 |
|
|
| |
ION: BlackStar Designer Reinhart On Design Doc Alternatives
by Wendy Despain, Staff
|
|
| |
|
May 16, 2008
|
| |
Speaking with designers at a 2008 ION Game Conference session, Spacetime Studios’ Brandon Reinhart, lead designer on the developer's forthcoming space MMO BlackStar presented his ideas for storytelling techniques in game design in a session titled “Narrative Design for MMOs: Using Storytelling to Craft and Convey Vision.”
Ineffective Design Documents
Reinhart began the session dismissing design documents as massive productions that poorly convey their message: “The reason I think these ‘visionary designers’ are different from us ordinary designers is that they understand the design doc is not a good way to get people to believe in what you're doing.”
He continued, “Design docs are great for making plans and scoping projects, so we can't throw them away entirely, but when you're telling your buddies -- or team mates -- about the game, you tell them about it in a story, not a wall of text.”
Allying Concepting and Design
On the idea of “narrative design,” Reinhart suggested designers work with a concept artist to more effectively communicate their vision and to limit future designer communication errors. He explained, “We already know what we're talking about, so it's easy to skip the most important elements when we tell stories.”
Reinhart went on to suggest that designers put together a 'concept request package' which references narrative material, much like a wiki. That way, the scope of the story will scale with the scope of the assets. He recommended, “Go ahead and care about little details -- don't tell a hundred stories about all the different kinds of blasters in the game, but maybe write ten stories, maybe one about the company that makes the blasters.”
Tools For Large Scale Projects
Discussing tools for keeping teams focused on large scale projects, Reinhart first advised that designers use a 'concept pyramid' to tailor their delivery by breaking vision down into its fundamental concepts and compartmentalize complex ideas.
“Start with the basic concept - space war! Then, the two parts of that - humanity and demonic aliens," he said. "When your audience is familiar with those first two tiers, move down one more level. Tech vs. magic, with idealism and destiny on one side and religious prophecy on the other. Don't use this graphic in your presentation, but keep it in mind when you're talking.“
To further tailor the delivery and also engender buy-in, Reinhart again told designers to work with concept artists and production artists to illustrate 'key moments,' images that tell a story with a single image. Pointing to comic book covers, he emphasized, “There's nothing more critical than giving your players a sense of characters. Your concept art can do that -- and it's critical in games the player doesn't already know the memes for.”
Reinhart then described a third tool designers can use to tailor delivery -- 'aspiration driven character design.' Using character art from BlackStar as examples, he stressed, “You need to make characters that players want to be.” Designers should convey the character's values without relying on words, possibly tying emotional aspects of the aspirational elements into the visual elements of a character.
The Great Law Of Conveying Vision
On conveying vision, Reinhart concluded the session by describing the concept of conveying ideas as a fundamentally social and political activity. He told designers to avoid defensiveness and admit when an idea isn’t working: “You can't afford to be a primadonna. Show confidence in your abilities, but also be humble and open to new ideas, especially when dealing with foreign partners.”
|
| |
|
|
I agree with the author. A design document is great for the nitty gritty, but to really create excitement and keep a consistent feel of the game and what it's supposed to be throughout the process, you need to have more. Visuals, graphs, stories, and a live Wiki are definitely some ways to improve the game development process.
Now, I don't know that it's common for designers to use the design documentation to try and motivate people's interest in their games, but my guess is Reinhart has experienced just that. Otherwise there wouldn't be much reason to talk about the subject, I'd wager.
I still think this "design docs = bad" (or "they don't do a good job at...") mantra is misguided. What they mean to say is *badly-written* design docs are bad - but don't throw out "design docs" as a category based on how badly people have done them in the past.
If printed material has inspired people in the past - and they have (ever read a good book or play?) - there is no reason why a design document can't do the same. After all, Dungeons & Dragons was just a bunch of rule books. Yet those books sure as hell seemed to inspire something pretty lasting.
Maybe the issue isn't design documents at all, but a generation of people who have grown up without doing much reading.
Personally, I've started to employ a different approach as well. In the industry we always joke "only designers read design docs or people interested in design;" So instead I highly recommend creating a GAME CONCEPT DOCUMENT "GCD."
The GCD is very much like what the author is proposing if not the same exact thing. It should read, if not look just like a Game Manual, but placing all the control schemes and high level systems in the back of the document. This should really hit the feeling, pillars of the game and more importantly now a days allude to a malleability and vastness of the IP beyond video games. This is the document you show your execs and team members first! Its like designing from the inside out. Your GDD will easily follow from the GCD.
Back to the Game Design Document. I've always found that making seperate systems/mechanic packages is much faster that just busting out a x pages GDD. Writing a full GDD and having your designer update it constantly is really antiquated as well. Instead use your lead designer to focus his energies on creating a working prototype in Engine with his counterpart engineers and artists.
WHY? Because a game design document never ships with the game! So move to proving your game Pillars as quickly as possible. You might find that some of the document you thought was going to be fun aren't that much fun after all.
Advice:
1) A game concept document is for the publishers or team members that can't read game design documents and game design document or packages is for the team. There are sometimes very suicidal short projects, all parties need to understand that the traditional documentation has go out the window...thinking anything otherwise is amateur.
2) The number of pages a document is does not equate to the game being fun. (yes I've hear this). Practice pitching your game from table of contents.
3) Move away from the document as quickly as possible. I've built prototypes on emails and map designs alone. Its possible, much faster and CHEAPER. If you have something playable people will quickly understand what your game is about versus reading your document. (Imaging reading a book on how to play American Football, it is not the same thing as actually tackling someone).
4) Dont argue over symantics or tables in the document. All of that is going to change once you start making a game.
5) Your prototype should have a representation of all the pillars in your game. If its not in there ask yourself why? Perhaps its not fun or not needed or its going to take x time to make.
6) Again remember not everyone is going to read your GDD so focus on making a GCD first, lots of art and narrative material. Execs, Artist etc... really don't care how many HP,DMG, Attributes or vectors that boss monster really has any.
7) Last if your dealing with someone else's IP, find out where the creative razors/boundaries are located. Can their IP become a Game? If not what concessions do they have to make? Are they willing to make them? Do the systems and mechanics you are proposing fit with your design? Figure this out before writing a document beyond 2 pages. Once they agree keep that email in a safe place.
Now, I try to write my specs in an entertaining, inspiring, and above all useful format, but it's an incredibly difficult feat and I certainly don't succeed all the time.
Sometimes, it's rhetorically a good move to have different docs that serve different audiences, so you don't have once single doc that's trying to be everything to everyone. So you have your GDD, which is the dry reference, and you have your inspirational portfolio of assets separately.
If you want more context to Brandon's talk, I took a detailed transcript of the talk at ION, you can check it out on the web page linked in my profile.