AP #6: Perfectionism
Spending hours on quality that no player will notice, at the cost of features or fixes that players will.
What It Looks Like
A bug gets found. It does not break the game — it is an edge case, a visual glitch, a mathematical imprecision. But it bothers the developer. Three hours go to it. Then another three. Six hours later the bug is fixed and two planned features were never built.
Or the programmer keeps refactoring a system that already works because the code is not clean enough. Or the artist revises a sprite that is already good enough. All of it feels productive. None of it serves the game.
Burning Light’s Six Hours
Burning Light (LD36) had a developer spend six hours on a math bug. The bug was real but it did not affect the player experience in any meaningful way. Six hours went to mathematical correctness that no player would ever notice, at the cost of content that players would have seen. [1]
Six hours is 12.5% of a 48-hour jam. That is not a rounding error. That is a major feature.
Why It Happens
Perfectionism in jams is rarely about ego. It is usually about discomfort with “good enough” from developers who hold high standards in normal work, avoidance where fixing a known bug feels safer than implementing something new that might fail, or tunnel vision where deep focus on one problem makes it hard to evaluate its actual importance.
None of these are character flaws. All of them are expensive at 48-hour scale.
The Standard Shifts
In production work, six hours on a math bug might be correct. It might affect thousands of users or create debt that costs more later. At 48-hour scale the calculation is different. No one benefits from that correctness. The game ships once, gets rated once and players experience what is there.
The question for every fix is: does this get the game closer to the Definition of Done? If not, it is a Could Have. Cut it.
Fix
BP #8 — Definition of Done: explicit shared standard for “good enough” that makes the perfectionism question answerable before it consumes time.
BP #7 — Playtesting Checkpoint: external feedback redirects effort toward what actually affects player experience.