Gravity Ghost

5 Alternatives to a Game Design Doc

If you're building a game with a team, communicating the design vision in a clear manner is essential. So what does a game design look like?

The most well-known way to describe a game's systems is by writing a Game Design Document. But I much prefer to work visually, so here are 5 ways you can communicate your vision without resorting to long blocks of text.

1) Illustration

Few things can sum up your goal like an illustration of the desired result. I sent this to my team on Friday, showing the systems we're going to be building for the next 90 days:

Pencil sketch, plus a Photoshop pass for color and contrast. Done is better than perfect, as they say.

Even if you've embraced the philosophy of rapid prototyping and iteration, at each stage you need a goal to iterate towards. A visual goal can focus the team on what's important, and help the designer avoid the temptation to add extraneous features. And don't underestimate the daily inspiration such an image can provide - I've tacked up the original sketch right next to my scrum board.

2) Slide Show

What if your game needs moving parts to explain what's going on? Not to fret. Presentation software is a remarkably easy way to present the actions of a game in sequence. Here's part of a Powerpoint I made for an educational game contract I worked on last year.

The final presentation had nearly 70 slides illustrating steps in the gameplay. I made a new slide for every animating progress bar and score increase. It took me about two afternoons to put together, a small amount of time compared to the 6 - 7 week dev cycle ahead.

If you're lucky, a series of mock-ups like this can do more than explain your goal: it can energize and inspire the team to do their best work. These particular mini-presentations were popular enough that sometimes a few of the senior faculty would sit in on our meetings. The goofy placeholder art and the informal nature of the presentation invited questions and discussion. It was a real boost for everyone - and reminded us that we were making something fun.

3) Flowchart

This is an activity I have all my game design students do. I didn't invent this - I first heard about it from the wonderful Steve Swink. The idea is to diagram all the basic components of your game and visualize how they interconnect. Let's take Pac-Man as an example.

Start by writing out all the game's nouns. Most likely these are the components represented by art assets.

Then connect those nouns with the appropriate verbs. This is what the player does in the game.

Next, write out any of the higher-order relationships between various nouns. These aren't necessarily in the player's direct control, but they do serve to make the game more fun. Note the many actions that add to the game's score, and how eating has many different purposes in the game.

I hope this helps to illustrate how even a 'simple' game like Pac-Man has an elegant underlying framework. If you try diagramming your own game, watch out for nodes that don't connect to anything. Everything in the game should have a reason to exist, and this is a good way to cull the things that aren't important.

Here's the Gravity Ghost flowchart (with some exciting secret features blurred out):

More complicated than Pac-Man, but nothing too unwieldy. The interconnections in the top half of the image help to unlock progress later in the game, finally unlocking...well, you'll just have to wait and see. :)

4) Prototype

One of the surest ways to communicate your vision is to make it playable. These are screenshots of an earlier build of Gravity Ghost, a game assembled from basic geometry, a few simple scripts, and a single art pass.

The game felt very strange, and the control scheme left a lot to be desired. But a game that's really challenging can also be really fun, and I was amazed by how much the first playtesters got into it. I now had not only a playable prototype but a sense of what needed to improve.

You might think your coding skills aren't up to snuff, but please take my word on this: you don't need a lot of programming experience to make something playable in its most basic state. I started building Gravity Ghost about two months after I started learning Unityscript. My only other coding experience had been a semester of Javascript in school that I had mostly forgotten. There are plenty of resources online for this sort of thing - but don't forget that you can hit up your friends, too.

5) Cloning

One easy way to demonstrate your design vision is to steal it from a game that already exists. Keep a close eye on the top 100 paid iPhone apps, and simply copy the most successful... just kidding. Never do this. Every time you clone a game an angel smacks a puppy.

5) Illustrated Game Design Doc

If you absolutely must explain your game's systems using large blocks of text, use a visual aid whenever possible. Challenge yourself to present your ideas both visually and in words - people tend to learn better when given redundant information. For some more reading on the subject, check out Stone Librande's excellent slides about One Page Designs.

This is a screencap of what I call the Gravity Ghost "spec doc" - not a true design doc, as we're not updating it. The spec doc outlines the entire scope of the game in a broad sense - I created it to show to potential programmers. Luckily it served its purpose, and I found a programmer willing to dive into the fun world of radial planet gravity.

That's it for this week. Keep up with the action by following me (or the official Gravity Ghost account) on Twitter. Hope it's been useful!

- Erin


Ghost Ghost Evolution

The main character of Gravity Ghost is quite dead. Though her look has evolved significantly, I'm afraid her death was certain from the start. But a dead protagonist creates all sorts of character design problems. Here I'm going to talk about how her design evolved, and the unexpected role that animation played in the process.

I wish I could refer to the main character by her name, but to date I haven't come up with one that really worked. The dev team calls her Gigi (GG) for short, so that's what I'll use here.

My first batch of designs for Gigi all looked a bit like this:

If you look closely you'll see there's actually no character there at all. All we've got is an empty cape, a mask, and some inexplicably lush hair. I was quite attached to this idea that the character herself was invisible, like the ghosts that wear sheets in old movies. But a quick survey among friends revealed that my exciting new character was actually pretty confusing:

"Extremely cute and incredibly weird."

"Is she supposed to be a doll?"

"What's up with her eyes?"

On that last point, my good friend Robin Hunicke of thatgamecompany had the best advice. Without visible pupils, she told me, people would have difficulty connecting with the character. I couldn't have a character be both cold and spooky, and also relatable and empathetic. We connect with things that appear human - deviate too far from that and people start seeing something as "other."

When I tried to drop this sprite into an early version of the game, other weaknesses of the design became clear. From a distance the color palette became muddy, and the lack of a clear profile made it was difficult to tell which way Gigi was facing.

Okay, back to the drawing board. I still really liked the idea of a character whose shape was mostly suggested by draped fabric, a somewhat masochistic idea for a wannabe-2D animator like myself. I returned to my tablet and came back with this.

First thing I learned: apparently hollow blackened eyes are more of a turn-off for people than no pupils at all. But at least this design kept the darker colors blocked towards the bottom of the sprite - I figured that would help with readability, especially if she were running.

I shouldn't have been surprised that she started looking more and more like a Japanese doll, as I was sampling origami paper textures. But I wasn't happy with this one - I felt like the design was getting away from me. I wanted to try and create an original sort of aesthetic. Plus it would've been hell to animate all that detail.

Time to simplify. I hit upon the idea that Gigi could be wearing both a dress and a cloak, where the cloak would imply her arm movement and her dress would cover her legs. I started doing some sketches of a character who was very soft and fabric-y. With pupils this time.

Looking better already. The character is more interesting to look at, despite having less detail. We can read into her actions a little more, and get an idea about her personality.

But how would such a character move? I answered that question by draping a large towel around my shoulders and running through the house. Fortunately I live with three independent game developers, who aren't generally fazed by eccentricities in the name of art.

When I returned from my mission I sat down and drew these.

It was useful to conceive of the bottom of her cloak being a single line that connected her arms. You'd see more of her cloak if her arms were fully extended, and less when her arms were by her sides. I really liked the clean shapes (and later, blocks of color) that were created by her dress and her cloak.

Okay on paper, but how did my new animation look in motion?

Hey, not bad for a first try! But her movement seemed far too stiff - I felt that she had lost some of the playfulness of the sketches. And her proportions were off. She seemed less cute, so I pulled an old cartooning trick and just made her head bigger in relation to her body.

Now that she was the right size, the jerkiness bothered me. I wanted to see how she'd look with a few more frames. Using some photoshop wizardry I added tween frames until I thought her movement was smooth enough.

Hurrah! The tween frames let me see where the animation had problems. Besides the little shuffle when her right arm came forwards, there were some irregularities in the size of her cape and the positions of her knees. I decided to try penning some line art to better pin down where the problems were.

Oof, well that didn't work too well. Trying to pen lineart over a bad animation isn't going to give you a good animation as the output. Time to go back to some basics. Animation is something I taught myself over the course of making games. It was a pragmatic decision: animation is expensive and time-consuming, and I had no money and a lot of free time. Anyway, I remembered a lesson from one of the animation books that I found acquired legally from a book store. Basically, to make an animation read better, you can add some squash and stretch.

Weirdly, realism takes a back seat when you're conveying motion. Here my beloved ghost girl's head squishes down when her foot lands on the ground, and stretches up into an oval when she's headed towards the height of her jump. It may not seem like much, but look how much the top of the image is stretched down when she lands.

Much livelier. Time to start sketching in the details for real. I added some consistency to her shape, too: no more pointy corners for her hands and feet.

And now for the real nitty gritty stuff. I created these bands of color to indicate the floor, the left and right extremes of her movement, the vertical path of her head, and the low and high points of her head.

Then I started adding some nice vector lines to make the whole thing less shaggy. Here's how she looked when the head was done. The vectorization probably took the most time, as I'd never done it before. To be honest I'm not sure it was worth the trouble, as the sprite is never too large on the screen. Next time I'll probably just paint the lines and hope for the best.

As a final step I came up with a style for her hair and painted it into all the frames. I think by the end the thought of doing any more vector art was just too exhausting.

Once all the lines were in place I decided to try out a color palette. I needed something that was very different from top to bottom, so her orientation would be readable. I did a quick color pass with a light on top, dark on the bottom rule. Here's how she looks in the game as it is now. It's not finished - I have big plans for her hair, and different ideas about colors - but I'm quite happy with how it turned out.

And here's the jumpcycle too. There are fewer frames than the runcycle, but they don't play in rapid succession. Instead, she gradually transitions between these frames over the course of her jump.

And that's it! Leave your comments in the comments.

Wuv, Erin.

Filed under: Animation 4 Comments