Wait what?

One vital thing to designing great games: Don't forget to get away from the project. There are amazing experiences outside - new scents and sights, colors, sensations, styles, spaces, perspectives, people. There are opportunities and possibilities you can't imagine until they happen. We live inside the most complex procedural generator in the universe. There's raw inspiration all around you, right beyond the doorway. If you want other people to feel, feel yourself. Expose yourself to a breadth and depth of emotion. Create vibrant memories you can call on in your design. I spent the weekend offline, consumed by feelings I could spend the rest of my life trying to capture in a game. Up and down, better or worse, depression and euphoria. This is your one life. Live it.

Project Aurora – Prioritizing Development

This is the third post in a weekly series on the progress of my latest indie endeavor: Project Aurora. The other two are on Creating a Concept and Making Design Decisions.

Why Prioritization Matters

We will never be able to create exactly the game we hope to make. We will never be able to add everything we want, to iterate as much as we should, or to polish to the extent the game deserves. Life happens. That's why we prioritize. Prioritization is incarnating your core to the best extent possible within the constraints of your environment - be they time, money, tools, people, or sanity. To me, this is the very heart of what makes an indie game an indie game. A product manager would have a very different definition of prioritization, focused on optimizing revenue, engagement, daily active users, marketability, or any number of business related goals over realizing the game's core. Regardless of company size or financing, for me an indie game is one whose creators champion the play experience over (but rarely to the exclusion of) other influences.

Production vs Design

Most schools of thought advocate having the producer and designer be VERY different roles played by VERY different people. A producer is someone who fights for the deadlines, who says 'no', and who protects the product against feature creep and randomization. A designer is someone who fights for the game's integrity, who says 'please', and who protects the user experience against quick fixes and low hanging fruit. Prioritization is the result of their constant battle. I like playing both roles. It forces me to deeply understand the impact each feature is going to have on user experience and the relationships between those features. It forces me to think on my feet when delays pop up, and be able to point and say, THIS feature is the most important of the three on your plate - do that one; that second one sets the foundation for five other features, but their impact will be virtually null if we lose this moment at the beginning. Be a responsible designer. Know the impact your decisions will have on workload and deadlines. Learn to prioritize. As Stephen King says, kill your darlings. So what does this actually look like? This is another process-that-happens-largely-unconsciously, but here's an attempt to get it down:

Figure out your influences

This step sets the stage, defining the space you have to work and what you plan on doing there. Influence is just a broad term for anything affecting your priorities:
  • Things you want to accomplish with your game (Goals)
  • Things that hold your game back (Constraints)
Here's a list of some of my major influences, and their order of importance.
  1. December 10th Deadline - This is the GDIAC showcase for my awesome Cornell team. If the game isn't done by then, they don't pass.
  2. Affective Design - The core of the game. Making people feel curiosity, wonder, solace, and smallness.
  3. Team's Technical Capacity - We've got two MEngs, one of which knows Xcode, and two undergrads. There's going to be a steep learning curve.
  4. Usability/General HCI - This is an umbrella for several goals: no text, quick to complete, holistic aesthetics (audio, visuals, narrative, gameplay all mesh together)
  5. iPad's Processing Power - As much as I want this to be beautiful, there are only so many particles or simulations the iPad can handle at a time.

Figure out your features

You've got to be prioritizing something, right? If you've already got a concept doc, you're set. If not, starting from the shiny ideal game in your head, mind the goals and constraints and come up with a reasonable feature set. Here's a few groups of features from Project Aurora:
  • Interactions: Walking, Swimming, Calling, Activating, Collecting
  • Usability: Tutorial, Touch feedback
  • Aesthetics: Aurora Borealis, Flocking Shards, Light rays, Binaural score, Dynamic shard sounds, Audio filters unique to location, Mountain top moment

Figure out your feature impact

This is my baseline for prioritization. How much is this feature going to impact the user experience? I usually average effect and frequency with some fudging. Frequency is how often the user engages with the feature, and effect is how much the presence (or absence) would affect them.
Walking Very HighMediumVery High
Swimming HighVery HighVery High
ActivatingMediumVery HighHigh
CollectingMediumVery HighHigh
TutorialLowVery HighMedium
Touch feedbackMediumHighHigh
Aurora BorealisVery LowVery HighMedium
Flocking ShardsVery HighMediumMedium
Light raysLowVery HighMedium
Binaural scoreLowMediumMedium
Dynamic shard soundsMediumMediumMedium
Audio filters unique to locationMediumLowLow
Mountain top momentOnceExtremely HighVery High
NOTE: This is a rigid structure, and I tend not to think quite so concretely. For instance, even if I have several low impact (but very cool) features, I will try to highly prioritize at least one. To me, those tiny details speak volumes about our craft. While not everyone will notice those additions, their absence, I strongly believe, is always felt.

Figure out the effort required

In college, this was called the "Awesomefort" score, and I've stuck with it since. If we think of Impact as "Awesomeness" and dev requirements as "Effort", it's pretty self explanatory (and superior to the "Effsome" score, which got us some funny looks). This doesn't normally change my priorities, but occasionally you'll be able to nix a low impact/high effort feature, or realize that you can do five low impact features for the price of one medium.
Walking Very HighLowP1
Swimming Very HighMediumP1
Touch feedbackHighLowP1
Aurora BorealisMediumHighP3
Flocking ShardsMediumMediumP3
Light raysMediumMediumP3
Binaural scoreMediumMediumP3
Dynamic shard soundsMediumMediumP3
Audio filters unique to locationLowHighP4
Mountain top momentVery HighMediumP1

Figure out your feature dependencies

In the sample list, I only had room for "walking" - but this is actually the root feature of several others: running, idling, trudging, and stopping. None of the latter features can exist without walking, so I know walking has to be prioritized first. Revise your list with dependencies in mind.

Work with your deadlines

Deadlines, for the most part, shouldn't matter. If you know your priorities, then you know what needs to be done in what order, and it's just a matter of figuring out how much of your process you can get through by what date. There might be some instances where you'd rather have features Y and Z complete for a beta and leave higher priority X until it can be fully functional and polished for a later milestone. I tend to think of that more as "temporary reprioritization" though - and stay away from it when possible. That's the first step down the long and troubled path of randomizing your devs.

Adjust for the bumps

If we suddenly realize that our walking algorithm causes the game to lag to 4 fps, we have a problem. Is it more worthwhile to spend three weeks fixing it, or nix walking altogether in favor of having a swimming only game? What about two weeks? One? As a designer, you get to draw the line.

Phew! TL;DR

TL;DR - Here's all the factors I consider when prioritizing features:
  1. Project Goals: What features best accomplish the goals?
  2. Project Constraints: What features are realistic given the time, money, people, tools, and sanity we have.
  3. UX Impact: How much will feature's presence or absence affect the user.
  4. Dev Cost: How much effort is it going to take to implement?
  5. Dependencies: What features does this unlock? Or what are its prerequisites?
  6. Deadlines: Should we put off this big feature in favor of having something more stable for a milestone?


Much love to everyone who's encouraged me to keep this up. Next week is going to be on project management. Stay tuned!

Project Aurora – Making Design Decisions

This is the second post in a scarily-open series on the development of my latest indie endeavor: Project Aurora. The first one, on creating a concept, is here.

What constitutes a design decision?

All of game design is making decisions - about implementation, priority, advice to take, playtests to do, where to stop, how to end. The vast majority of these decisions are tiny enough, or broad enough, to address with a few seconds thought, or intuition. Scary word, so let me clarify: Intuition is an informed gut reaction. It's not magic. It's not an excuse to hole yourself up and never look beyond your bubble. And by all means it is not justification to do whatever you want, however you want to, because you want to. Intuition is the rapid-cognition sum of all that you've experienced and learned, and the best designers are going to be constantly learning, constantly playing, constantly adding to that internalized machinery that automatically weighs and values choices. Great designers can all but instantaneously throw their imagination into the possibility space, seeking the optimal experience like electrons searching out a grounding wire. It's a good place to start, but please, please don't misinterpret this as me endorsing design without intention. It is anything but. For me, a design decision is a place where intuition forks into two or more viable options, or where a choice already made is confronted by playtest results, or confused looks from team members, or another dev who says 'but did you think of...' Design decisions come down to the experience. Here's one example of a design decision made over the past week for Project Aurora, and how we made it.

Movement Controls - The Choices

When thinking about controls I was lucky to have two very different and very effective examples to draw from.
  • Tap & Go (Sword & Sworcery) - In Sword & Sworcery players tap a location on screen and the avatar walks there along preset paths. If players hold a place on screen the avatar walks in that direction.
  • Swipe for Velocity (Mirror's Edge for iPad) - In Mirror's Edge, a swipe anywhere on screen to the left or right sends Faith running in that direction. Swipe up makes Faith jump, swipe down makes Faith slide. While there are several contextual variants, directional swiping is the entire input spectrum.

Movement Controls - The Process

Ultimately every decision comes down to What best upholds the core of the game?. If you didn't check out last week's post, the core for Project Aurora is a set of emotions: Curiosity, Wonder, Solace, and Smallness. It's important to note that I do 'affective design' - design to elicit specific emotional experiences. Your core probably isn't a set of emotions (but maybe it should be). The Good S&S: Waiting for the avatar to traverse its path created significant down time - time to reflect & listen, to appreciate the stunning artistic detail, to notice fairies in the forest. This would give players opportunity to cultivate the emotions I wanted (especially wonder), making sure they were feeling and not just flowing. ME: Having precision control of Faith allowed for skill mastery, heightened agency, and closed the gap between player and avatar. The fluidity of constant movement echoed the spirit-nature of the polar bear: a windblown entity gliding across the arctic. Curiosity also correlates with agency - I'm more likely to investigate if I feel like I'll have an effect. The Bad S&S: Wait time could quickly shift from interesting to agonizing, and having pre-written paths is unexpected programming overhead. ME: Overall controls were less intuitive and could get frustrating quickly in a small space trying to perform a rapid series of moves. Players should live in the world, not feel burdened by controls.

Movement Controls - The Decision

When you have two good options, take the best of both. I desperately wanted to control jumping. It made the mental difference between "I am this character" and "I am ordering this character to do things". I also wanted the enchanting 'watch-the-world' feel you get in S&S as your character strolls across the screen. So here's what we wound up with: On Land/Surface of Water
  • Swipe left or right to start moving in that direction
  • Swipe up to jump
  • Swipe down to dive (only on water surface)
Under Water
  • Hold finger + bear will swim towards it
And here's how it affected our core: Curiosity - I can go anywhere in the world my body can take me; I'm not restricted to paths, and more likely to try and get to new places. Wonder - I can dive to the depths of the ocean, around the tails of icebergs, and fully digest the scope of the world on my own terms. Solace - Negligible. Smallness - Negligible.


TL;DR - Here's how I make a design decision.
  1. Figure out the options. Give a nod to your intuition. Think about feasibility, gameplay benefits, the emotional experience, and harmony with existing elements. Only go past this point if you have more than one really good option.
  2. Champion your game's core. How does each choice contribute to your core, for better and for worse? Be honest. Live for the edge cases. Ask your programmers. Make a benefits/detriments list if you need to.
  3. Consider compromise. If you have great options, is it possible to utilize elements from both/many?
  4. Make the decision. Come on, we have milestones to hit!


The team is hard at work getting our repository set up, entering our tickets & user stories, and constructing our paper prototype. Look for an update next week with more pictures, docs, and maybe a silly video. Update! The next post in this series is Prioritizing Development.

Project Aurora – Creating the Concept

If you're like me, you love seeing how other people design. Here's the process - and the docs - from the first stages of development on my latest indie endeavor: Project Aurora.

The Spark

The idea for Project Aurora came up accidentally, the result of experimental concepting for Project Babies. Armed with a rainbow glitter texture and some semi-transparent white hills, I was in the middle of making background sprites when I had one of those awesome perceptual shifts. It wasn't happy rainbow hills - it was the aurora borealis amongst the stars, casting bright spectrums on the snow. I doodled a polar bear on it, and it stuck. At that point, it was an aesthetic - there were no mechanics, nothing beyond the look, but I loved it. The entire game was this picture:

The Core

One of the rare times I literally "dreamt this up". In the dream I was actually a seal, swimming in arctic water black as void. I couldn't go on land - but that restriction made the water feel safe, like home. I found specks of the Aurora Borealis that had fallen from the sky and called out to them to wake up, wake up! When they were glowing again, I shepherded them together, guiding them through the waters. I woke up with a vivid emotional imprint, and a head start on the mechanics. At this point, the idea was still in "bright light" stage: it was vivid and pulsing with potential, but if I looked right at it with a critical eye I'd wind up blind and stumbling until I extinguished it. Instead I felt it out tangentially, mentally testing moments instead of mechanics, building the integrity of the experience up slowly in my head so that when it came to details I'd have a foundation to stand on instead of losing it to doubt and the slippery slope towards 'generic'. I picked these out as the four main emotions (and in roughly this order) I wanted to evoke:
  • Curiosity – what is this world? Drive to explore.
  • Wonder – the stars are flickering, the water lapping.
  • Solace – I am alone. The world is dying.
  • Smallness – I am a tiny piece of a cosmic world.
They would form the core of the game.

The Feel

I had enough of a start that I wanted to get this thing made, and the awesome Kim Koskamp and I were overdue for a project together. I wrote up an official pitch doc, set the milestones, and we decided to make it happen. The first time I'd mentioned the project to her, it was still in its rainbow bubble gum art aesthetic, so her initial character concepts reflect that feel: At first we weren't even sure we wanted a polar bear. Here we switched away from the bear cub aesthetic into something more of a 'spirit' character - older, wizened, and with inspiration taken from the smooth curves and minimalism of Inuit carvings. We also snagged some help from wildlife artist Amber Hill to help make sure we had all the major anatomy points down. And after several more iterations, settled on this:

The Mechanics

Oh, right, mechanics... We had a feel we liked, a character, an idea, and a set of emotions we wanted to evoke. We knew it had something to do with collecting pieces of the aurora, but how exactly? No idea. Necessity is the mother of invention. When our intended programmer went MIA, I connected with GDIAC - the Game Design Initiative @ Cornell - and sent around an updated pitch looking for AS3 or iOS devs. I was lucky enough to get an interested team of 4. ((You'll note that I dedicated an entire page to 'important aesthetics that will require dev work' -- when the core is feeling and emotion, aesthetics play a huge role)). That meant I actually needed to know how you play this game. I broke the mechanics into the rough sections I wanted:
  • (Explore World)
  • Find Shard
  • Activate Shard
  • Collect Shard
  • (Restore Borealis)
Bouncing ideas with Kim, we knew we wanted something sound-related. Since the team was iOS, I started thinking touch screen, and sound/touch mechanics. I was drawn to the old wine glass trick - circling a damp finger on the rim to generate a tone. But that wasn't fun enough alone, so I added a melody-recall challenge mixed with connect-the-dots. What does that even mean? Good question. I’ve found the best way to unfuzzy an idea is to get it on paper – which brings us to the storyboards.

The Storyboards

I like to start my storyboards with..er.. story. If I can convey the story of a game in a paragraph, then I should be able to illustrate/storyboard each sentence and get a basic walkthrough. Right? Right. So here's the story:
The light has fallen out of the sky, into the snowy desert of arctic dunes and deep blue dark of oceans. ((setting, conflict)) * You are the eternal guardian, the tireless wanderer, the only living thing in the wasteland. ((character, mood)) * Seek the scattered remnants of the broken borealis, calling into the wind and waiting for echoes. ((purpose, mechanic1)) * The shards have forgotten their power and purpose; awaken them, resonate with them. ((mechanic2)) * Song ignites the shards of shattered aspiration, each unlocked by a melancholic melody. ((mechanic3)) * … [spoiler] ((conclusion/message)) [Image available in concept doc] *
Which brings us to the final concept doc, where we stand now. Up next on the agenda is working out user stories, getting a 30 second "feel loop" of audio for the project, and creating a paper prototype.


My process is a little different every time - and sometimes wildly - but hopefully you got a kick out of your adventure in my brain space, and stay tuned for more.
Update! The next in this series is Making Design Decisions, followed by Prioritizing Development.