Verdant

You arrive at a river bend that used to be farmland. The reeds have taken it back, there is rusted machinery in the silt, and the soil is dead. Nobody is going to fix it. You are going to fix it.

Most crafting games spend your resources on you. You gather, you craft, you get a better axe, you gather faster. The loop is a staircase and the world is scenery you climb past. Verdant spends your resources on the place. You hand everything you own to the grove, and the grove answers: plants come back thicker, new things grow that were not there before, the route you walked yesterday is greener today.

The question this prototype was built to answer is not whether the economy balances. It is does spending resources on a place instead of on yourself still feel like progress? It does. But the first version felt like a chore, for a reason I did not predict.

   ┌─────────────────────────────────────────────┐
   ▼                                                  │
GATHER ──► REFINERY ──► RESTORE ──► VITALITY ─┘
 raw        runs by      hold E at     rises
 nodes      itself       a project       │
                                                 ▼
                                    denser nodes · richer nodes
                                    new recipes · new node types

Vitality (0 to 100) is the only meta-stat in the game. No player XP, no levels, no skill tree. Restoring the zone is the progression system. Each restored project wakes a new node type and unlocks a recipe, and crossing a tier threshold raises node density, node richness and respawn rate. Density leads on purpose: it is the lever the player reads as the grove coming back, rather than as the numbers getting bigger.

Three raw resources feed a two-step refine chain into four gated restoration projects. Read in raw material, which is the only honest way to read a crafting economy:

Derived from the data tables by script, not typed by hand. Mine were wrong twice before I automated it, which is the argument for automating it.

The one input doing the most work is the Fiber in Compost. It makes Fiber contested by two separate chains, so Fiber becomes the thing the player actually feels short of. Everything follows from that: why the reeds stay worth walking past, why the Sporebloom unlock reads as relief instead of as a bigger number, why the player prefers one route over another. One extra input in one recipe. Contention is cheaper to author than complexity.

The economy runs in a simulation that reads the same CSV tables the game imports, so the model and the build cannot drift apart. Five seeds, restoration-first play.

First pass looked healthy. Full restoration in 39 minutes, tight across seeds, final project 4.2× the first, matching the 4.4× cost curve. Then I looked at where the time actually went.

The diagnosis. This is not a cost problem, it is a throughput problem. It appears the moment the chain grows a second refine step, because every craft serializes behind the last one. It is invisible in a cost spreadsheet, because the costs are fine. Shipped, it would have been reported as the late game dragging, and the late game is not what was wrong.

The fix that does not work: raise yields. Worth showing why, because it fails in a way that looks like success.

The session gets shorter, so by the usual measure it worked. But bench time stays at exactly 15.2 minutes in all three rows, because the player still crafts the same number of items. Only the gathering shrinks, so the standing-still share climbs. Double the yields and the player spends more than half the game watching a progress bar, while every number on the balance sheet improves. The fix that works: make the bench passive. Three background refine slots that run while the player keeps gathering. No cost, yield or craft timer changed.

The session got 37% shorter and the progression curve flattened, without touching a single balance number. The 4.2× to 3.2× drop is the interesting half: some of what read as the last project being expensive was never cost. It was queue depth pretending to be cost.

What I would carry into a real production: measure the player's time, not their inventory. Two economies with identical costs can feel completely different depending on what the player is doing while those costs are being paid. A spreadsheet cannot see the difference. A stopwatch can.

The loop closed in engine. Gather, refine, restore, the barrel grew, vitality went up. Then I sat down to play it and could not tell what to do next. If the designer cannot read the system, the system is not designed yet. So I tore down how six cozy games teach the same loop: Stardew Valley, Animal Crossing, Terra Nil, Spiritfarer, My Time at Portia, Dinkum. Every one of them does three things Verdant did not.

The diagnosis had five lines. The only UI showed what you had, never what you needed. The refinery had no body, so Fiber went down and Cord appeared in a text line. Spending was silent when it failed and automatic when it worked, so there was no moment of choice. Everything was a number and nothing was a place. And the tier ladder was invisible.

The fix changed zero balance numbers. Every cost, yield and timer stayed in the tables. I drew the tables on the world instead: a commission card that always names the next project and its price in raw material, a label on every node saying what it gives and what that becomes, a refinery board with a row per slot and an amber "waiting for Fiber (Cord took 3)" when one recipe starves another, project cards that shake red with "need 2 more Cord" and then read "READY, hold E", and a restore beat: the mesh grows, the banner says what changed, reeds appear, a dormant node wakes. Only one project is open at a time. The rest say what unlocks them.

The refinery board also turned a bug into a design lever. Recipes run in table order, Cord is row one, Compost is row three, and both eat Fiber. So Cord always wins and Compost starves. Before, that was a mystery in the output log. Now the board says it on screen, and the fix is a priority column, not a code change.

No balance value lives in Blueprint. The whole economy is six data tables plus a string table for every line of on-screen text, so a designer with no engine access can rebalance the game from spreadsheets and re-run the simulation to see what it did to session length, before the build is even opened.

This is a prototype, not a game, and the gaps are deliberate.

• The tool sink is in the tables and not in the build. A second place to spend, with no purchase screen, is a decision the player cannot see.
• Tier 3 is unreachable. The four projects total 80 Vitality against a 100 threshold. It is drawn on the bar in grey rather than quietly rebalanced, because the gap is real and worth naming.
• No audio. Five sound hooks exist and are empty.
• Node placement is hand authored. A seeded spawner was designed and cut. Density is pre placed and revealed per project, which is what the player reads as growth anyway.

• Update V1, the Keeper's Farm. Designed and costed: plots, water, a store, coins, land you buy and clear, a lodge you upgrade, day and night, rain and drought, birds and rats. Four sinks on one wallet, with the rule that coins buy comfort and only the forest buys progress. Building it in slices.
• Validate the tool crossover. Tools and restoration draw on the same resources, so buying a sickle slows this project down to speed every future one up. That is the only place a player can actually be wrong. The simulation never buys one, so the crossover point is designed and unmeasured. If it lands after the final project, the tool tree is decoration and should be cut or made cheaper.
• Resolve the flat second step. The cost curve runs 1.0, 1.1, 2.2, 4.4. Project two is nearly free. Either that is a deliberate teaching beat or the ramp stalls. Playtest decides.
• A second zone with different weights. Does the same chain read differently when Scrap is the abundant resource instead of Fiber? If not, zones are wallpaper.
• A depletion mechanic. Nodes that permanently exhaust unless restored, so a player can locally over-harvest. That turns restoration from a menu into a consequence, which is where the fantasy gets teeth.
• Instrument a real playtest and compare against the simulation. Where the model is wrong is where the design is interesting.