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).
: 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 feel
ing and not just flow
: 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.
: Wait time could quickly shift from interesting to agonizing, and having pre-written paths is unexpected programming overhead.
: 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)
- Hold finger + bear will swim towards it
And here's how it affected our core:
- 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.
- 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.
TL;DR - Here's how I make a design decision.
- 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.
- 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.
- Consider compromise. If you have great options, is it possible to utilize elements from both/many?
- 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