Does More Dev Time Mean A Better Game?

Abstract

Problem: There's a persistent myth in game development that more development time automatically leads to a better game. Is this true, and what problems can't be solved by simply extending the schedule?

Approach: Tim Cain draws on decades of experience shipping games — including his own at Troika Games, which he feels all shipped in alpha — to examine when extra time helps and when it doesn't.

Findings: Extra time helps fix bugs, incomplete features, and optimization issues. But it cannot fix bad design (incomplete designs, mismatched features, trend-following), production mismatches (wrong team skills, bad estimates), or discoverability problems. These require recognition and course-correction, not just more calendar days.

Key insight: Time is only useful if you know what's wrong. If your design is fundamentally flawed, your team skills don't match the game's needs, or you're chasing trends, more time just means more time wasted going in circles.

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

The "Yes" Case: When More Time Helps

Many games ship too early and fail for three fixable reasons:

  • Incomplete features — the game is simply unfinished
  • Bugs — especially crash bugs that make the game unplayable
  • Lack of optimization — performance below acceptable thresholds (e.g., sub-30 FPS)

Tim puts all three Troika Games titles (Arcanum, Temple of Elemental Evil, Vampire: The Masquerade – Bloodlines) in this category, saying he feels they all shipped in alpha. He contrasts this with studios that have "war chests" — enough money from previous successes to self-fund until the developers themselves say the game is done — versus most studios that are beholden to publishers who pull the ripcord when the money runs out.

Tim notes that publishers often figure if one game underperforms, they have a dozen others coming. The reputational damage falls mostly on the developer, not the publisher. The result: developers crunch to squash as many bugs as possible before an externally-imposed deadline.

The "No" Case: Three Categories That Time Can't Fix

Bad Design

Tim identifies three subcategories of design problems that no amount of extra time will solve:

Incomplete design — not incomplete implementation, but incomplete design. Examples include:

  • Story holes where something should be explained but the game just jumps forward
  • Rushed endings where the final levels clearly had less attention than the opening
  • Player builds that can't finish the game (requiring specific skill levels in lockpicking, speech, or combat with no alternatives)
  • Unbalanced skills so severe that certain builds are literally unwinnable — not just suboptimal, but broken

Mismatched features — well-implemented features that don't belong in the game at the design level. Tim's examples:

  • Parkour in a game where the player can fly — why climb when you can fly?
  • Crafting in a game where the best items are drops or purchases
  • Crafting in a far-future setting where everything is built by nanofactories — it creates dissonance when you walk up to a workbench and hammer out a laser pistol

If you don't recognize these features should be cut, all the time in the world won't make them mesh.

Trend-following — chasing whatever feature is currently popular. The longer development takes, the more trend-chasing cycles occur. By the time the game ships, players have either seen the trend done better elsewhere or are simply burned out on it.

Production Mismatches

Two production-level problems that extra time won't solve:

  • Team skills don't match the design — wanting a combat-heavy game without strong combat designers, or a horror game without skilled lighting artists. You end up with pitch-black levels or sewers lit like the surface of the sun. This isn't about bad developers — it's about the wrong fit.
  • Bad estimates — if the original time estimates were wrong and you haven't corrected the underlying estimation process, you'll just get another round of bad estimates. Especially deadly when combined with mismatched features: you fix one feature, players complain about another, you fix that, and the first one breaks again. You're going in circles.

Discoverability

With 25,000+ games releasing per year, making your game findable is a completely separate problem from making it good. Extra development time is orthogonal to discoverability. Worse, the money spent on extended development often comes directly out of the marketing budget — the very thing that would help players discover the game exists.

Tim's Recommendation

If you got your extra time, shipped the game, and it still didn't sell: recognize that development quality and commercial success are separate problems requiring separate solutions. Tim references his video on what to do when your game doesn't sell — a situation he's personally navigated multiple times.

References