Code Overview

From TACWiki
Revision as of 21:22, 8 January 2009 by Belmonte (Talk | contribs)

Jump to: navigation, search

This page contains a high-level overview of the code for the Autism Game.

XNA

This game is built on XNA, which is suite of classes written by Microsoft. It provides methods for importing and playing content, a basic program flow (detailed below), portability, and has a good online community of homebrew game developers and hobbyists.

Layout

The code is divided into three categories: the engine code, utility code, and the game code.

The engine code is a self-contained XNA project, AC_GraphicsEngine. This code encompasses all the basic engine fundamentals. It includes lighting support, sprite and model entity support, sound management, game management, and game screens for use with basic applications. For more information, please see the tAC_Engine page.

The utility code is another self-contained XNA project called Util. This project defines input handlers, a logger for logging events for experimental data, and event-related information. For further details, please see the Util page.

The game code is stored in individual game projects. These individual game projects each represent either the main game (the Colony Simulator) or one of the several mini-games. The Content folders of each of these contain any and all content (non-code files such as graphics and sounds) used by the games. These are usually divided further into subsets: Fonts, Textures, Models, Shaders, and Audio. A sample breakdown of a game project and its related hierarchy can be seen on the Sample Game page.

Program Flow

An XNA game has 2 main cycles, Draw and Update. Both are called up to 60 times per second (usually). If the CPU load is high, XNA will automatically skip Draw cycles in an attempt to keep up with the Update cycles.

Below is the intended program flow for the game. As of this writing (October 2007), some steps have yet to be implemented.

  • The entry point for the game is Program.Main() (located in ColonySimulator\Program.cs)
    • Main instantiates all the major components used in this game and assigns them to the ColonyBaseApplication
    • The game mode is set to the startup sequence
  • mainGame.Run() is called
    • This calls several initialization functions (Engine\GenericGameManager.cs)
    • The Update and Draw cycles start (GenericGameManager.Update()/.Draw())
  • GenericGameManager.Update() calls the appropriate main game or mini-game's update based on the current mode (initially the startup sequence)
  • GenericGameManager.Draw() works the same way
  • There is a persistent game (the colony simulator) and also a "current" game
    • When the game mode is set to a mini-game, the current game is that mini-game
    • When the game mode is set to the colony simulator, the current game is the colony simulator
    • The startup sequence mode and main menu mode also are candidates for the current game
    • The colony simulator always exists
      • This allows mini-games to interact with the simulator mode
      • Colony Simulator's Update and Draw cycles are called only whilst it is the current game
  • When a game is finished, it must set the appropriate mode by calling ColonyBaseApplication.switchMode(...)
  • The game is ended by setting the mode to the shutdown sequence
    • Only the main menu or the pause menu should do this
    • This gives the user a last chance to save
    • Sends experimental data to the server or archives it if the server cannot be reached

Object Interactions

  • Each game is responsible for running and drawing itself (that is, a game must implement Update() and Draw())
    • This responsibility can be delegated to helper classes
  • Games should be independent
    • The main game (the colony simulator) should switch only to the "mode selector" mode, not to a mini-game directly
    • Mini-games can give the main game resources, but should do so only indirectly through the ScoreCard classes
    • With the exception of resources, any one game should not have any impact on any other game
  • Every game object should derive from Entity
  • Except for extremely specific circumstances, ALL objects or classes used in a game should derive from some class in the tAC_Engine namespace
    • If there is no suitable generic class, it may be necessary to create one and add it to the engine code
  • Use ColonyBaseApplication to communicate with Windows forms and exchange global data
    • See Code How To's for several examples of this, including checking time, screen dimensions, and setting game parameters