House of Bonsai · Development update

Measure the tree, then measure the game.

A lifecycle tool learns how an untended fig grows from sapling to 80 years, the first playtest build passes its standalone checks, and profiling finds that loading a large tree, not growing it, was the slow part.

The accepted fig (calibration 9) in the lifecycle tool at 5, 10 and 20 years (top) and 40 and 80 years (bottom), grown unpruned in the ground. Each panel is scaled to fit; the thin post is a 1.75 m person. Labels compare the model with measured targets, and red marks an age with a miss. Side views from a development tool, not the game’s renderer.
The accepted fig (calibration 9) in the lifecycle tool at 5, 10 and 20 years (top) and 40 and 80 years (bottom), grown unpruned in the ground. Each panel is scaled to fit; the thin post is a 1.75 m person. Labels compare the model with measured targets, and red marks an age with a miss. Side views from a development tool, not the game’s renderer.

What the pot holds back

Bonsai keeps a tree small that would otherwise grow large, so the simulation needs to know what that untended growth looks like. The new lifecycle tool grows an unpruned tree in the ground with ideal care, one season at a time, and compares it at 5, 10, 20, 40 and 80 years with measured references for height, crown width and trunk diameter. The fig’s trunk sizes come from street figs in the USDA Forest Service’s Urban Tree Database. Between September 24 and 26 the fig went through ten calibrations. Each candidate was scored over several random growth seeds rather than one, because a fit learned on a single seed rarely held on the next.

Numbers were not enough

Two corrections came from looking rather than scoring. A version that won on the numbers kept a single central leader for decades, which a fig should not have; scoring the trunk’s fork from five years brought back a low, spreading trunk. Its limbs were then far too slender, so the model now adds wood wherever the bending stress from wind on the foliage would pass a limit. Checking the source data also showed the model had been measuring the wrong stem: the database measures a tree that forks below breast height beneath the fork. The ninth calibration, with moderate wind-driven wood, was accepted after a side-by-side review: a broad umbrella crown on a stout trunk. It still misses some targets. Its young trunk is thicker than the street figs, and its mature crown is shorter.

Knowing when to stop

A review of the Early Access plan put the project at late prototype: 5 of its 39 checklist items are closed, and nobody outside development has played it yet. A fig trunk that is 30 cm instead of 25 at ten years in the ground is a difference no bonsai player will see, so further calibration is parked. The juniper passes six of its seven checkpoints; the cherry needs recalibration.

A build other people can run

The last verified standalone package was dev.16. The source had since added an exhibition display, jin and lime sulfur, a juniper grown to a reference shape entirely through the game’s own training and pruning, a fixed viewer that turns the pot, and a redesigned interface. Packaging dev.39 exposed problems the source checks never saw: the new interface fonts broke a clean import, a data file the community page reads at startup was missing from the package, and three standalone checks still expected the old interface or an older growth rule. After the fixes, the exact ZIP passed its standalone verification with a fresh profile. It is a candidate for a small private playtest, not a public release.

Measure before fixing

Large trees were slow to grow day by day, and the plan was to freeze old wood so that only recent growth is simulated. Profiling a 1,930-part juniper first changed that plan. A game day of growth took about 7 seconds, but loading the same tree took about 18, and the courtyard reloads every displayed tree when you step back out of close care: 36 seconds with one tree, 70 with three. Most of each load went into building an editable copy of every branch the player had ever cut, 133 of them, in case one was picked up, followed by a second full rebuild.

Faster, with nothing changed

Skipping those copies would have left every cut branch as an open tube, because the copy also draws the sealed cut face. So the fixes had to leave the output identical, and every mesh on the tree is now fingerprinted before and after a change. Measuring each point once instead of once per triangle, building out-of-date copies once, letting the leaf cache survive a load, and skipping meshes that were immediately replaced took a load from 17.6 to 7.8 seconds with an identical fingerprint. The next step is to stop reloading unchanged trees in the courtyard at all.

What I learned

The slow part was not the one that had been measured. Growth was slow, but loading was slower, and its cause was a convenience rather than a calculation. A fingerprint of the output made it safe to change how the result is produced without changing the result.

Sources & development context

Based on House of Bonsai’s September 24–26 source history and notes: the lifecycle calibration records (fig calibration 9, scored over five growth seeds), the September 26 Early Access stage review, the dev.39 build manifest and exact-ZIP standalone verification, and the profile reports from the project’s tick_profile.gd harness. Timings come from one machine (Intel Core Ultra 9 185H with an RTX 4070 Laptop GPU) and one tree, the 1,930-organ juniper-02 program tree; they are development measurements, not hardware requirements. The fingerprint compares every mesh array, transform and visibility under the planted tree, plus a hash of the saved tree, with the unchanged code. Street-fig trunk data: McPherson et al. 2016, Urban Tree Database (USDA Forest Service PSW-GTR-253). The image shows the lifecycle tool’s side views, not the in-game renderer. dev.39 is not a public download.

All House of Bonsai posts