DEV Community

IdleCultivation
IdleCultivation

Posted on

A history the player can read: what an event log should record

Development covered 17 Jul 2026 to 19 Jul 2026 (commit dates).

The game keeps a Chronicle: a running account of your cultivator's life, from the day you were tested for spirit roots to whatever you did five minutes ago. It has existed for months and it was close to useless, and working out exactly why turned into one of the more interesting stretches of design work on this project.

Something happened, and that was the whole entry

Here is a fair summary of what the old Chronicle said. You brewed a pill. You completed a quest. A breakthrough succeeded. You bought something.

Every line is true and none of them is worth reading. Scroll back a week and you learn that you played the game, which you already knew. The reason is that each entry recorded the fact of an action and dropped everything that made it a decision: what it cost, what it returned, what the odds were, what state you were in when you chose it.

The rewrite went through roughly twenty families of events, and the rule for each was the same. Say what moved. A purchase names the goods and the money. A brew names the ingredients consumed and what came out, including the failures. A breakthrough attempt records the chance of success as it stood at the moment you committed, which turns a line of history into something you can argue with yourself about later. A refused action says why it was refused, which is often the most useful line in the whole list.

That last one surprised me. A log of things that did not work is more instructive than a log of things that did, because a player who was blocked at nine in the evening has usually forgotten by morning what blocked them.

The test is whether it reads as a story

The design target I settled on was that a stranger should be able to read a stretch of the Chronicle and follow what happened to you, without playing the game and without a glossary.

That is a demanding standard, and reading real output in a browser is the only way to hold it. Doing that turned up an entry that referred to an object by its internal name because one lookup fell through. Another line printed a fractional attribute where a whole number was meant. A third repeated its own clause. None of those is a fault a unit test would have flagged, because the code did exactly what it was told; only reading it as prose shows that the prose is wrong.

There is a related trick worth stealing: when the same refusal happens over and over, fold the repeats into one line with a count. A history that faithfully records forty identical failures is not more accurate than one that says it happened forty times, it is just less readable, and readability was the entire point of the exercise.

Six sects, six silhouettes on the horizon

The other visible work was a piece of pure spectacle. Each sect compound in the world now sits under a great protective dome, and every sect's dome is its own.

The gameplay argument for it is that a player crossing the map should know whose territory they have wandered into from a long way off, before any label is readable. The fiction argument is that a powerful sect obviously would shield its mountain. When those two arguments agree, the feature is usually worth building.

What each dome does is drawn from the sect's character rather than a palette swap. The sword sect's shell carries blade-shaped glints circling the rim. The alchemy valley trails cauldron smoke around its outermost ring. The iron sect throws up ember volleys. The demon sect is silver ice in layers. Same underlying effect, six unmistakable readings.

Detail has to be sized for the distance it is seen from

The first version of the domes looked wrong up close and I had trouble naming it. Far away they were fine. Standing next to one, the whole shell was a single soft blur.

The cause was that every feature of the effect was sized as a fraction of the dome, so as the dome grew on screen every detail grew with it and nothing ever resolved. Real ornament does not work that way. A carved surface has fine detail at a fixed physical size, so approaching it reveals more, not the same thing larger.

Sizing the engraving in world units rather than in fractions of the shell fixed it, and the fix generalises. Anything you can walk up to needs at least two scales of detail: one that reads from far away and one that only exists when you are close. If your effect has a single scale, it will be a silhouette or a blur, and which one depends entirely on where the player is standing.

Try it in your browser: Xianxia idle incremental game.

Top comments (0)