Two Altars I Could Never Reach
An altar is supposed to arrive every 38 seconds. Two rooms into a run, they stop arriving, and they never come back.
Nothing errors. No frame drops, no exception surfaces, no log line changes. A thing scheduled to happen dozens of times over a long run happens twice, then stops, and every signal the game emits is about something else entirely.
The clock lives inside the capacity check
The spawner is a handful of lines I had read many times without seeing anything wrong with them:
if (this.shrines.length < MAX_SHRINES) {
this.spawnTimer -= deltaSeconds;
if (this.spawnTimer <= 0) {
this.spawnShrine(playerX, playerY);
this.spawnTimer = SHRINE_INTERVAL;
}
}MAX_SHRINES is 2. SHRINE_INTERVAL is 38 seconds. The countdown sits inside the capacity check, which is deliberate and, on its own, correct: there is no reason to count down toward a spawn you are not allowed to perform. The player takes one, a slot frees, the clock resumes.
A shrine leaves that list exactly one way. The player flies into it, inside a touch radius of 36, it fires, and it is spliced out. That is the only exit.
A second door into the same list
The world generator also places altars, and it does not use the timed path. It calls addShrine directly, the same method the timer uses to register its own, and that method never consults MAX_SHRINES. The asymmetry sat there for a long time and cost nothing, because a placed altar was still an altar: fly into it, it fires, the slot frees.
Then the expedition layer started fencing rooms. Some seal their contents behind a traversal ability, and an altar behind that fence cannot be reached by a player who has not yet earned the Phase Cloak. There is no path to it at all, and there is not supposed to be. That is the feature.
So it holds a slot by construction. It never fires, so it never leaves, so the slot never frees.
Two of those anywhere in the world and shrines.length < MAX_SHRINES is false for the rest of the run. The countdown does not pause. It never resumes. The ambient altar that the run pays out every 38 seconds, carrying a real slice of the run’s economy, simply never arrives again.
Two rooms in was enough.
The constant never changed. Its inputs did.
Nothing about the cap was wrong when it was written, and nothing about the fence was wrong when it was written. MAX_SHRINES = 2 means “at most two of these at once”, which is a throttle, and a throttle is a claim about a flow. It only holds while everything the counter counts eventually drains.
Feed that same counter from a second path whose items are guaranteed never to drain, and the identical constant quietly changes what it says. “At most two at a time” becomes “two, then never again.” Same number, same line, opposite behavior. The commit that flipped it lived in a different file, shipped for an unrelated reason, and touched nothing in the spawner.
Connection pools, semaphore slots, in-flight request limits, worker queues: every one of them is a bound written by someone assuming the counted things are transient. The bound does not enforce “at most N”. It enforces “at most N of the kind of thing I had in mind.”
There is no event for something that did not happen
The reason this ran undetected is a separate failure from the bug itself, and the more useful one.
Every monitoring instinct I have is built around events. Something happened and it was slow, or it threw, or it came back the wrong shape. All of that machinery is blind here. The altar did not fail to spawn. The code path that spawns it was never reached, because the clock leading to it stopped advancing. There was nothing to log, because nothing occurred.
The player-facing symptom is just as quiet: the run gets slightly poorer over a long enough stretch that it reads as difficulty. It does not look like a defect. It looks like balance.
The fix is not “drain the pool”
The obvious repair is to make placed altars retire when the player leaves the room, the way the game already puts away an untouched chest. That is most of the fix, and it works.
It cannot be applied to everything that lingers, though. Ambush nests and nemesis lairs also sit in arrays and also never leave on their own, and they are deliberately left standing, because the map derives its hazard markers live from those arrays. Retire one and you delete a destination the game has already told the player to come back to, and blank the quest pin aimed at it.
So the repair was not learning to clear things out. It was having to tell two kinds of permanent resident apart: the one holding a slot it will never use, and the one whose entire job is to still be there when you return.
The fenced altars are still out there in every run, sealed behind a wall until the player earns the cloak. They just do not hold the clock any more.