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.

Generalized

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!

Thanks!

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.

4 Responses

  1. Artwork looks interesting so far. I am a fan of control settings but I guess game devs often want to give the play a specific set of limitations and control options maybe blasphemous – I am not sure.

  2. Hey Owen – In this instance there are two reasons why I’d stray away from settings, but best practice in HCI would definitely agree with you.

    1) Controls can/should play a significant role in creating the experience. Allowing people to change up the controls means people are going to be getting different experiences. When the game is so compact and the emotional effect I want to have so specific, adding in a gigantic variable or set of variables like that, all of which I have to account for, fractures the design flow (and also adds dissonance to people talking about the experience after the fact).

    2) Practically, the instant I have control settings I’m suddenly forced to implement a UI – whether it’s a menu that pops when you press a button, or a title screen, or a tiny semi-transparent gear icon in a corner. That can require an entirely new artist in the worst case scenario, and at least a few new libraries for the devs to explore in the best. Our release date is 10 Dec 2011- we just don’t have that sort of time, unfortunately : )

  3. Loving these posts. The thing that particularly struck me here was your definition of “design decision” as something where the designer sees two or more viable options. The corollary here is that in theory, number of conscious design decisions when making a game should be inversely proportional to a designer’s experience. What is a “decision” for a novice (“Should jump be swiping up or down?”) is an automatic known singular path for an expert (“jump = swipe up, DUH.”). This explains why some master designers I know tell me that they just “feel” the game, or that the game “designs itself” as if they are just some kind of passive bystander — really what’s happening is that they’re making all of the design decisions on automatic because they already know most of the solutions!

Leave a Reply