GalaxyEggbertGame

The application host: one XNA Game that owns every subsystem, runs the phases and the fixed 60 Hz tick, and draws each frame.

Location

Until 2026-11-09 nearly all of this lived in one GalaxyEggbertGame.cpp of about 8 400 lines; it was then split by topic into the seven files above (a refactor only). Older pages called the class GalaxyEggbertCnaGame.

Purpose

GalaxyEggbertGame is the glue between the engine-independent game code and CNA. It loads the content, owns the world (WorldRuntime), Blupi (BlupiController), the objects' rules (InteractionSystem), the renderers, the HUD, sound, menus, save data and the editor, and calls them in a fixed order once per 1/60 s step. It decides which phase the game is in (menus, Play, Pause, Win, Lost, Setup, Resume, Editor) and applies the state changes that cross subsystem boundaries: the events InteractionSystem and BlupiController report are turned here into deaths, camera shakes, sounds, HUD updates and mission changes.

Collaborators

Uses

• Simulation: WorldRuntime, BlupiController, InteractionSystem, HubDoors, ChaseCameraYaw, CameraShake.
• Presentation: TileAtlas, TerrainRenderer, WorldRenderer (fed a SceneFrame), ObjectModelTable, EffectParticles, PostProcess, UltraFinish, Hud, Sound.
• Input and UI: InputPad, ControlInput, GamepadInput, FocusNavigator, ScreenKeyboard, EditorDeviceControls.
• Persistence and tooling: SaveData, ResumeLog, DemoReplay, Autoplay, WorldEditor, CustomWorldStorage functions.

Used by

• src/GalaxyEggbertCNA/main.cpp only: it picks the player's folder, creates one instance, applies the command-line flags and calls Run().

Key members

The public interface is small: the XNA overrides plus the start-up switches that main.cpp sets before Run(). The rest of the header (about 1 500 lines) is private state and helpers; the table names a selection of both, verified against GalaxyEggbertGame.hpp as of 2026-11-10.

Phases

The phase is a GalaxyEggbert::Def::GamePhase (include/GalaxyEggbert/Def/GamePhase.hpp), the original's enum plus one value: None, First, Wait, Init (main menu and player select), Play, Pause, Lost, Win, Trial, MainSetup, PlaySetup, Resume, Ranking and Editor (Galaxy Eggbert's own). Trial and Ranking exist for numbering only; nothing switches to them. Menus are drawn and hit-tested by InputPad in the original's 640 × 480 layout; the title scene (worlds3d/title.vwr) plays behind the menu and the editor's slot list.

How it is used

The tick in Play

UpdateTickWorld (in GalaxyEggbertGameUpdate.cpp) runs the simulation in this order: terrain animation, input to steering, BlupiController::Step and its events (sounds, landing, teleports), actions (UpdateTickActions: switches, dynamite, vehicles), crate pushing, InteractionSystem::Update, terrain patching (RefreshTerrainMeshIfChanged), voyages, then UpdateTickEvents (shakes, Lost, Win) and UpdateTickCamera. A simulation speed factor (F5/F6, Tab) scales simDt; the tick itself stays 1/60 s. See Game Loop for the full walk-through.

const float simDt = dt * GameSpeedFactor(gameSpeed_);

worldRuntime_.Update(simDt);

if (terrainRenderer_ && UpdateTickWorld(dt, simDt, padPlayInput, inputPadClaimedMouse))
{
    return; // the world left (a mission over, the bye) or a phase took over
}

Loading a mission

LoadMission(n) reads the world's bytes once and passes the same bytes to WorldRuntime::LoadFromVwrStream and to ResumeLog::HashBytes, so the resume log records exactly the world that was played. AdaptHubDoors applies the hub rules (HubDoors) and can choose where Blupi arrives; in the main hub he starts beside the sign of the last world he played. PlaceBlupi gives Blupi the crate cells and calls BlupiController::SettleOnGround, so walking starts on the first tick. If the file is missing or invalid the current mission stays.

Command-line flags (parsed in main.cpp)

Demos, resume and the editor hand-off

• Resume. Every Play tick's input record is appended to a ResumeLog; on focus loss it is written, on a clean exit deleted. Continue replays it from the mission start (ReplayBatch).
• Demos. StartDemo/UpdateDemo replay a .gdemo through the same simulation; the player's profile, settings and resume file are frozen during a demo and restored after it. See DemoReplay and Demos & Recordings.
• Editor. The main menu's Editor button calls WorldEditor::EnterBrowser and switches to GamePhase::Editor; Play-Test runs LoadCustomWorldForPlayTest, and Win, Lost and Back return to the editor. Typing xnjttjpo in Play calls OpenMissionInEditor on the world being played (campaign saves keep a backup of the shipped file). The menu's Galaxy button calls StartGalaxy, which opens the editor's galaxy screen when the player has no main hub yet. See 3D World Editor and Your Own Galaxy.

Rules and invariants

• Platform code stays here. Android asset copying (AndroidAssets.cpp), Emscripten storage and the executable hash for the resume log's build identity live in src/GalaxyEggbertCNA/; the game and editor layers below do not know which platform they run on.
• Determinism. The tick is a fixed 1/60 s; randomness comes from InteractionSystem's generator, seeded per mission and recorded in the resume log and demos. Wall-clock time paces frames and drives the menu's demo idle timer and on-screen notices, never the simulation. Golden files, autoplay, resume and demos all depend on this.
• Cross-system state changes happen here. InteractionSystem reports events and requests; the host applies what needs Blupi, the camera, the HUD or the phase.
• Some long comments in the header describe states that no longer exist (the class comment still speaks of an invisible collision-only Blupi). Trust the code.

Tests

No ctest unit test constructs the host. It is covered by end-to-end checks that run the real executable:

• VerifyDemoReplays (ctest, needs xvfb-run; tools/verify_demos.sh): replays every shipped demo with --verify-demo and fails when one ends differently.
• Golden frames and trace (tools/verify_golden_frames.sh, tools/verify_golden_trace.sh): byte comparisons against tests/golden/; manual, need a display.
• Autoplay playthroughs (tools/autoplay.sh, tools/autoplay_all.sh) and live QA step files (tools/qa_live.sh).

See Testing.

Related pages

• Architecture and Game Loop
• Startup and Engine Integration
• Rendering, Input, Save Data & Resume
• Cheats & Diagnostics, Running the Game
• WorldRuntime, BlupiController, InteractionSystem, WorldEditor