Void Engine is the 3D rebuild of Kuro Kishi. Today it was made repeatable, and a trailer render showed why light needs a limit.
A game that can be replayed exactly
Before today the simulation followed the frame time of the display and used Math.random everywhere, so no two runs matched. Now it advances in fixed 1/60 second steps with an accumulator, up to 5 steps per frame, and a faster display just renders at 60 Hz. About 30 gameplay random calls moved to a seeded stream that is reseeded when the world is built. Cosmetic randomness stays unseeded.
Two things turned out to be quietly feeding back into combat:
- Enemy ids came from a counter at module level that never reset, so a replayed stage had different aim jitter.
- Cosmetic animation fed back into combat in two places. Hazard debris now collides on a rest pose instead of the animated one, and the boss muzzles are sampled without the hit shake.
To prove it, a recorder hashes every group of entities on every frame, each case in a fresh headless browser page. Recording with the cosmetic randomness still unpinned diverged: stage 5 at frame 174 and stage 2 at frame 4,073, with different final scores. After the fixes they match.
| measure | result |
|---|---|
| Cases | 72 (8 stages, 3 ships, 3 pilots: god, normal, idle) |
| Frames recorded | about 706,000 |
| Repeat identity | every case identical on repeat |
| Trace files kept | 53, 21 MB (identical normal pilot traces pruned) |
The loop was checked at 30, 60 and 144 Hz and with jitter by calling the tick directly, because the browser pane was hidden. Nobody has watched the game run live after the loop change. Replaying a stage inside one play session is probably not exactly reproducible, because of warm-up state. That is not fixed.
The white-outs were one charged shot
A 61 second trailer is rendered frame by frame. It showed near-white blasts of 0.5 to 1 second at about 2, 17 and 33 seconds in. The first assumption was explosions, and it was wrong.
The cause was the Watch Mode pilot's fully charged shot from the Kestrel. It draws an additive glow of 128 by 105 units at HDR colour (3.0, 1.4, 0.3), plus a 66 by 60 fire sprite, covering two thirds of the 192 by 108 view. Bloom and tone mapping push that to near white. It fires at 3.4, 34.1 and 38.7 seconds of simulation, then every 1.5 seconds from 56.8 to 73.3, and again at 126.9 and 128.7. Hiding the additive effects layer made the white-outs disappear, which is how it was pinned down.
Nothing in the game changed. Instead the capture tool measures each rendered frame and, if it is over a cap (mean luminance 0.30, lit fraction 0.25, near-white fraction 0.04), re-renders it with a lower gain on large additive sprites, found by bisection. Frames under the caps are untouched.
| before | after | |
|---|---|---|
| Frames with more than half the screen lit | 548 (9.13 s, in 16 runs) | 0 |
| Highest frame mean luminance | 0.673 | 0.301 |
| Highest lit fraction | 0.718 | 0.250 |
| Highest near-white fraction | 0.205 | 0.030 |
| Counted flashes | 19 | 0 |
786 of 3,660 frames were governed, with a median gain of 0.25. Rendering slowed from 8.2 to 3.5 frames per second, so a preview should run with the governor off. A simpler cap on glow size alone was tried and left off, because it only moved the first fireball's peak from 0.635 to 0.559.
This is an approximate check and not a formal flash-safety standard. Under a stricter setting (swing 0.10, area 0.10) both versions still count 30 flashes with at most 2 in a second, so ordinary explosions still flash. Other stages, ships and segments have not been checked.