Design Fallbacks

Abstract

Problem: When game features inevitably get cut during development, what happens to everything connected to them?

Approach: Tim Cain draws on his experience from The Outer Worlds and previous games to walk through concrete examples of feature removal and the cascading consequences each one triggers.

Findings: Removing a feature is never free β€” it creates ripple effects across skills, balance, controls, content, UI, and game length. Pre-planning fallbacks in your design document is essential for managing these cuts efficiently.

Key insight: Feature cuts are not an "if" but a "when." Design your fallbacks early, document them so the team can review them, and when the time comes, pull the ripcord quickly and move on.

Source: https://www.youtube.com/watch?v=T7ToTnHj-CI

What Is a Design Fallback?

A design fallback is what you're going to do if a feature gets cut. It's not always a replacement feature β€” it's a plan for how to stitch the game back together without that feature, because features don't exist in a vacuum. They're interconnected.

Tim emphasizes that for The Outer Worlds, there was literally a section in the design document (hosted on Confluence as a living wiki) called "Design Fallbacks." Previous games had them too, just less formally structured.

Removing a Feature Is Not Free

The big point Tim makes upfront: removing a feature takes time, whether it's already been implemented or not. This cost is frequently overlooked by publishers and producers β€” especially inexperienced ones. Sometimes they know it takes time but don't want it to impact the schedule, so they act like it shouldn't.

When you remove a feature, you must:

  • Remove the feature itself (code, assets, references)
  • Stitch up everything that depended on it
  • Rebalance connected systems (skills, points, items, perks, flaws)
  • Potentially remap controls
  • Account for changes in game length and pacing
  • Accept that the time spent removing means other planned content won't get done

The Two Most Common Fallbacks

Shortening the Main Quest Line

When you cut main quest content (due to lack of time for assets, levels, testing, lighting, loot placement, etc.), the cascading effects include:

  • Game length changes β€” your publisher wanted 40 hours, now they're getting 30
  • Main-to-side-quest ratio shifts β€” Tim aims for 80/20; cutting main quests skews this
  • XP economy breaks β€” the main quest determines the minimum level a player reaches at endgame; fewer quests means lower levels, which may require increasing XP rewards across all remaining quests

Removing Maps

When a map is cut, content planned for it either disappears or must be relocated. This is why maps tend to be designed slightly bigger than needed β€” to absorb displaced content. However, moving content to remaining maps increases their density, which changes pacing and the feel of exploration.

Other Common Feature Cuts

Removing Melee Combat

If you cut melee from a game that had both melee and ranged:

  • All melee-related skills, perks, flaws, and items are gone
  • Skill point allocation per level must be rebalanced (fewer skills to spend on)
  • All melee weapons are removed
  • You must decide: do NPCs still use melee against the player?
  • Control scheme must be remapped

Removing or Changing Mini-Games

Lockpicking and hacking mini-games are common candidates for cuts. When removed:

  • Check whether the underlying skill still makes sense without the mini-game
  • Decide if there's now a minimum skill threshold instead
  • Consider resource consumption (lock picks, hacking devices) β€” how is that conveyed without the visual mini-game?
  • Remember that mini-games usually paused the game; without them, stealth pacing changes because actions like lockpicking now happen in real-time

Removing Movement Types (Swimming, Parkour, Flying)

Swimming is a good example because it requires unique animations for movement, combat, and skill use underwater, plus UI for breath mechanics. When cut:

  • Remove all swimming-related skills, perks, flaws, and items
  • Remove or relocate all underwater content (if it was designed for 3D movement, you may need a complete redesign)
  • Decide what water becomes β€” a hard blocker? Shallow wading only? Instant death on falling in?
  • If creatures can still enter water but the player can't, combat encounters break

The same logic applies to parkour, flying, or even removing a run mode (sprint bar, associated attributes and skills all disappear).

Removing Dual Wielding

Often cut for animation reasons. Without dual wielding:

  • Rebalance all one-handed weapons (they were likely balanced as "okay alone, great in pairs")
  • Remove associated perks and attack modes
  • Weapon stats like speed, noise, and ammo cost may all need adjustment

Removing First/Third Person Camera

Tim's games often started with both camera modes planned. When third person gets cut:

  • Some skills may not make sense anymore (dodging worked because you could see attacks from the side in third person)
  • In-game cinematics (dialogue, death, emotes) may need to stay in third person as a compromise
  • This is an example of a fallback that's a compromise rather than a full removal β€” you keep third person for specific moments while removing it as a general gameplay option

Removing Ammo

Ammo is deeply embedded in game balance:

  • All ranged weapons must be rebalanced (ammo type, cost, weight, reload time were all balancing levers)
  • Ammo was likely a money sink β€” removing it breaks your economy
  • For melee characters, ammo was a money source (found and sold); that income stream vanishes

Removing Encumbrance

When encumbrance is cut:

  • Rebalance attributes that affected carry weight
  • Remove related perks and flaws
  • Full pass through all items and any system using items (like crafting)
  • UI must be redesigned

Tim's Conclusion

Design fallbacks are advanced game development. You will do this on your games β€” Tim doesn't see many people talking about it, which is why he made a dedicated video.

His advice: design these fallbacks early and put them in your design document so other people can read them, comment on them, and when you need to use them (and you will), you can pull that ripcord as quickly as possible, get the work done, rejuggle your schedule, and move on.