Ferrum development journal · Part 6 of 19
Game Progress and Measuring the Right Thing
Controlled gameplay in King's Pass was useful progress. Understanding the route, memory growth, and test conditions was just as important as reaching another screen.
Seeing a character move through an actual game is one of the more satisfying parts of this project. The Hollow Knight work reached controlled gameplay in King's Pass, with tests that followed the scene and checked what the game was doing. That was a useful application result, even though a complete human play session, audio, saves, and the rest of the game still needed broader acceptance.
The route itself needed more care than simply holding a direction. A camera movement can make the player look stationary, and a character near the edge of a frame can be difficult to locate. The development work used the scene and the captured images to distinguish a real stall from a change in how the game was being observed.
Performance work also needed better controls. If two guests or a build are competing for the same machine, an apparent slowdown may have very little to do with the code being compared. The project accumulated rules about one guest at a time, recording load, and comparing the same backend and workload. Those conditions are part of the result, not details to leave out of the report.
Memory growth was another example. A long game run can show a problem without identifying which component owns it. Reproducing growth outside the game gives us a smaller case to examine, and it avoids blaming the title for behavior introduced by the translation stack or the harness.
The same period included CPU and translation research, along with packaging and test-isolation work. I'm interested in optimizations that survive a real comparison, but I don't want a faster number produced by changing the workload, lowering the quality, or losing part of the measurement.
So the takeaway from this part of the journal is specific: there was real, bounded gameplay progress, and the measurement process became more demanding. It wasn't a declaration that the game was fully supported or that Ferrum had reached a general performance target. Those are larger claims that need their own evidence.
Ferrum development journal
View the journalLive19 entries so far·Updated New (19 entries updated in the last 14 days)
- Part 1Bringing FEX to macOS: The First Windows Program
- Part 2From Return Values to Pixels and Sound
- Part 3Building More of the Windows Runtime
- Part 4Following a Game Through Its Opening Video
- Part 5Installers, Saves, Fonts, and the Parts Around the Game
- Part 6Game Progress and Measuring the Right Thing
- Part 7Building the 32-Bit Graphics Path
- Part 8Making Memory, Files, and Graphics State Agree
- Part 9DirectX 12, Shader Caches, and the Steam Startup Work
- Part 10Working on Presentation and Controller Input
- Part 11A Launcher and a Freeze That Wasn't the Presenter
- Part 12Portal Reaches a Command Stream, With the Frame Still Ahead
- Part 13Correcting the Ferrum Progress Report
- Part 14Recovering the Project and Resuming Real Tests
- Part 15Making Memory Protection and Lifetime Tests More Useful
- Part 16Getting Wine's Real 32-Bit Startup to Run
- Part 17Making the Launcher Own Its Storage and Processes
- Part 18A Real Archive Roundtrip and Better File Behavior
- Part 19Asynchronous I/O and the Bytes a Cancelled Write Keeps