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!

2 Responses

  1. Thanks again for keeping this up. As a programmer/designer I do similar things with prioritization and task lists for my personal projects, with the added bit that I like to break tasks down as granularly as possible – if I can’t have a task at 30-60 minutes of coding, it’s a red flag that I haven’t fully designed it yet in my head and I’m just handwaving through a vision. Great thing about this is that I can do all the implementation in small chunks. In the time it’d take to watch a sitcom, I can implement a new feature. Throw in commercial breaks and I can test and debug it. That constant momentum of “yes, another one off my list!” that gives me the incentive to do just One More Feature, is this wonderful surge of recurring energy into the project. Best part is that since the tasks themselves are so tiny, the barrier to entry to get started is low, so i never have a project that just sits around forever because I can never bring myself to start the dreaded Next Big Task.

    Huge takeaway for me, though, is your discussion on producer vs. designer. It’s a perspective I hadn’t considered before. I definitely still believe that on a large development team, you don’t want the same person as designer and producer for the reasons you mentioned, but you’re totally right that more designers should take on production roles on small projects and study production in order to benefit from a better understanding of the people that they butt heads with professionally :-).

  2. The tiny tasks is going to come up next week in project management, and I totally agree with you. I’d much rather have more well thought out little bites than a cake that’s too big for my mouth ; ) – for exactly your reasons: easier to start, easier to keep going, easier to get feedback and see progress.

    I think if a designer was forced to do production on a large team, there would be no time to design, and vice versa; both deserve a dedication you can’t really give them. But on small teams you get excellent insight on how all the cogs fit together, and I believe it’s made me much more responsible and empathic and just more well rounded on the whole. Totally recommend. :)

Leave a Reply