Pyrogenesis Engine Overview

Introduction

Pyrogenesis is the game enginefor 0 A.D. Its design goals include cross-platform compatibility (Windows, Linux and Mac OS X), efficiency (including hardware-accelerated 3D graphics), and extensibility through game mods and scripts. The core engine is written in C++. However, much of the high level game logic and user interface is implemented by scripts, which are written in JavaScript. This document focuses on the C++ engine (present in the source folder in SVN). We first describe the "life cycle" of a game and how the different engine modules interact. We then provide an overview of each module in the engine.

Life of a Game Session

When you launch 0 A.D, the game first loads from a combination of plain files in binaries/data as well as a zip archive containing commonly used files. The Virtual File System (VFS) module (implemented in lib/file) makes both files in the archive and regular files look like the same kind of File object to the game. Once the game is loaded, it displays a main menu GUI. The GUI engine is implemented by the gui module. It supports defining a GUI page layout in XML and then responding to events using JavaScript. These files are present in binaries/data/mods/official/gui/test. They interact with the game using the script functions exposed by the various C++ modules, which are generally in scripting/ScriptGlue.cpp. From the main menu, players may either start a single player game, host a multiplayer game, or join a multiplayer game.

The game logic code works the same way whether the game is multiplayer or single player - all that differs is how commands are treated. We'll first describe how the game logic code is organized before explaining the details of setting up multiplayer. The game logic is implemented in the simulation module, most notably in CSimulation, which handles all updates, and CEntity, which represents and updates an in-game object (unit, building, etc). In both multiplayer and single player, the game state is updated in turns, which are about 150 milliseconds each. Each turn, objects move to some new position, units may gather resources or do damage (depending on their gather rates), etc. A turn is handled in the CSimulation::Update method. In addition, between turns, the graphical objects in the game are animated continuously as fast as the frame rate permits by interpolating between their previous turn's position and their next turn's position. This is done by CSimulation::Interpolate. There is a CTurnManager object which says when it is time for a new turn (the simulation queries this object each frame). While the game is running, commands from the player (obtained through the GUI) are queued up using CTurnManager::QueueLocalCommand. Each turn, the turn manager provides a batch of commands to the simulation based on what was queued up. The only difference between single player and multiplayer is which turn manager is used: The multiplayer turn manager sends commands to the host, which buffers a batch of commands and then broadcasts them to all players, thus making sure that all clients get the same batches of commands. The single player turn manager sends commands directly to the simulation.

Outline for this document (from Gobby):

engine overview
  life of a game session from start to finish (pyrogenesis startup, VFS, menu GUI,
    creation of game object, loading, gameplay, scripts, etc), mentioning the
    components involved in each part
  explanation of multiplayer sessions
  explanation of how Atlas fits in

how to build the distribution
  supported compilers
  
  build system
    * only one copy of settings for Mac, Win, Unix (helps keep workspaces in sync)
    * what it means to update-workspaces
    * organization of the tree as static libraries
    * external libraries and how they are linked in
    * required libraries for Linux and OS X ("manual" installation of the game)

finding your way around: brief description of all repository directories
  merge the below descriptions of svn/source and those already found in "finding your way" 


overview of svn/source directories:
  collada: routines for loading COLLADA 3d models
  dcdt: triangulation library used by the pathfinder
  graphics: manages objects drawn on the screen, like textures, animated models,
    terrain patches, etc
  gui: a homemade OpenGL in-game GUI based on XML files
  i18n: routines for internationalization (translating in-game text)
  lib: Jan's collection of mostly low-level routines.
    allocators: memory (sub)allocators
    posix: POSIX emulation when on Windows
      file: efficient file loading code.
        http://www.wildfiregames.com/users/code/wiki/index.php?title=Virtual_File_System
        http://www.stud.uni-karlsruhe.de/~urkt/articles/study_thesis.pdf 
    res: resource handling (textures and sounds)
    sysdep: bridges differences between systems and allows 'portable' code
    debug (asserts), error handling, timing bit bashing, etc. - all the dirty details.
  maths: math code (linear algebra, geometry)
  network: the network engine (based on Enet; serializes game messages)
  pch: pre-compiled headers (this directory is required by the build system)
  ps: pyrogenesis engine - basically, 'everything else'
    utility classes, console, profiler, XML loader
  renderer: rendering algorithms, including sorting, quality settings, shadows and water
  script: scripting engine (Javascript)
  simulation: most of the actual RTS game logic
    simulation turns, entities, techs, unit AI, pathfinding, ..
  sound: (WIP) high-level sound and music engine
    builds on an abstraction of OpenAL
  tools
    particle engine, archive builder, map editor, random map generator, PMD exporter 
  overview of scripts in data/mods/official/scripts (entity functions & game startup)
  
misc topics:
  self-test
    * purpose
    * mechanism in VC IDE
    * where they lie 
  
  overview of art formats
  
  useful features for testing/development
    copy from the finding your way around - doc