Module 5 · The HD era and indie (2005–2012)

Indie production: scope, realism, postmortems

Making a game is not the hardest part; shipping it is what kills you. And that is decided by scope: an unreleased game has zero quality and zero marketing. The core indie skill is cutting scope to fit your margin of safety, while fighting a systematic underestimation of schedules.

~16 min🛠 production + 💰 economics

The gist in 30 seconds

The #1 killer of indies is scope: the project swells, and money/time run out before release. Worse, game development is R&D: "is it fun?" cannot be estimated, only discovered by building it — so schedules are systematically low (the planning fallacy, real time ≈ 1.5–2× the estimate). The survival skill: find the fun in a vertical slice first (one polished sliver that proves the loop), cut everything that does not serve the core loop, and budget estimate×1.5–2 against your runway (savings / burn). The market is also a barbell: AAA budgets went from $10–20M (2005) to $100–200M+ (2015), the mid-tier died out (LucasArts closed in 2013, Telltale in 2018) — leaving blockbusters or cheap indie, with innovation moving to indie. The cases: Braid (3 years, $200k, one mechanic in depth), Stardew (4.5 years solo — over-scope that survived, but that is a survivor), the crunch of Super Meat Boy ("Indie Game: The Movie"), No Man's Sky (over-promise → redemption through patches). And the postmortem — a structured learning cycle that turns experience into transferable lessons.

The mechanism: why scope decides everything

An unreleased game has no quality, no audience and no revenue — so scope gates everything else. The indie graveyard is packed with beautiful over-scoped projects that never shipped. Three forces make scope lethal:

The planning fallacy — why game estimates are worse than usual

Game development is R&D, not execution: the central question, "is this fun?", cannot be planned, only discovered by building it and playing it. That is search, not fulfilling known requirements. So estimates run systematically low even for veterans (Hofstadter's law: "it always takes longer than you expect, even when you account for Hofstadter's law"):

T_{real} \approx k \cdot T_{est}, k \approx 1.5 - 2

The more unknowns there are (a new genre, a new mechanic, "find the fun"), the higher $k$ goes. Budgeting $k = 1$ is planned bankruptcy.

Runway — how long you have until zero

For an indie (especially solo) the budget is time until the money to live on runs out:

runway = \frac{savings}{burn} = \frac{54}{3} = 18 months (in $k/month)

You have to ship before the runway hits zero. So a safe estimate is ≤ runway / $k$ = 18 / 1.7 ≈ 10.5 months. If the project "feels like" 12 months, it is really about 20, and you drown halfway. Hence the indie rule: estimate the scope, then cut it in half, then do it again.

The vertical slice — find the fun first

The main weapon against scope is the vertical slice: one small but fully polished piece of the game (one level, one loop) that proves three things at once — fun (the core loop really is fun), feasibility (you can build it technically) and sellability (you can show it to a publisher / bank wishlists with it). This is Miyamoto's "find the fun first" / "30 seconds of fun": make the core loop fun on a minimum first, and only then multiply content. The opposite is horizontal development (many rough levels): it burns runway on content for a loop that may not be fun at all. Scope = features × polish × content, and all three are squeezed into the box of your runway.

The barbell market — why indie exists at all

AAA budgets escalated: ~$10–20M (2005) → $50–100M (2010) → $100–200M+ (2015). A $30–50M game that earned $100M came to count as a failure (too little ROI on capital) — and that is how the mid-tier died (LucasArts closed in 2013, Telltale collapsed in 2018). Publishers greenlight either blockbusters ($100M+) or cheap indie (<$5M); there is no middle. Innovation moved to indie precisely because there the risk/reward is balanced: a small scope is a small bet.

🕹 What to play and watch — and what to notice

Production is visible not in the gameplay but in the story of how it was made: watch the documentaries and postmortems, and inside the games themselves notice the trace of scope decisions.

"Indie Game: The Movie" 2012 · a documentary · crunch and burnout

Production reality filmed directly: Team Meat (Edmund McMillen + Tommy Refenes) crunching for the XBLA "Game Feast" deadline (finish in a month) — at the cost of McMillen's marriage and Refenes' health; Phil Fish and the five-year Fez saga; Jonathan Blow on Braid. Crunch here is not valor but a failure of scope planning.

🎮 Watch: "Indie Game: The Movie" (it is on Steam). Notice that nearly all of the drama is about scope and schedule, not code: features that cannot be cut, deadlines that cannot move, and a runway that is melting.

Braid 2008 · 3 years, $200k · one mechanic in depth

Jonathan Blow put in ~$200,000 of his own money over 3 years (mostly for artist David Hellman and for living costs). The scope is narrow and deep: a single idea — manipulating time — explored to the bottom instead of a heap of mechanics. The reference case for "depth, not breadth".

🎮 Play: get through a couple of Braid's worlds and notice that the whole game is one mechanic (different rules of time) taken to its limit. That is scope discipline: not 10 systems half-done, but one done to the end.

Stardew Valley 2016 · 4.5 years solo · over-scope that survived

Eric Barone made it alone over ~4.5 years (≈10 h/day, 7 days a week): design, code, art, music, writing — all himself. A gigantic over-scope for a solo dev — and a hit. But it is a survivor: for every Stardew there are thousands of over-scoped indies that died unreleased or unnoticed.

🎮 Play: take stock of the volume (farming + cooking + fishing + mines + relationships + seasons) that one person built in 4.5 years with almost no days off. Ask yourself: is this a model to follow — or a warning about the price of over-scope? (Hint: both.)

No Man's Sky 2016 → · over-promise → redemption through patches

Hello Games over-promised (Sean Murray was compared to Molyneux) and shipped without half of what had been shown — "the poster child of a failed launch". Then years of free updates (multiplayer, bases, VR) turned it into "the greatest redemption arc". Scope vs hype: promising is easy, shipping is not.

🎮 Play / read: launch today's No Man's Sky (the redeemed one) and compare it with what was written about the 2016 launch. Notice the gap between the promised scope and the shipped one — and how many years it took to close it after release.

Deep end · production: the vertical slice, feature creep and crunch as a symptomskippable

Scope control is a set of engineering practices, not "work harder".

Vertical vs horizontal

A vertical slice is one piece at final quality through every layer (gameplay + art + sound + UI): it proves the fun and removes the risk before you have invested years. Horizontal development (many rough levels) proves nothing: the loop may turn out boring, and the runway is already burned. So professionals build vertically: is it tasty first, then scale.

Feature creep and "kill your darlings"

Every new feature multiplies not only the work but the integration complexity (testing, balance, bugs at the seams). The discipline is kill your darlings: cut everything that does not serve the core loop, however much it hurts. "We could add" ≠ "we should add": every feature steals runway from polishing what already exists.

Crunch is a bug, not a feature

Crunch (as at Team Meat) is almost always a symptom of failed scoping/estimation, not heroism: something impossible was planned, and the team's bodies pay the difference. Sustainable production is the right scope from the beginning, not a heroic finish. Same as in ordinary software: a death march is a planning failure, not valor.

Deep end · economics: runway, the barbell and the power-law tail of outcomesskippable

Indie money lives by three harsh laws.

Runway and funding paths

Savings (self-funding): Braid (Blow's $200k), Stardew (Barone lived on savings plus a part-time job) — full control, full risk, a hard runway.
Kickstarter: money up front from players (Double Fine $3.3M, Star Citizen $10M+→$100M+), but a public promise of scope that presses on you later.
A publisher: money plus marketing in exchange for a share and control; you need a vertical slice to even start the conversation.
Early Access: revenue funds the rest of development (Vampire Survivors), but it also binds you to people who have already paid.

The barbell and the "death of the mid-tier"

AAA going from $10–20M (2005) to $100–200M+ (2015) squeezed out the middle: a $30–50M game earning $100M is a "failure" by ROI. Only the poles are left: a blockbuster or cheap indie. That structurally pushes toward small scope — not out of poverty but because a mid-sized budget cannot survive economically.

The power-law tail

Indie outcomes are extremely power-law (as is visibility on Steam): a handful of hits take almost all the revenue and the median is ≈ zero. That changes the strategy: you are managing a portfolio of bets and the risk of ruin, not "the average outcome". Small scope = a cheap bet = more attempts before the money runs out; over-scope = one expensive all-in bet.

Analogy

Making an indie game is a solo expedition to the pole on a fixed ration (your savings = the runway). Scope is how far you plan to walk. What kills you is not the cold (quality) or the beauty of the route (marketing) but a route longer than your rations: you freeze in the snow without reaching the place that was worth filming. Survival skill #1 is planning a route you can walk on the food you have, and adding detours only if rations are left over. The vertical slice is a short test excursion: check your gear and your pace before staking the whole season.

Why it matters

In indie, shipping is the hard part, and scope decides whether you ship. The graveyard is full of beautiful over-scoped games that never came out. The skill is hard scope discipline under the planning fallacy: find the fun in a vertical slice first, cut everything that does not serve the core loop, and do the math for reality (estimate × 1.5–2 against the runway). It is the same discipline that saves any R&D project — including ML — from dying in the long tail before it delivers anything at all.

🔁 Beyond games — where this transfers

The lesson is scope discipline under uncertainty: the planning fallacy in R&D, a vertical slice instead of a horizontal one, runway as a hard boundary.

ML / AI (your domain): ML projects are a textbook victim of the planning fallacy and scope creep: "we'll just train a model" swells into data, evals, infrastructure and an endless tail of edge cases. "Find the fun first" = the smallest end-to-end baseline / vertical slice of the pipeline at tiny scale first, and only then scale up — a dumb working baseline beats a half-assembled grand model. Research is search (you do not know whether it will work until you try, exactly like "is it fun?"), so schedules are unreliable: time-box it and de-risk the riskiest unknown first (does the idea work at all?). Postmortems = blameless retros and experiment logs; the power-law tail of outcomes = managing a portfolio of research bets (most will fail, a few will carry everything). Baseline-first is exactly the discipline that saves an ML project from dying in the tail.

Startups: MVP, runway, "default dead", "do things that don't scale", the vertical slice = a demo that proves the loop; cut features to fit your burn.

Any software/R&D: the planning fallacy and estimate×k; a vertical slice versus "let's build all of it roughly"; a death march / crunch = a planning failure, not valor.

The principle: under uncertainty the winner is not the most ambitious plan but whoever shipped: de-risk the unknown with a vertical slice, cut scope to fit the runway, do the math for reality.

🔧 Run it and poke at it — on your home machine

What to watch is above (🕹). This part is about trying scope discipline on yourself.

🔧 Poke at it (a scope draft) ~40 min

Take a game idea (yours or a favorite) and compress it into a vertical slice: one core loop, one level, one enemy — what is the minimum that proves it is fun? List the features, estimate the schedule "by feel", multiply by 1.7, and set it against an imagined runway ($X of savings / $Y a month). What has to be cut to ship before zero? That is the real producer's exercise.

🧪 Postmortem (with analyst eyes) ~15 min

Watch one GDC postmortem (or read one in the "5 things that went right / 5 that went wrong" format) and extract the scope lesson: where they underestimated, what they failed to cut, where crunch was a symptom. Then do a mini postmortem of one of your own finished projects (not a game — anything) in the same format, and notice whether the same scope mistake keeps repeating.

Checklist: compressed an idea into a vertical slice; computed estimate×1.7 against runway and cut the excess; mined somebody else's postmortem for a scope lesson; wrote your own "5/5".

Connections

foundation

Steam and launching — scope decides whether you survive to release; visibility decides what happens at release. Outcomes are power-law in both: shipping is not enough, you still have to break through.

foundation

Engines — the engine you pick sets your iteration speed and therefore how much scope you can get through on your runway.

adjacent

F2P economics — "games as a service" (2012+) moved the indie goal from "sell copies" to "retain": another axis of scope, with post-release support as part of the budget.

Questions worth asking

Why is it scope that kills indies rather than quality or marketing?

Because an unreleased game has zero quality and zero marketing — it does not exist. Scope is the constraint that gates everything else: run out of money or time before release and it does not matter how good the idea was. Cutting scope = surviving to the point where quality and marketing start to mean anything. So of all indie skills, scope discipline comes first: ship first, then polish and sell.

Why are schedule estimates worse in game development than in ordinary software?

Because game development is R&D, not the execution of known requirements. The central question — "is this fun?" — cannot be estimated in advance, only discovered through iteration (search, not fulfillment). Ordinary software more often implements a known specification; a game discovers its specification through prototypes. Search is unpredictable in time by definition, so the planning fallacy compounds: the more "find the fun" there is, the higher the multiplier

k

. Hence the rule "estimate it and cut it in half".

Stardew was over-scoped and it hit — so over-scope works?

That is survivorship bias. Stardew is visible precisely because it hit; thousands of equally ambitious solo projects died unreleased or unnoticed — and you do not see those. Barone also paid an extreme price (4.5 years at 70 h/week with almost no income). Planning on "I will be the exception" is not a strategy: scope so that you survive with high probability, and let the upside happen on its own. Hits are about managing the risk of ruin, not about copying survivors.

The vertical slice — why bother, if you have to build the whole game anyway?

Because it answers the only question that matters early — is the core loop fun, can you build it, can you sell with it — at minimal cost, before you have sunk years and money. Horizontal development (many rough levels) answers none of that: you burn runway on content for a loop that may turn out boring. A slice also de-risks funding (you can show it to a publisher / bank wishlists). Prove it is tasty first, then scale — otherwise you may be scaling garbage.

A postmortem is just reflection. What is the engineering point?

It is a structured learning cycle that turns one-off experience into transferable rules. The "5 things that went right / 5 that went wrong" format (a Game Developer classic) forces honesty and surfaces systemic causes rather than "bad luck". In effect it is a blameless retro applied to creative R&D: without it a team repeats the same scope mistake project after project. The engineering value is accumulated calibration: your multiplier

k

and your nose for feature creep only get sharper through honest postmortems.