Game Engines And Feature Creep

tim-cain game-development feature-creep game-engines game-design unity unreal scope-management

Abstract

Problem: Do off-the-shelf game engines like Unity and Unreal encourage feature creep by making it trivially easy to add features that teams wouldn't have bothered coding from scratch?

Approach: Tim Cain responds to a viewer comment (Lord of Cake) and examines several common engine-provided features — creature scaling, flying creatures, dynamic lighting, breakable physics, and multiplayer — walking through the hidden costs and design questions each one introduces.

Findings: The viewer's hypothesis is correct: feature creep has become far more prevalent in the modern engine era. While feature creep always existed, the low barrier to enabling engine features tricks designers into thinking additions are "free" when they carry significant design, performance, legal, and content costs. Every feature should be evaluated against setting, story, mechanics, play spaces, and performance — not just technical availability.

Key insight: Just because you can have a feature doesn't mean you should. The question is never "does the engine support this?" but "does my game need this?"

Source: https://www.youtube.com/watch?v=vIu3IXioTsU

1. The Old Days vs. Modern Engines

In the era of custom engines (80s–90s), every feature had to be coded and tested from scratch, which created a natural barrier against feature creep. Teams had limited programmers, limited time, and limited budgets. Every feature was debated because it consumed real development resources. Sometimes teams couldn't even implement everything they needed, let alone everything they wanted, and had to change the game they were making.

Modern off-the-shelf engines flip this dynamic. Features come pre-built, and designers think "it's already there, it's free." But Tim argues that availability is not justification — you should still ask whether a feature belongs in your game.

2. Creature Scaling

Scaling is cheap and tempting: one model becomes yard trash, regular enemies, and big bosses. But Tim raises several concerns:

  • Setting fit: Do wildly different creature sizes even make sense in your world? You're deciding on variety before knowing if it fits.
  • Combat spaces: Oversized creatures clip through geometry or get stuck, letting players exploit safe spots with ranged weapons.
  • Visual quality: Scaled-down creatures have sped-up animations that look wrong. Scaled-up creatures move too slowly and their textures get smeared or repeated, prompting higher-res textures that bloat install size.

3. Flying Creatures

Another easy-to-enable feature with cascading design problems:

  • Melee characters: If enemies fly, what does a melee-only player do? Are flying creatures just untouchable for certain builds?
  • Status effects: What happens when you freeze or paralyze a flying creature? Does it fall? Stay hovering?
  • Loot accessibility: Killed flyers drop into unreachable areas — off cliffs, into water, into lava. Their loot becomes inaccessible, creating frustration and new problems for other designers to solve.

4. Dynamic Lighting

Dynamic lighting looks great but introduces performance traps:

  • Player-created lights: Even if you carefully light your levels, players casting spells with dynamic light effects can tank the frame rate unpredictably.
  • Stacking effects: Creatures with their own dynamic light effects compound the problem. Multiple light sources interacting can make scenes look bad rather than good.

5. Breakable Physics

Breakable walls, props, and ragdolling creatures sound exciting but raise fundamental questions:

  • Consistency: How does the player know what's breakable and what isn't? Visual markers like cracks feel hand-holdy; absence of markers feels arbitrary.
  • Pathing exploits: Breaking walls or props lets players reach areas they shouldn't, bypassing locked doors and designed progression. Why learn lockpicking if you can smash the wall?
  • Performance cost: Breakable objects store destruction data and break animations, increasing both storage and frame rate overhead.

6. Multiplayer

The most deceptively "easy" engine feature with the deepest hidden costs:

  • Story coherence: Does your narrative support multiple player characters running around?
  • Space design: Can your combat areas handle 5, 10, 20, or 100 players?
  • Mechanic conflicts: Abilities designed for NPCs (like paralysis) become unfun when applied to players.
  • Infrastructure costs: Servers require data centers, connectivity, power — ongoing real money.
  • Communication systems: Players need to coordinate before, during, and after play. But open communication introduces legal issues: maturity rating changes ("online interactions not rated"), and some jurisdictions require logging all player communication, including expensive voice storage.

7. The Decision Framework

Tim's framework for evaluating any engine-provided feature:

  1. Setting: Does this feature make sense in the world you're building?
  2. Story: Do you need it to tell the story you're planning?
  3. Mechanics: Is it foundational to your game's systems, or just available?
  4. Spaces: Do your game environments actually support this feature?
  5. Performance: What's the impact on load times, file size, and frame rate?

Separate features that are foundational to your game from features that are merely available. That distinction tells you whether you should have a feature, not just that you can.

8. References