Prioritizing Tasks

tim-cain game-development project-management prioritization bugs features production

Abstract

Problem: How should game developers decide what to work on first when the task list is infinite but time and money are not?

Approach: Tim Cain draws on decades of experience across multiple shipped titles to explain his framework for prioritizing both features and bugs, and who should be involved in the process.

Findings: Features should be prioritized by foundation first, then importance to the game's setting and story, then effort level, and finally team passion. Bugs should be prioritized by severity — crashes and progression blockers first — with input from QA on frequency and player impact. The game director, leads, QA lead, and producer each play distinct roles in prioritization.

Key insight: "No game is ever finished. It's only shipped." — accepting that the task list is infinite is the prerequisite to prioritizing effectively.

Source: https://www.youtube.com/watch?v=0ZO-YYziKV0

1. Why You Must Prioritize

Every game ships with things left undone. Tim quotes Jay Patel, tech director at Interplay: "No game is ever finished. It's only shipped." The task list is infinite — you keep adding things, noticing bugs, thinking of new features. Time is not infinite, and money is not infinite, so you must prioritize.

2. Prioritizing Features

2.1. Foundation First

Always do foundational work before anything else. Animators should do walk animations before combat animations. You can't build bartering or pickpocket systems without inventory. On every game Tim has worked on, someone has been excited to dive into non-foundational work, and you have to explain that the underlying systems they need don't exist yet.

2.2. Importance to Setting and Story

After foundations, prioritize features by how important they are to the game's setting and story. If stealing items from NPCs isn't critical to your story, it has lower priority. If your entire item economy depends on merchants, that goes higher.

2.3. Effort: Low-Hanging Fruit vs. High-Effort First

Tim sees merit in both approaches:

  • Low effort first: Knock down easy tasks quickly, especially later in development when energy is flagging — gives the feeling of getting a lot done
  • High effort first: Tackle ambitious features while excitement is high, ensuring they get the attention they deserve

Both have worked well; both have caused issues. Tim doesn't commit strongly to either.

2.4. Factor in Passion

Assigning people to tasks they're passionate about produces better games. Tim recalls arguing with a VP of Development who asked, "What kind of games would we make if we only let people work on what they liked?" Tim's answer: "Better games."

If a passionate person's task can't be scheduled early, let them know they'll own it when the prerequisite work is done. Ownership means QA knows who to go to, and the person is invested in the quality of their system.

3. Prioritizing Bugs

Tim handles bugs differently from features. You will never fix all bugs in a sufficiently complex game.

3.1. Crashes and Progression Blockers Are Top Priority

  • Crashes: No one wants to crash to desktop and lose progress
  • Progression blockers: Anything that prevents the player from finishing the game — an unwinnable character build, a destroyed quest item that blocks the main story. Even worse when the game doesn't detect it and the player continues for hours before realizing they're stuck

Tim doesn't prioritize balance very high in single-player games, though he acknowledges it's supremely important in multiplayer — especially PvP, where imbalance is unfair, or co-op PvE, where weak classes get ignored.

3.2. Bugs Can Become Features

During Fallout development, Tim built the pickpocket system by leveraging the barter UI with a flag. Because barter went both ways, QA discovered players could not only steal from NPCs but also plant items on them. When Tim offered to fix it, the QA lead said: "No, please don't take that out. We all love it. Sometimes we light dynamite and plant it on people." The bug became a beloved feature.

4. Who Prioritizes

4.1. Anyone Can Suggest

Any team member can suggest features to implement or bugs to fix.

4.2. The Game Director Filters

The game director holds the vision. If a task doesn't fit the vision, it gets zero priority — no one even has to think about it.

4.3. Leads Estimate and Assign

Leads figure out time estimates, determine who will do the work (which may change the estimate), and handle scheduling.

4.4. QA Lead Provides Impact Data

The QA lead can tell you how a bug feels when it happens and how frequently it occurs. Tim shares the Fallout crash bug story: a character outlining bug that only triggered when characters were at the bottom of the screen. Everyone in QA hit it constantly — some couldn't play more than a minute or two — but Tim never saw it because of how he scrolled the screen.

4.5. The Producer Guards the Schedule

The producer knows who is working on what and when. They're the one who catches when someone gets assigned 12 months of work with only 6 months until ship. They identify choke points and dependencies.

5. Summary

Tim's prioritization framework:

  • Features: Foundation → importance to setting/story → effort → passion
  • Bugs: Crashes and progression blockers first; consider frequency, player impact, and whether the "bug" might actually be a feature
  • People involved: Game director (vision filter), leads (estimates and assignment), QA lead (impact and frequency), producer (schedule and dependencies)
  • Universal truth: This framework works for any size team, any budget, any scope game

6. References