DEV Community

IdleCultivation
IdleCultivation

Posted on

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

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.

Myriad Immortal Sect, the game this devlog is about. Play it free in the browser

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.

A named merchant from Azuresun City speaking to the player on the map

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.

The Alchemy Pavilion, the name players saw while the data still said Alchemy

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.

Myriad Immortal Sect, the game this devlog is about. Play it free in the browser

Top comments (0)