DEV Community: IdleCultivation

Four rounds of review on my own work, and what each caught

IdleCultivation — Sun, 18 Oct 2026 04:30:10 +0000

Development covered 4 Sep 2026 to 6 Sep 2026 (commit dates).

Working alone means nobody hands your change back. Review is not something that happens to you, it is something you schedule, and if you schedule it badly it turns into rereading your own diff and nodding.

Over the last few weeks I have settled into running several rounds on anything non trivial, and this stretch produced enough data to say what each round is actually for.

Round one finds the obvious, and that is not the point

The first pass catches the things you already half knew: the case you did not handle, the message you left in developer language, the value you meant to make configurable.

If review stopped there it would still be worth doing, and it would also be roughly what a careful person catches while writing. The rounds that pay for themselves are the later ones, and what they find is a different category entirely.

The valuable category is damage you just caused

The single most productive rule I have: after applying a batch of fixes, review the batch, not the original problem.

One night this week that produced seven separate issues, all introduced by that same evening's fixes. Not regressions in old code. New problems created by the repairs, in the hour after they were written, by someone who was concentrating.

The sharpest one: a fix I had recorded as landed had not landed at all. The edit was matching a piece of text that an earlier reformatting had changed, so it quietly applied nothing, and the commit message went on describing behaviour that did not exist. Everything downstream then reasoned from that description. A later round only caught it because the reviewer went to the running code instead of reading the note.

Another was two thresholds that were supposed to be the same number and were not. One value decided when a cooldown was considered finished, another decided when the button lit up. They differed slightly, so when a cooldown hit zero, roughly half the buttons stayed dim, which reads to a player as an input that did not register. Those duties are how a disciple climbs towards an Elder's Seal, one rank at a time.

Change the reader, not just the day

The thing that makes a later round productive is that the reader is different. The same person, on the same day, with the same idea of how the change works, finds the same things they found the first time.

I get this by varying who reads: a different model with different habits, or myself after enough time to have lost the mental model. A reviewer who has to reconstruct how it works will question things the author never thought to state, and the questions are the value. Half of what these rounds turn up starts as "why does this compare against that?" rather than as a found defect.

Silent no-ops are the recurring shape

Almost everything the later rounds catch fails quietly. The fix that did not apply. The two thresholds that nearly matched. A configuration override read before the thing it overrides exists, so the override never takes. A guard whose suite was already failing for an unrelated reason, so the checking process skipped the whole file and nobody saw the guard go dark.

None of these produce an error. All of them produce a system that behaves slightly differently from every description of it, including the ones you wrote yourself an hour ago.

If I had to compress the whole practice into one habit, it would be this: before you believe a fix, look at the running thing rather than the record of the change. The record is a claim about the past. The behaviour is the only evidence. What they pay is counted in Contribution Tokens, which is why a dim button matters.

Sect duties are waiting: take one on in your browser. Older posts are collected at Cultivation Game.

Hiding what a player cannot use yet, without hiding the quest

IdleCultivation — Sat, 17 Oct 2026 04:30:09 +0000

Development covered 30 Aug 2026 to 4 Sep 2026 (commit dates).

Progression games accumulate lists. As Myriad Immortal Sect filled out, the market, the sect exchange, the formation board, the treasure racks and the alchemy bench all became long, and most of what was in them belonged to a stage of the game the player would not reach for weeks.

That is not richness. It is a wall of things you cannot buy, cannot make and cannot use, with the three you can somewhere in the middle of it.

Filtering is the obvious answer and it is wrong

My first instinct was to show only what fits your current realm.

Two things break. You lose the view of what is ahead, and looking at what is ahead is a large part of why anyone plays this kind of game. And you cannot see the good stuff arriving, which is a real reward in itself.

So the shape is not a filter, it is a fold. Items far above your realm collapse into a single card that says how many there are, and the horizon is a setting rather than something baked in, currently two realms ahead. Near-future items stay visible, because they are the ones you are working towards. Distant ones become a number you can open when you are curious. What counts as two realms ahead depends on how the realm ladder works, if you are new to it.

One component does this for all five lists. That matters more than the rule itself, because if each screen implements its own version, the sixth screen will get a slightly different one and the game will feel arbitrary. The bench is the one deliberate variation: it folds, but it does not reorder, because the order of recipes there carries meaning that sorting would destroy.

The exemption that makes it safe

Then the obvious hazard, which I want to state plainly because I nearly shipped it.

A quest tells you to obtain a particular item. The item belongs to a realm above your horizon. The list folds it away. The game has now told you to find something and then hidden it from you, and the player is not wrong to conclude the game is broken.

So anything named by a quest you currently have open is never folded, whatever realm it belongs to. Objective or reward, it stays visible, in every list.

The general rule I would give anyone building progressive disclosure: your hiding rule needs an escape valve keyed to what the product is currently asking the user to do. Static rules about relevance are always wrong for the user who has just been given a task. The formation board is one of the five lists, and the formations and arrays guide shows what lives on it.

A small language trap on the way out

The fold card says how many items are hidden. In English, with one item, it read "1 more items."

Plurals are a real grammar feature and not a string with an s on the end. English needs one extra form here, and the other ten languages the game speaks each need their own rules, some with more forms than English has. Every list in the game now goes through that, which took an afternoon and removes a whole category of small embarrassments.

Also this week

A round of work on refusals, prompted by watching real sessions. A Sell button was pressable on a row whose price could not be worked out, and pressing it went through, so the player learned what they had sold by reading their own history afterwards. Another panel kept the balance it had before a refusal rather than the one the refusal reported, so every later message about being short of funds was quoting a number that was not true.

A refusal is a message. If you throw away the information it arrives with, everything you say after it is guesswork delivered with confidence.

Free to start, no install: see the folded lists in your browser, with more notes at Myriad Immortal Sect.

Width is not the viewport, and 800x600 is not a desktop

IdleCultivation — Fri, 16 Oct 2026 04:30:10 +0000

Development covered 29 Aug 2026 to 2 Sep 2026 (commit dates).

Myriad Immortal Sect runs in a browser, and browsers are not one shape. It runs full screen on a laptop, portrait on a phone, landscape on a tablet, and embedded in a small frame on portals that host browser games. That last one is where my layout rules turned out to be built on an assumption I had never said out loud.

The assumption

Every breakpoint I had written asked one question: how wide is this?

That works for the usual cases, because on real devices width and height travel together. A narrow viewport is a phone and a phone is also short. So width alone is a decent proxy for the whole shape, right up until it is not.

The frame on a game portal is around eight hundred pixels wide and not very tall. Width says desktop, comfortably. Height says something closer to a phone. My code believed the width, so the embedded build got the full desktop treatment: a minimap at its full size covering a sizeable share of the visible area, and, on the first screen, a start button that sat below the fold. The first thing a visitor saw was a game they could not begin.

Both directions, every time

The rule now is that layered elements are decided against both dimensions. Not a second set of breakpoints, just an honest question: is there room for this, given how much space there actually is, rather than how wide it is.

The practical version, if you want one line to take away: write down the real frames your thing runs in, including the embedded ones, and test the smallest total area rather than the smallest width. I had a phone in my test list and no small landscape frame, so a whole class of layout went unchecked in a place where real people arrive.

The other half of a viewport nobody reads

A related one on phones with a notch or a home indicator. The document declares that it wants to draw into the full screen, edge to edge, which is the modern default and looks better.

Declaring that is half the job. The other half is reading the safe area the device reports and keeping interactive controls out of it. I had done the first half only, so on those phones the bottom row of controls sat exactly in the strip the system reserves for its own gestures. Pressing them was a coin flip between the game and the operating system.

The lesson generalises past this specific property. Anything that opts you into more space is also opting you into responsibility for the parts of that space that are not yours. The places that fill that frame, from cities to sect grounds, are named in the glossary of world terms.

Small thing, disproportionate effect

The change I did not expect to matter: the minimap now folds itself away after ten seconds of no input, on a desktop or in landscape. A portrait phone keeps it, since the space it takes there is not contested.

It is a small animation on a timer. It made the map feel meaningfully less cluttered, because the clutter was mostly a thing you needed for four seconds and then stopped looking at. A surprising amount of interface design is working out which elements are answers to a question rather than permanent furniture, and letting the answers leave once they have been read.

Also this week

A pass over the English text as a native reader would meet it, which meant removing transliterations that had survived in dialogue, replacing Chinese units of distance and weight, and fixing one quest line where all four names were wrong at once. Item names went through the same pass, and the glossary of item terms collects their English forms. Our English text is authored rather than translated, so no reader should be able to tell which language a given sentence began life in.

Everything here ships in Xianxia idle incremental game, and you can check the layout on any screen you own.

Putting a 520-chapter serial inside the game itself

IdleCultivation — Thu, 15 Oct 2026 04:30:07 +0000

Development covered 23 Aug 2026 to 29 Aug 2026 (commit dates).

The novel that shares a world with Myriad Immortal Sect became part of the game this week rather than a thing beside it. There is a reader in the game, chapters arrive through their own channel, and somebody who finds a chapter on the web can be playing a few seconds later.

Writing the chapters was the smaller half of that sentence. The story runs through ten acts, from the first realm to the Ascension finale.

What is written is not what is published

The first rule I had to make explicit is that having the text does not mean the text is available. Those are two different states and they need two different sources of truth: the writing, and a published index that says what a reader may actually open.

Without that split, turning the feature on shows a reader an empty shelf, and the shelf looks like a bug rather than like a book that is still being written. With the split, the feature can be on while the index is honest about carrying three volumes.

I got the inverse wrong once too. The index briefly advertised two volumes that were not there. An index that promises less than exists costs you nothing. An index that promises more produces a reader tapping a title and receiving nothing, which is the single worst outcome in the whole feature.

The states that are not chapters

Most of the reader's real work is in the cases where there is no chapter to show.

You can be offline, in which case previously read chapters should still open and unread ones should say so plainly rather than spin. A volume can be planned and unwritten, which is a real answer and deserves its own presentation, not an error. A chapter can be listed and fail to load, which is different again.

I would guess two thirds of the reader's behaviour is these three states. That ratio is normal for anything that fetches content and always surprises me anyway when I count it.

The screen that could trap you

The interesting bug is worth the whole article.

A visitor arriving from a chapter page should land in the reader, not in character creation. So the reader renders in front of the new player flow. That is deliberate and it is the right call: someone who came to read should read.

Anything you place in front of an onboarding flow needs its own way out, and mine did not have one in every path. The close control lived in the reader's header, and the early return that runs before the chapter index arrives never rendered that header. So a visitor whose index failed to load got a screen with no chapters, no close control, no tabs, and no route into the game. Trapped on arrival, on their first visit, which is the exact moment you can least afford it.

The general rule I wrote down after: any screen that renders ahead of the normal flow needs an exit that does not depend on the thing that might have failed. Put the way out in the branch that runs when nothing loaded, not in the branch that runs when everything worked. A reader arriving at a late chapter such as Mahayana should never be trapped there, whatever loaded.

And the paperwork

The rest of the week went to reading my own design set beside the running game. Working through it in order, the tally came out unpleasant: nine contradicted claims in one file, eleven in another, ten in a third, spread over some fifteen files.

An automatic check now covers the cheapest third of that, refusing any document that cites a name or a file the project does not actually contain. The remaining two thirds still need a human with both open side by side. I have looked for a way around that and no longer expect to find one.

The live build is Idle Cultivation RPG, and the reader is inside it: open a chapter and the game in your browser.

Designing an item that exists because players get lost

IdleCultivation — Wed, 14 Oct 2026 04:30:05 +0000

Development covered 18 Aug 2026 to 23 Aug 2026 (commit dates).

The continent in Myriad Immortal Sect is big enough to be lost in, which is mostly a feature. Walking somewhere should cost you something, and reading the land should be a skill you develop. But there is a difference between not knowing the way and standing in a valley with no idea which direction anything is in, and the second one is not fun, it is just friction with a nice sky.

So there is an item for it, and building it properly took the whole week.

An aid has to work where the problem happens

The first version could only be used from your bag. Read that back and the flaw is obvious: to use the thing that tells you where you are, you leave the view that shows you where you are, open a menu, find an item, and come back.

It lights from the map now, in the place and at the moment being lost actually occurs. This sounds trivial and it changed how the item feels entirely. An aid used at the point of need is a tool. The same aid two menus away is homework. The Discerning Eye sorting game hands these out too, which matters for what comes next.

The related failure came from a sorting minigame that also hands these out. Its assistance tray had been sized for the opening stage and never grew, while the boards tripled in size behind it. The help was still there. It had quietly become help for a problem three times smaller than the one in front of you.

Reachable by the people who need it

Two things were making the aid unavailable to exactly the players most likely to be lost, which is to say new ones.

One rung of assistance was meant for people playing without an account, and it could never be reached, because a player on a device that remembers them looked signed in to the check. The other was physical: the three assistance buttons were a thirty five pixel target on a phone, in a project that already had a solution for that and had simply not applied it here.

Neither of these is a design decision. Both of them silently overrode the design decision, which is a thing I have learned to look for specifically.

Pricing a thing you also give away

The item is sold, and it is also granted: some for confirming your email, some for each cleared stage of the sorting game.

That combination is where an economy can quietly spring a leak, and the fix is unglamorous. Buy price and sell payout are set independently rather than one being derived from the other, so no arrangement of buying and selling comes out ahead. The sell payout is deliberately low, and that low number is the brake.

I could have made the item untradeable instead. I did not, because untradeable items pile up in a bag as a category of thing you cannot do anything with, and because a low resale value is honest: it says this is a consumable convenience, not treasure. Players understand that immediately.

One consequence worth knowing if you build the same thing: every source has to deliver the identical item, or your bag ends up with three stacks of the same lamp from three places. Sameness here is a design requirement, not an implementation detail. The settlements you are most likely to be walking between are listed in the guide to cities, towns and villages.

Elsewhere

The other half of the week went to the tie in novel's checking gates, where I measured the false alarm rate at roughly seventy to eighty percent over three rounds. The useful move was not better filtering. It was giving the checker the context it was missing, since a large share of its bad calls came from reading chapter numbers that were local to a section rather than to the book. Fix the input, and a whole class of wrong answers stops being generated.

Try it in your browser: Idle Cultivation Game, or light a lamp yourself, free and with no install.

Adding a rule to a project that already breaks it

IdleCultivation — Tue, 13 Oct 2026 04:30:07 +0000

Development covered 18 Aug 2026 to 22 Aug 2026 (commit dates).

Most rules worth having arrive after the thing they govern. You decide that every tunable value must be readable by the code that needs it, or that every craft key sold in a shop must open something, and then you discover the project breaks that rule in forty places, some of which will take a week to unpick.

There are three things you can do, and two of them do not work.

The two that do not work

Fix everything now and only then turn the rule on. This sounds principled and it means the rule ships in a month, or never, because the forty fixes touch systems you were not planning to open. In the meantime nothing stops violation forty one.

Make it a warning. A warning that appears on every run stops being read by the second week. I have done this to myself more than once and I no longer pretend otherwise.

The third one

Enumerate the violations you have, by name, and assert that the set only ever shrinks. Anything not on the list fails immediately. Anything on the list is a to-do with a test attached, and removing an entry is a small satisfying commit rather than a project.

The rule is live from day one against all new code, which is where most violations would otherwise come from, and the existing debt becomes visible and countable instead of implied. This week that shape closed three separate things: config keys with no reader, craft keys sold in a shop that opened nothing, and a formatting rule. The sellers in question include the wandering merchant's stall, which stocks recipes among its goods.

The mistake that makes it useless

I had the formatting one wrong for weeks and did not know it.

Instead of naming the violating files, I had exempted them with a pattern. A pattern does not just cover the files that existed when you wrote it. It covers every file that matches it from then on, including the ones I wrote that same night, which were red, and which nothing told me about because the exemption swallowed them along with the old ones.

That is the whole difference between an exemption and a ratchet. An exemption describes a shape and keeps forgiving it. A ratchet lists specific items and forgives exactly those. The list is uglier to read and it is the only version that works.

Two smaller ways a guard can be theatre

Both of these were live in this project and both survived review, because a guard that never fires looks exactly like a guard that passes.

One matched a mention rather than a use. It was checking whether a certain thing appeared in the file, so an unused import at the top satisfied it forever, long after the real usage had gone.

One had been written inside a comment. It never ran at all. Nobody noticed because its suite was green, which it would have been either way.

The habit I have taken from this: when I write a guard, I break the thing it guards on purpose and watch it go red before I commit. Sixty seconds, and it is the only evidence that the guard is connected to anything. A craft key such as the Deity Pill recipe is the kind of item the shop check now covers.

And check the artifact, not the description

The last variation is subtler. Several checks here were asserting against prose in a document, or against a value in the file that authors it, rather than against the payload that actually ships to players.

Those pass while the shipped thing is wrong, which is the worst outcome available: a green signal proving something adjacent to the thing you care about. The checks now read the exported payload. Two of them went red the moment they were pointed at it, which is exactly what you hope for and never enjoy.

Open the game free in a browser tab to see the rules at work; the devlog archive sits at Incremental RPG.

The rename that changed nothing, and why 43 names had drifted

IdleCultivation — Mon, 12 Oct 2026 04:30:07 +0000

Development covered 16 Aug 2026 to 18 Aug 2026 (commit dates).

I spent part of this week renaming thirteen named characters in Myriad Immortal Sect. The English edition is written as an original rather than as a translation, so a character who reads naturally in Chinese gets an English name that reads naturally in English, not a transliteration a reader has to decode. Characters now carry names like Sabrina, whose codex page shows the name players actually see.

I made the renames in the place where the game's entity data is authored and curated. Then I opened the game and every character still had the old name.

Two sources, one fallback, opposite winners

Names in this game live in two places.

There is the curated entity data, which is authored, reviewed and exported to the client. And there is the display catalogue that the interface reads for the player's language.

The lookup tries the catalogue first and falls back to the entity data when the catalogue has no key. That is a completely reasonable design, and it produces two quiet no-ops that point in opposite directions.

Rename in the entity data, and nothing changes for any name the catalogue already knows. The export runs, the payload updates, the game shows what it always showed.

Rename in the catalogue, and the entity data stays wrong forever. It is not reachable from any export, so a later reader of that data sees a name that no player has ever seen.

Why the drift accumulates rather than settling

There is a tool that seeds missing catalogue entries from the entity data, and it is additive and safe to re-run on purpose, which is the right call for a tool that runs often.

Additive means it can add a key that is absent. It cannot carry a change to a key that is present. So every repair made in the catalogue leaves the entity data one step behind, permanently, and the tool that exists to keep them together can never close that particular gap.

By the time I looked, forty three rows had drifted. The curated data said "Alchemy" where the game had been saying "Alchemy Pavilion" for months. The good name was the one nobody had written down in the place that looks authoritative. The hall in question is the Alchemy Pavilion, which is what its codex page calls it too.

What I actually changed

A single tool now moves both layers together, and the rule is written down where the next person will trip on it, which in practice means where I will trip on it.

The wider lesson is the part worth carrying to another project. If you have two sources with a fallback between them, ask two questions before you edit either. Which one wins for the reader, and can your synchronisation carry a change or only an addition? A sync that is additive and safe to re-run is a guarantee about safety, not about convergence. Those get confused constantly, including by the person who wrote the tool.

Elsewhere this week

The same week produced a matching lesson at the data layer: a repair applied to the authored rows is not finished until every mirror of those rows carries it, because a fresh environment is rebuilt from the mirror rather than from the repair. And a check now runs over the design documents themselves, failing when a document names an identifier or a path the project does not have. Six of those were live, including two constants documented in a file they had moved out of.

None of these are interesting bugs. They are all the same shape: a fact stored twice, agreeing at the moment it was written, with nothing watching the gap afterwards.

The cast answers to its English names now: meet them in your browser, or read the rest at Cultivation Game.

1,826 draw calls to put 61 objects on the screen

IdleCultivation — Sun, 11 Oct 2026 04:30:08 +0000

Development covered 15 Aug 2026 to 17 Aug 2026 (commit dates).

Players of Myriad Immortal Sect walk a continent that streams in around them as they go. It had felt slightly rough for weeks, in the way that is easy to live with and impossible to un-notice, and I had two confident theories about why.

Both were wrong. I finally measured, and the number that came back was 1,826 draw calls to put 61 objects on the screen.

Loading and showing are different units

The map loads in chunks. A chunk is a sensible unit for loading, because it is a sensible unit for unloading: when you walk far enough away, the whole chunk goes.

The problem is that the renderer does not skip a plain image just because it sits outside the view. Every loaded thing gets submitted, every frame, whether it is in front of you or twenty eight thousand pixels behind you. And chunks stay loaded for a long distance around the player, deliberately, so that walking back does not stutter.

That is where the ratio comes from. Sixty one objects were visible. Everything else being drawn was correct to keep loaded and pointless to draw.

The fix is to keep the unit of loading as the chunk and make the unit of visibility the object. Those cannot be the same unit here, because a sect compound's buildings all belong to one chunk while the world is dozens of chunks across, so chunk level visibility would either draw the whole compound or none of it. A compound holds a dozen or so halls, such as Azure Cloud's pagoda, all owned by that one chunk.

The trigger you will forget

Visibility gets recomputed when the camera moves, which is the obvious trigger and the one everybody writes.

It also has to be recomputed when new chunks finish streaming in. Without that second trigger, anything that arrives while the player is standing still is never considered, so it is drawn forever regardless of where it is. Standing still is extremely common in an idle game. That trigger is doing more work than the obvious one.

Then the opposite problem

Building a chunk means scattering its props, and that work is synchronous. Measured, it is about seven milliseconds at the median, thirty six at the ninety fifth, and one hundred and forty two at its worst.

When you reveal a large area at once, the box being revealed can be twenty five chunks. Doing twenty five of those in a single frame is a freeze, and a freeze while the page is meant to stay responsive is exactly the thing I care most about avoiding.

So chunk assembly now runs against a per frame budget, nearest chunks first. Terrain loading is deliberately not budgeted, because ground appearing late is much worse than a tree appearing late. Population trails the ground by a frame or two and nobody notices. The land being streamed is laid out in this overview of the whole continent, if you want to see how far it goes.

The part I want to remember

I had two explanations for the roughness before I measured. One was about how the game hands work to the browser. The other was about a piece of the world I had recently changed and felt guilty about. Both were the kind of theory you can hold with real confidence, because both described mechanisms that genuinely exist and genuinely cost something.

Neither was the reason. The reason was a ratio nobody would guess, sitting in a system I considered finished, and it took a count of draw calls to find.

I now treat a performance hunch as a hypothesis with a required measurement attached, and I write the measurement down next to the fix. Not for discipline points. Because the next person to touch this code will be me in four months, holding a fresh confident theory, and the number in the comment is the only thing that will stop me.

More devlogs and the game: Myriad Immortal Sect, where you can roam the streamed world for free.

You cannot eyeball a tap target, so I measured all of them

IdleCultivation — Sat, 10 Oct 2026 04:30:06 +0000

Development covered 10 Aug 2026 to 15 Aug 2026 (commit dates).

Myriad Immortal Sect runs in a browser, which means it runs on phones, which means for months it had a whole half that nobody was testing. I had looked at it on a phone plenty of times. Looking is not the same as testing, and for this particular class of problem, looking is close to useless.

Why a phone pass is dimensional, not visual

The defects here are numbers. A control is 17 pixels tall. A grid is 40 pixels wider than the screen. A description has one line of room and two lines of text, so it does not wrap, it disappears.

None of those announce themselves when you glance at a screenshot. The screen looks like the screen. You find out when you try to press something with a thumb and press the thing beside it instead, and even then you are inclined to blame your thumb.

So the first real change was not a fix. I taught the machine that plays the game overnight to switch to a phone viewport, and suddenly the mobile half was under the same treatment as everything else.

The first measurement pass lied to me

Asking a page how big each control is sounds like the easy part. It is where I lost the most time.

The game already gives many buttons an invisible halo that extends the pressable area past the visible edge. That halo is drawn separately from the button. If you measure the button's own box, you get the visible size and you conclude the control is too small, including for every control you already fixed. My first sweep confidently re-reported a batch of buttons that were fine.

The lesson generalises past this project: when you automate a measurement, check it against a case you know the answer to before you trust the list it produces. I had a list of forty problems, some fraction of which were the measurement's problems rather than the game's.

Fix the class, not the instances

Once the list was honest, the temptation was to walk it. Four controls at 13 to 28 pixels here, a pager arrow there, tabs on the market at 28, a duel button at 24.

Walking a list like that is how you fix forty and miss four hundred. The controls came from one shared button definition, so the minimum pressable size went there, once, and most of the list closed by itself. What was left was genuinely per screen: a grid that had to stop assuming a desktop width, a header that had to wrap so its action stayed visible, a bottom bar that now scrolls to the tab you are actually on.

One fix I want to call out because it is invisible on desktop and obvious on a phone: an item menu used to open below the point you touched, which is exactly where your finger already is. It opens above now. Nothing about that is discoverable from a mouse. Every screen got the same treatment, down to the skill tree page, one of the busiest screens on a small display.

The other half of the week

Away from the phone, this stretch was the tribulation curve. Breakthroughs used to be uniformly tense, which reads as uniformly flat. They are now loose at the front and tight at the back, so the early ones teach you the rhythm and the last two are meant to frighten you, with the panel telling you plainly what would raise your odds. There is always a way through. Difficulty that can trap you is not difficulty, it is a dead end with a health bar.

The connection to the phone work is real, if you squint. Both are about the game answering the player honestly about a physical fact: how big this is, and how likely that is. Preparations for a tribulation include items like the Tribulation-Warding Talisman.

If you have a phone handy, test the game on it straight from the browser; the full series is on Xianxia idle incremental game.

The writing pipeline kept eating the state it depended on

IdleCultivation — Fri, 09 Oct 2026 04:30:07 +0000

Development covered 11 Aug 2026 to 15 Aug 2026 (commit dates).

This stretch was almost entirely the tie in novel rather than the game. The series covers a book per realm, and volume one alone is long enough that nobody is holding it in their head. So the writing runs as a pipeline, unattended, for hours at a time.

A pipeline like that has two products, and I had only been watching one.

The output is not the state

The obvious product is chapters. The other one is everything the pipeline remembers between chapters: which threads are open, who knows what, which promises the book has made and not yet kept. That running record is what makes chapter 300 agree with chapter 40. It is not delivered to anyone. It exists so the next run is not starting from nothing.

I found out that my revision step rewrites that record every time it runs. Not corrupts, rewrites: it reconstructs the state from its own reading and puts that back. Measured on one book, the record of open threads came back missing about four fifths of its entries. A separate step could truncate it to nothing at all.

None of this showed up in the chapters. The prose was fine. It would have kept being fine for a while, and then, thirty chapters later, the book would have quietly stopped honouring a promise it made in the second volume, and I would have gone looking for that in the writing. The story it has to keep straight is the game's story too, down to single quests such as Settling Karma.

What made it findable

I only caught it because I started checking the state before and after a run instead of reading the output. That sounds like something you would obviously do. In practice it is not obvious at all, because the state is intermediate, it has no reader, and every instinct says the thing to inspect is the thing you are shipping.

The rule I now work by: if a long job carries state between steps, that state is a first class artifact. Snapshot it before a destructive step, compare after, restore when the comparison fails, and assert on it in its own right. Do not infer its health from the output, because output quality degrades far later and far more gradually than state does.

A related trap, in the checking layer

The same week produced a version of this in the repair path. I had a step that takes an identified problem, edits the text, and reports success. Reporting success is not evidence, so I added two assertions: the thing you were asked to remove must be gone, and everything you were not asked to touch must still be there.

The first assertion had a flaw that made it always pass. Its pattern was allowed to end on whitespace, which meant it could never match what it was looking for, which meant it never fired. An assertion that cannot fail is worse than no assertion, because it makes a report of success look checked.

The second assertion, the one about not touching anything else, turned out to be the more valuable half. A repair step will happily fix the sentence you named and rewrite the paragraph around it.

The parallel version of every bug

The last thing I did here was let several arcs be written at once. That surfaced five separate defects that simply do not exist in a single stream, the most instructive being two runs racing for the same write with no single instance check between them.

Concurrency did not create those bugs. It removed the accidental serialization that had been hiding them, which is roughly what it always does. The people whose knowledge that running record tracks include figures like Zhou Ming, who also appear in the game.

Everything here ships in Idle Cultivation RPG; read the story and play it free in the browser.

How big is that tree? Sizing a world drawn at every scale

IdleCultivation — Thu, 08 Oct 2026 04:30:07 +0000

Development covered 9 Aug 2026 to 11 Aug 2026 (commit dates).

The world map in Myriad Immortal Sect is made of hand drawn pieces: halls, pines, herbs, beasts, mountain ranges, people. They were drawn at whatever size suited the drawing. A pine came in enormous. A herb came in nearly as tall as a person. A wild beast was being shown at one fixed height whether it was a rat or a tiger.

You do not notice this as a sizing problem. You notice it as the world feeling wrong, which is a much harder thing to act on.

The player is the ruler

The fix started by naming the unit. The player figure is the reference height for every drawn thing in the world, and whatever decides how large to render a piece asks a single place for that answer. A gatherable herb is about half a person. A pine is a tree, meaning several people tall. A beast is sized by what it is, and when the beast happens to be a person, it is sized like a person.

Having one answer sounds like tidiness. It is really about the failure it prevents. Three separate places were deciding size, and they had drifted, so the same object could be one height in the world and another in a panel. There is now a test whose only job is to fail if a fourth place starts deciding this on its own. The halls that rule now sizes are catalogued in the codex of buildings, each drawn against the same human ruler.

A ceiling flattens the thing you care about

My first version capped drawn height. Anything above the cap became the cap.

That is wrong in a way that took a day to see. A cap does not just shrink the giants. It makes all the giants the same. A mountain range, a great hall and an overgrown pine all hit the ceiling and arrive at identical height, so the world loses its ordering exactly where the ordering is most dramatic. The player cannot tell that the mountain is the biggest thing on screen, because everything tall is now equally tall.

So oversized things are compressed along a curve instead. Big things get noticeably smaller, enormous things get much smaller, and the ordering between them survives the squeeze. A mountain range is also allowed out of the system entirely, because a skyline that respects a height budget is not a skyline.

The bugs this class of change produces

Two are worth repeating because they are the same mistake wearing different clothes.

A gentle breathing animation on standing figures was written as a scale, so it multiplied whatever size the new system had chosen and pushed some villagers to twice the player's height on the inhale. An animation that adjusts a value has to adjust it, not replace it.

The ground had a similar story. I wanted a hairline seam between tiles so the surface reads as tiles rather than as paint, and I first added it by shrinking each tile. That opens gaps you can walk into, and in one spot could not walk out of. The seam belongs in the spacing between tiles, not in the tiles. You can judge the result in any stretch of wilderness, for example around the Dragon Vein Eye.

Walking got the same treatment

Click to move used to plan one route to the destination and give up if the whole thing was blocked. It now plans leg by leg, measures progress against the current leg instead of the final goal, and slides along a wall it bumps into while keeping the heading it was travelling on. It cancels only when the destination itself is unreachable, not when some point along the way is.

The common thread across all of it: the first version of each rule was a single global answer, and the world is not uniform enough for a single global answer. What worked was a rule that keeps relative order intact, plus one place that owns it, plus a test that notices when a second place appears.

Sizes now follow the player everywhere. Walk that continent free in the browser, or see the other devlogs on Idle Cultivation Game.

The spec was unbuildable, and only building it showed that

IdleCultivation — Wed, 07 Oct 2026 04:30:09 +0000

Development covered 6 Aug 2026 to 9 Aug 2026 (commit dates).

Myriad Immortal Sect has a design document per system, and I write the document before I write the system. This week I finally built one of the oldest ones and discovered it described something that cannot exist.

Reading your own spec like a stranger

The system is a slow-earning currency. The document said, in effect, that you earn it while you are in the game, at a rate set against a balance, with the earning gated on a condition. I had read that paragraph perhaps thirty times over several months and understood it every time.

Then I sat down to implement it exactly as written, and the gate could never be satisfied. The condition the document set was one the game reaches only after the currency already exists. Read literally, the faucet never opens on a new account, which is the only kind of account that matters for a currency meant to accumulate slowly.

I want to be clear that this is not a typo I could have caught by proofreading. The sentence is grammatical and it names real things. It is wrong in the way a plan for a bridge is wrong when the two banks are at different heights and nobody drew the elevation.

What "an hour is worth an hour" means when you write it down

Settling it meant answering a question the document had been quietly avoiding: what is one hour of play actually worth here?

An idle game has to answer that in a currency, not in a feeling. Once the number exists, everything downstream stops being an argument. The production rate became plain arithmetic that a test can assert, which sounds obvious and was not obvious for months, because the rate had been living inside a paragraph as a description rather than inside the game as a value.

The moment it was arithmetic, a second problem showed itself: a faucet with no relationship to a balance is just a number going up. So the rate now reads from the same balance the rest of the economy reads, and the two move together. If I change what an hour is worth, one number changes and the whole system follows. Each attribute that rate eventually feeds is described in the guide to what your cultivation attributes do.

The rest of the week was the same lesson at smaller scale

I spent most of this stretch checking documents against the game that shipped, one document at a time, and the pattern repeated in miniature everywhere.

A file promised a discount that scales with your realm. Built version: a flat one, and the document had claimed the scaled version superseded it. A card advertised perks that were compiled into the build, while an operator was supposed to be able to change them. An index named the wrong starting sect. A guidance table ranked two actions it had never actually ranked. In one document three separate claims described behaviour the code does not have.

None of these were caught by reading. They were caught by holding one document open and one game open and going line by line, which took a full day per batch and turned up something almost every time. Several of those documents describe trade, such as the weekly sealed-bid sale and its pricing.

The takeaway I would give a past version of myself

Write the document first, still. It remains the reason the game has a shape. But treat it as a hypothesis with an expiry date rather than a record of what is true. A spec that has never been built is not verified, however many times you have read it, and rereading is the exact activity that will not verify it. The only reader who finds the missing elevation drawing is the one holding a shovel.

I now finish a system by going back and rewriting its document to describe what shipped, including the places where I decided the original was wrong. That is not bookkeeping. It is the only way the next thing I build starts from something true.

Go straight to the game and play for free, or browse the design notes at Incremental RPG.