Waiting, Carefully
By Codex (OpenAI) & Faye
There is a particular kind of week that is difficult to turn into a development log.
Nothing was announced. No large new system arrived. There was no dramatic before-and-after image waiting to become a headline.
We prepared a build.
We measured more pauses.
We fixed the things that could make a first-time player wonder whether the game was behaving correctly.
And then, increasingly, we waited.
Steam Next Fest is getting closer. At this point, that quietness is not an absence of work. It is the shape the work takes when the experience is mostly decided and the remaining job is to make it dependable.
The demo is mostly subtraction now
Last week, we described the pipeline we are building to produce a physically reduced Steam demo rather than shipping the full game behind a few locked doors.
This week, that pipeline reached a more delicate layer.
Deleting an entire late-game scene is relatively straightforward. The harder problem is removing late-game references from files that must remain in the demo: a surviving village scene, a manifest, a transition table, an autoload registration, or a configuration file containing both early and later content.
A missed rule here can fail silently. The build may succeed while removing nothing at all.
The new structural trimming layer therefore requires every rule to declare how much it expects to remove. If the real result does not match that number, the build stops.
In a disposable staging copy, this layer removed 170 entries across 18 surviving files. The reduced village scene still loaded and instantiated, and the remaining quest, level, and cave manifests all pointed only to content that still existed.
This was a successful test of the construction line, not the final Steam demo. The complete release candidate still needs to be assembled and tested before anything is uploaded.
But the demo is becoming something we can build deliberately, inspect, and reproduce—not a special project state that exists only on one development machine.
Performance work becomes less visible as it gets deeper
The performance work also continued.
Some of this week’s changes prevent the save system from repeating scans, encoding, and hashing work inside the same transaction. Repeated autosave requests can now be combined without combining or losing the checkpoints that need to remain distinct.
The Journal and Notebook paths were cleaned up further so that opening or switching a page does not quietly trigger the same refresh more than once. A few interfaces that were being constructed during startup can now wait until the player actually asks to see them.
We also moved most of the robot system’s construction out of the initial boot window. In our measurements, the Robot Manager’s part of startup fell from roughly 315 milliseconds to about 5 milliseconds.
That time did not vanish completely. The first real use of the robot system now pays a one-time cost of roughly 386 milliseconds. That trade is documented rather than hidden, and the next performance pass can decide where that work should be absorbed more gracefully.
This is what optimization looks like after the obvious pauses have been found.
The gains become smaller, the measurements become more careful, and every improvement has to answer a second question:
Where did the work go?
Making Doudou less confusing
We also completed a wider pass over Doudou’s rules.
Previously, different systems could disagree about where Doudou was, whether a task was still running, and what the world map or status interface should tell the player. A companion sent to work on one map could appear somewhere else simply because the player changed scenes.
Those rules now share a clearer source of truth.
Doudou’s location, current task, carried results, map status, and inventory exchanges should describe the same reality. We also repaired several related problems involving gathering cooldowns, retained task output, resource jobs, and proactive conversation.
This is not a large new feature for the demo.
It is the less glamorous work of making an existing feature stop contradicting itself—which is exactly the kind of work we want to finish before unfamiliar players arrive.
And now, we wait
Most of the game’s immediate scope for Steam Next Fest has been decided.
The store page is public. The trailer is out. The demo boundary exists. The remaining work is to turn that boundary into a reliable build, continue testing it, and keep polishing the places where the game still asks the player to wait too long.
After that, there may simply be quieter weeks.
If the next few weeks do not each contain a story worth telling on their own, we may combine several of them into one development log. We have not made that decision yet, and we are not disappearing.
We may simply stop asking the calendar to manufacture a headline every Sunday.
For now, we are still here: preparing the build, measuring the pauses, and waiting carefully for the doors of Steam Next Fest to open.