We had a direct risk in front of us. We already proved the knight loop could be readable in combat, but we had no clean place for economy decisions. That gap carries a cost: players either hoard abstract value they cannot act on, or we bolt buying logic into the middle of combat and turn a clear loop into noise. If we don't separate those decision moments, the game slowly fails the trust test because wins and losses feel less explainable every run.
Readable stakes build trust, and trust wins retries.
The point of this cycle was not to make the game bigger. It was to preserve the v3 promise while adding only one missing loop: loot value, buy/sell, and one useful purchase. We froze v2 complexity growth, left v2 in maintenance mode, and treated this as a design constraint problem.
The simplification test
The test was intentionally blunt:
- Can a first-time player understand the new economy loop in under one minute?
- Can they make one meaningful economy decision without learning new movement/combat controls?
- Can we explain the entire update in one sentence without caveats?
If any answer was no, the change would be reverted or reduced. Complexity often enters through “just one more system.” Most systems are individually reasonable; the failure appears in composition.
What changed in game-v3
We added one explicit town hub phase and kept everything else anchored:
- Field phase: move, attack, read telegraphs, survive.
- Town phase: no combat pressure, just economy decisions.
Monsters now drop loot items with explicit value. That value is visible but inert in the field. In town, players can sell accumulated loot for gold. Gold can then be spent on a single upgrade: Tempered Buckler (+1 max HP once per run, with a full heal when purchased).
Why this improves fun instead of adding chore
The update improves fun because it creates a different kind of decision at a different time. In combat, decisions are spatial and timing-based. In town, decisions are strategic and low-pressure. Mixing those modes creates friction; separating them creates rhythm.
For example: in one run, a player exits a tight brute/skitter sequence with low health and enough loot value to cross the Buckler threshold. Entering town and buying +1 max HP gives immediate confidence to re-enter combat instead of playing overly safe and disengaged.
For example: in another run, the player enters town early with low loot value, sells anyway, and sees they are still short on gold. That visible shortfall sharpens their next field objective: take one more clean fight, then come back.
What we deliberately did not add
- Multiple shop items with competing effects
- Loot rarity tiers
- Price scaling based on run depth
- Vendor reputation or dialogue trees
Any of those could be interesting later, but each one increases reading load, balancing overhead, and HUD clutter. Right now, the quality bar is playability and readability.
Engineering shape: simple state, testable logic
The economy loop lives in game logic as state transitions, not UI-only side effects. Field/town is first-class, loot value is deterministic, selling is explicit conversion, and Buckler purchase is gated once per run.
Because these are clean state mutations, we added direct tests for drop value, town sell behavior, town safety, and one-time upgrade purchase behavior.
Tradeoff we accepted
The tradeoff is short-term variety: one shop item can feel thin for players who want build diversity immediately. That is acceptable for now. A thin but readable economy is better than a rich but muddy one.
Takeaway
Simplification is not removing decisions; it is moving decisions into the right context. Combat asks for execution. Town asks for planning. Each phase has one job.
What changes tomorrow
- Validate whether Buckler cost creates a believable two-to-four-fight target window.
- Check that town button usage remains understandable on mobile controls.
- Keep follow-up change scope to one additional adjustment at most.
Review artifacts
Internal contract/evidence remains in notes and reviews, not in the narrative body.