This atlas's Wire Protocol doc named gameState().apply(pack) and showed it happening once, for one battle pack. This is what that call actually is: one method, one visitor class with roughly ninety overrides, and — the part Wire Protocol didn't get to — the exact same code running independently on the server and on every client, each against its own CGameState.
Every other doc in this atlas has pointed at CGameState without opening it. It's smaller than the reputation.
Past the map (std::unique_ptr<CMap> map, this atlas's Map Formats convergence point) and the day counter (ui32 day), the real bulk is three maps and a bonus node: std::map<PlayerColor, PlayerState> players, std::map<TeamID, TeamState> teams, and CBonusSystemNode globalEffects — the root of the black and red DAGs Bonus System already traced; every other node in the game eventually inherits from this one. Alongside that: currentBattles (a vector of every fight in progress, plural — simultaneous battles are a first-class case, not an edge case) with its own nextBattleID allocator, heroesPool (the tavern's unhired heroes), and replayLog, which gets its own section below. Everything else on the class is either initialization code (private, run once by initNewGame()) or narrow accessors over these same few members.
CGameState::apply() is three lines. What makes it the busiest file in this atlas isn't the method — it's what it dispatches into.
CGameState the same way each client applies them to theirs. GameStatePackVisitor implements roughly ninety visitXxx() overrides, one per PacksForClient.h type this atlas's Wire Protocol doc already catalogued — this diagram generalizes the one example that doc traced (BattleAttack) to the whole class.Three concrete overrides, chosen for how differently they touch gs:
visitSetResourcesa mode switch, then two clampswrites or adds to players[pack.player].resources depending on pack.mode (ABSOLUTE/RELATIVE), then caps at PLAYER_RESOURCES_CAP and floors at zero — the comment on the floor is explicit that server-side events are allowed to spend more than a player has, so this is where the deficit gets absorbed, not preventedvisitGiveBonusa four-way target switchresolves pack.who (OBJECT / HERO_COMMANDER / PLAYER / BATTLE) down to a concrete CBonusSystemNode*, then attaches the bonus there — the literal write side of the DAG this atlas's Bonus System doc traced only from the read sidevisitNewTurna pack that visits itselfclears OneDay bonuses and ages NDays/OneWeek ones off globalEffects, recomputes troop-mixing morale for every army that had one, then loops its own heroesMana and heroesMovement sub-packs and calls manaPack.visit(*this) on each — a composite pack applying its per-hero contents through the very same visitor instance that's applying itIf every state change really is just a pack applied through apply(), recording the packs is the same thing as recording the game. ReplayLog is built on exactly that assumption.
Recording of the game, kept inside CGameState so that it is part of every savegame. The server records every pack it sends out in CGameState::apply(), the client records every pack it receives — so both sides end up with a log of their own that they can replay on their own.
A ReplayChapter is one game day: a full gamestateSnapshot taken the moment the day starts, every pack that lands afterward, and a list of ReplayTurnMark ranges (simturns can make these overlap). recordPack() is called from inside apply() itself — deliberately before pack.visit(visitor) runs, per apply()'s own comment, “so that a snapshot taken here holds the pre-pack state.” configure(recordEntireGame, roundsKept) is the retention knob: by default only the most recent roundsKept days stay replayable in full; with full recording on, the whole game stays watchable from day one, using each day's own snapshot as a fast-forward point rather than replaying every pack since the start.
A second, smaller visitor sits next to GameStatePackVisitor in the same file — and it's already appeared in this atlas under a different name.
BattleStatePackVisitor implements the same ICPackVisitor interface for just six battle-mutation pack types (SetStackEffect, StacksInjured, BattleUnitsChanged, BattleObstaclesChanged, CatapultAttack, BattleStackMoved), constructed around an IBattleState & instead of a whole CGameState. Its only caller outside lib/ is AI/BattleAI/StackWithBonuses.cpp — the concrete class behind Adventure & Battle AI's HypotheticBattle and its nested HypotheticServerCallback::apply(), which that doc described only as something that “absorbs every state-changing pack instead of touching real CGameState.” Now the absorption has a name: it's this visitor, applying the same packs to a local stackStates shadow the exact way GameStatePackVisitor applies them to the real thing, just scoped to one battle instead of the whole game.