feat(stats): Generate match stats for headless replays#396
Merged
x64-dev merged 2 commits intoGeneralsOnlineDevelopmentTeam:mainfrom Mar 20, 2026
Merged
feat(stats): Generate match stats for headless replays#396x64-dev merged 2 commits intoGeneralsOnlineDevelopmentTeam:mainfrom
x64-dev merged 2 commits intoGeneralsOnlineDevelopmentTeam:mainfrom
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Stats Export for Replay Simulation
Adds a system to export detailed match statistics as gzip-compressed JSON alongside replay files. Designed to support post-game analytics, replay visualization tools, and automated stat collection pipelines.
What it does
When the
-exportStatsflag is passed on the command line (requires-headlessand-replay), the engine records game events during replay simulation and writes a.gamestats.json.gzfile next to the replay. An optional-statsUrl <url>flag uploads the compressed file to a server via HTTP POST after writing.The exported JSON contains:
How it hooks in
Event recording uses three hook points in existing game logic:
Object::scoreTheKillrecords kills (after the same guards that gate score tracking. No self-kills, no civilian kills, no GUI-ignored objects)Player::onUnitCreatedandPlayer::onStructureConstructionCompleterecord builds (respecting theisRebuildflag for structures)Object::onCapturerecords capturesEach call site is guarded by
TheGlobalData->m_exportStats, so in normal (non-export) gameplay there is zero overhead The recording functions are never called. Inside the functions, a secondaryexportingActiveflag gates recording to the active window betweenStatsExporterBeginRecordingand the end ofExportGameStatsJSON, preventing data accumulation between replays in a batch run.The replay simulation loop in
ReplaySimulation.cppdrives snapshot collection (called every frame, throttled internally to every 30 frames) and triggers export after each replay completes. Worker process mode forwards-exportStatsand-statsUrlto child processes.Flag validation
-exportStatsis validated at startup inGameMainbefore any game logic runs. If-headlessor-replayis missing, the process prints an error and exits immediately. This fail-fast approach avoids silent misconfiguration or flag mutation at runtime.Design choices
Free functions with static state instead of a class: The exporter is intentionally not a subsystem or singleton. It's a leaf dependency. It reads from Player, ScoreKeeper, Energy, etc. but nothing depends on it. Free functions with file-scoped static state keep the coupling minimal and avoid touching the subsystem initialization order.
Two-layer gating (
m_exportStats+exportingActive):m_exportStatsis a command-line flag checked at call sites to eliminate function call overhead in normal gameplay.exportingActiveis a runtime state flag managed by the exporter itself, active only betweenStatsExporterBeginRecordingand export completion. The two serve different purposes: one answers "did the user opt in?" and the other answers "are we in the recording window right now?"Raw player index remapping: The engine's player list includes observers, civilians, and other non-game slots. The exporter builds a mapping from raw engine indices to dense 1-based "game player" indices at first use, so the JSON output has player indices 1, 2, 3... regardless of how the engine internally numbers them. Events store raw indices during recording and remap at export time so the mapping only needs to be stable at the point of export, not during gameplay.
gzip compression: Stats files can be large for long games (many thousands of events). Writing gzip directly via zlib keeps file sizes manageable and avoids needing a separate compression step in the pipeline. The upload path sends the compressed file as-is with
Content-Type: application/gzip.nlohmann/json (ordered_json): Uses the existing
json.hppalready vendored in the codebase underGameNetwork/GeneralsOnline/.ordered_jsonpreserves insertion order so the output is human-readable without a separate formatting step.WinInet for upload: The uploader uses WinInet (
InternetOpenA/HttpSendRequestA) rather than pulling in a dependency like libcurl. WinInet is already available on all target platforms and handles HTTP/HTTPS with proxy support out of the box. The upload is synchronous and runs after the replay has finished simulating, so blocking is acceptable.AcademyStats getters: Added const accessor methods to
AcademyStatsto expose the existing private counters (supply centers built, peons built, etc.) for export. These were previously only accessible through thecalculateAcademyAdvicepath.