Home › Engine executable

Engine executable (CivilizationVI.exe)

The game program itself, as opposed to GameCore: the settings it reads, the switches it accepts, and the debug console it hosts. None of this needs a mod, but much of it is debug and configuration functionality that Firaxis never documented, so treat the descriptions as ours where they are marked inferred.

• Option files reference: the 194 options the exe registers, spread over four files (AppOptions.txt, UserOptions.txt, GraphicsOptions.txt, EOSOptions.txt), with section, type, description and file.
• Command-line switches: 16 fixed switches plus the generic -<Key> <integer> override for any integer option.
• Files and paths: the log files the exe writes, option and data files, folders, databases, mod discovery masks and install layout paths it refers to.
• .modinfo vocabulary: every element, component type, criterion, property and status code the exe understands in a mod, cross-checked against the shipped mods.
• Log and error messages: the texts the exe writes to its logs or shows on errors, by subsystem, searchable by a fragment of a log line.
• UI XML vocabulary: every attribute each ForgeUI control type reads from the UI XML files, checked against the game's own UI files.
• Telemetry configuration: the events and usage counters in the default telemetry configuration built into the exe.
• Imports and dependencies: the DLLs the exe loads (game libraries, Steam and Epic SDKs, Windows) and the functions it calls in them.
• Audio vocabulary: the sound event, state, volume and playlist names the exe passes to its audio system.
• Event data fields: the fields of the GameCore events as read by the exe's handlers (offsets and widths).
• Debug console: 129 commands with help text from 6 handlers, plus the 268 command phrases the handlers match.

How this was made. The Windows executable (DX11, July 2024 build) was analysed statically: option registrations and command phrases are read from the code that registers and matches them, switch names from the strings the start-up code compares, behaviour from disassembly. Function names come from the Linux build of the same engine, which exports its symbol names. Statuses follow the conventions: verified means seen in the exe (and, for options, also present in the option file the game writes); inferred follows from verified facts but was not tried in the running game.

Not covered yet: the Lua tables hosted by the exe (UI, UILens, Controls, Network, ...), the engine event buses, and the exe function map. Their analysis exists as topic notes; they will become entity pages here.