In-game art is a strange beast. It needs to be detailed enough to look good in screenshots, but iconic enough that a player speeding by knows what's happening. Often what a player sees is different from what the developer sees. Even people watching the game over someone's shoulder perceive it differently.
An example that springs to mind is the realistic gore in Left 4 Dead 2. When I first saw the game I was struck by how much more graphic it was compared to Left 4 Dead. Yet when I played, I stopped perceiving that entirely - once a zombie was down, I never looked at them again.
Much of Gravity Ghost is spent flying through the air. I knew I wanted as much contrast between the planets and the background as possible. I've increased that contrast several times now, and it's always made the game better.
Consider this very old mock-up I did:
I began by trying to simulate a handcrafted feel. The sky and the planet are different colors as well as different values: the planet is dark, the sky is light. But just by looking, could you tell me which part of that planet you would land on? (The answer is you'd land behind the 'hills', on a round collider). What about the trees, would you collide with them, or are they just for decoration? It is visually ambiguous, which was no good.
Notice the large planet in the center. Here, I've added a texture to the round collider, so at least it's clear which part of the planet you'll land on. The other planets still have curvy surfaces though. And what do the different colors mean?
It turns out the only planets that actually do anything different are the light blue ones, which behave like water. I was trying to add variety to the designs of the planets, but I only created visual noise. People thought the red planet was dangerous (actually, nothing in the game is dangerous). And the darker planets blended right into the background, even when the game was in motion. Oops.
To get away from the texture-heavy art style above, I tried re-imagining what the game would look like with a clean vector style. This isn't bad, but the ambiguity about the collision is still there (do you land on the hills, or not? Would you think you were going to crash into them, if you were flying towards them?). And there's still some problems with contrast. The planet surface is very light, but the planet center is the same value as the background. Clearly this wouldn't solve my contrast problem. Plus the idea of doing custom art for each planet seemed exhausting.
You may remember this image from an earlier post. Here is the beginning of our terraforming mechanic. Each planet represents a different possible state for a planet to be in, having been terraformed by dirt, water, seeds, or a combination thereof. When I tried this art in the game, I discovered I really liked the way the white planets contrasted against the dark blue sky in the game. I cleaned up this art a bit and this is what we got:
Okay, so it turns out the only handy picture I had was this joke image about Gravity Ghost's secret 'bikini mode.' Anyway, the planets (sans bikini, oh la la) stayed in this state for more than a year.
This image was in our first blog post about the game, and I would look at it often. As you can see, it's shaded more like it's a sphere, unlike the white planet above, which is flat. I finally decided to update the flat planets to look round, and this is the result.
The moons are now shaded like spheres, and they have flat images overlaid for the various terraforming states. Lots of people asked me if the water planets were sawblades that were going to kill them. Video games have ruined all of us, forever.
Gravity Ghost now has some new planet types, each of which required unique art. I'm back to my initial problem: How do I create art that stands out from the background, yet is visually distinct enough that a player flying by can identify everything clearly? Other games can play with the profile of distinct game elements, but I'm afraid it's all circles for me.
Here's what the planets look like now. Can you tell what each of them does without checking the filename? If you can't guess, I don't blame you - it's an ongoing evolution. :)
We've been busy! A quick update on what we're adding now that the core gameplay is done:
Not just a title screen - everything from the save menu to the in-game UI elements now have to be added. This is a chance to add a bit of visual back-story to our ghostly main characters, Iona and Voy. Space friends 4 life! (4 death just sounds morbid to me).
This is a guardian, a magical creature charged with protecting the galaxy from unruly gravitational anomalies.
Running and jumping in an orbital space opens up some interesting gameplay possibilities, which I'm now exploring. For example, a level in which you only have one jump to collect as many flowers as you can, together with several ghostly apparitions.
Levels in the game are arranged into constellations, which you unlock as you go. You'll notice the first constellation is linear, which suits the early-game tutorial levels well. The next constellation allows you to try different levels if you happen to get stuck on one.
I ordered 200 of these babies before GDC, the Game Developers Conference, and I successfully gave away all of them. It turns out the answer to "Would you like a sticker?" is always "YES!" Even if you're a grown man. Especially if you're a grown man.
One last thing: if you never want to miss another devlog, please feel free to sign up for Gravity Ghost: The Video Game: The Newsletter here, or in the box below:
It'll also be where I post information about sales and download codes when the time comes. For now, it'll be for sharing devlog entries/puns. Good news for devlog enthusiasts/dads.
Last week I wrote about 'sketching' details of the game world with primitive shapes. Here's the same planet about one week later, and you can see some details are starting to get filled in.
For now the point isn't that it's beautiful, but that it's playable. The planet is much bigger than I first planned, but I realized the larger scale would add to the feeling of exploration. This is something I could only see by having a playable prototype - no amount of sketching on paper would have given me that piece of insight.
Speaking of working within the game, I had written some sample dialog snippets in a google doc, but they just kind of died on the page. I cut out half the words and still nothing quite worked for me. What I believe now is that I should be composing the dialog in the game itself (we have a custom dialog editor in Unity now, although it's a few features away from being fully usable).
By seeing the characters speak the lines, I'll be able to take into account the context of their surroundings - where they're standing, what objects are around them, and what's already happened in the story. I think that'll give the dialog lines the life and spontaneity they need. Writing those lines will be the next step once the world is fully sketched in.
If you're interested in keeping up with what we're doing, please consider following me on Twitter if you don't already. Whenever anything important happens with the game, I guarantee that'll be the first place I'll post it.
The original title of this post was "modular level construction," but that's not nearly as fun. :)
I'm currently adding all the necessary story beats to the game. This means having all the story locations in the game, even if they're just roughed in. The next round of playtesters should be able to play through the story, and we can see if any changes are necessary.
The game has several large 'story planets' that play like traditional platformers, albeit on a radial world. The character movement - running, jumping, riding moving platforms, etc. - was done a few months ago. All the main characters are in, and the beginnings of a working dialog system.
But how does one build structures on a radial planet? Would the people there compensate for the strange curvature of the world? Or would they build straight up and down and hope for the best? Trying to imagine how such a planet might look, I did a quick digital painting and built a level on it. The platforms are those dark red rectangles.
The big problem with this is that it's inflexible. I could move the individual trees around, but moving the platforms too much from the art made the whole thing look terrible. And the house was stuck where it was.
I tried simplifying the items I put in the game. In this image, things like the garden and the tea table are represented symbolically. And while it was easier to move the pieces around, it didn't convey the scale I was hoping for. If I couldn't figure out how to make a rough draft, how could I jump straight to the final version?
Then, while working on an unrelated system, I had a brainwave. Most systems I prototype start as cubes and cylinders - primitive geometry that's easy to manipulate in Unity and other 3D programs. Why not prototype the locations using cubes as well?
I made this house today. It's not perfect, but it does start to communicate the feeling I want the player to have as they approach and explore the house. And the nice thing is, the floors already work like floors because the platform system was already in place.
One more quick note, for people who care about aesthetics like I do. As I created the cubes, I assigned each one a colorful material. I have a small number of these that I use like paint pots - it's quick and it keeps the color palette consistent.
Building the rest of the locations should go pretty quickly now. Woo!
The very first version of Gravity Ghost was pretty bare-bones, but I noticed something about the way people played the game that surprised me. Playtesters liked to run in circles around the planets.
Old build, featuring high-tech spinning cubes.
There was no reason to run in circles. It often would have been faster to reverse direction and run the other way. Yet players kept running in circles, sometimes many times in a row, just because it played into this nice feeling of continuous motion that was already built into the game.
Enough people even said "I like running in circles" that I decided to turn it into a game mechanic. It solved another design problem I was having, which was how to give the player a simple way to choose which planets to terraform. The colorful trail behind the girl character would now have a purpose: to show you which trail type she was carrying.
I've decided to call the girl character "Iona", so let's use that from now on. There were three different trail types Iona could pick up: dirt, water, and seeds. She could now run in a complete circle around a planet with whichever trail type she picked up, and they could be layered in a crafting sort of way. Here's what the first art pass for that looked like:
Water, dirt, seeds, and various combinations thereof.
And here's what that looked like with some nicer art for the trails and planets:
The miracle of life.
Cool, so that all seemed to work. The next thing I wanted to do was twofold: have the trails be a finite resource, and have the trails be made of Iona's hair. We built a system where flowers would make her hair longer, and encircling a planet would decrease the length of the hair by the circumference of the planet. A fully terraformed planet would create more flowers.
Here's a video with the various hair trail types (I turned off the gravity visualization circle for clarity's sake):
When you see her hair length increasing spontaneously, that's me cheating with a debug button. Normally you collect flowers to make her hair grow.
You'll see that Iona's hair now responds to gravity. It's a game *about* gravity, so that should work just fine, right?
Look again. Her long hair gets spooled around the planets and seems to get stuck. It interferes with the free, flowy feel of the game. If you play this build you'll swear her hair is yanking her back down towards the planets when you jump (even though that's impossible).
But the hair has some cool features, too: it collides with the planets in a neat way, and follow's Iona's motion. Sure, it's a bit visually noisy, but there must be some compromise to make it work, right?
Nope. It was time to give up on the physics hair. Why? There was one important piece of visual feedback that the hair didn't provide, and it was so subtle it took me a while to notice what was missing.
Look back at the very first video. The trail shows exactly where you jump, creating not only those nice round shapes, but also an important visual guide. Like the dotted line in Angry Birds, it let you adjust your course and correct your aim if you missed your jump the first time. And I had totally forgotten about it.
After a good chat with our programmer Mike Stevenson, we decided to nix the physics hair and start again. I still had a problem: I wanted the hair to be a resource you carried with you, so its length would vary. But I also wanted the player to always have a long trail, to show where you had jumped. Here's the solution I came up with:
And here's what that looks like in the game now (though it's running a bit slower than normal):
We're also re-tuning the movement a bit, so we switched off her animation for now.
The feel of the game is worlds better. Running around collecting flowers to make your hair grow is strangely satisfying. It's built to make your momentum feel *good.* The hair doesn't pull in behind Iona yet, and we still have to hook it up with the terraforming system, but this is likely how the hair will behave in the final game. Art-wise, it's functional and readable, and we can tint the hair to represent the different trail types. The next time we revisit this, it will probably be for the final art polish pass.
Speaking of which, I've been trying to reconcile my love of bright colors with the fact that Iona should read as a ghost. That's the main piece of feedback I've gotten about her: she's cute, but not particularly 'ghostly.' Ghosts are typically transparent or white, and in games they're usually surrounded by animated smoke of some sort. But somehow that didn't seem right for Iona - she's very powerful, and I didn't want her to seem intangible.
With this coloration, there's much more white at a distance. But I gave her bright colors for highlights and shadows, as though the light hitting her is from some otherworldly source. I'll have more to say about this later, just thought I'd update you on Iona's ongoing evolution.
Back to the main thrust of this post, running in circles is now a core part of the game, and one that has a few more uses beyond what I've mentioned here. It wouldn't have become what it is without the input of playtesters, who found a behavior they liked and wanted to be rewarded for it in some way.
On that note, another thing playtesters tell me quite a bit is that they love trying to stay in the air for a long time without hitting any of the planets. This is on its way to becoming a game mechanic too, so stay tuned. :)
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.
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.
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. :)
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.
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.