Difference between revisions of "Code Overview"

From TACWiki
Jump to: navigation, search
m
Line 17: Line 17:
 
==Program Flow==
 
==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. This game has special requirements, so the Update cycle is actually called every ms and a new "Logic Update" cycle is called if 16.7 ms have passed since the last cycle. This is transparent to the minigames, so they can call Update and Draw as if they were part of a standard XNA game.
+
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 (Oct 2007), some steps have yet to be implemented.
 
Below is the intended program flow for the game. As of this writing (Oct 2007), some steps have yet to be implemented.

Revision as of 10:32, 23 July 2008

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 home brew 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 contained in a self contained XNA project, AC_GraphicsEngine. This code encompasses all of 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 contained in 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 more information, 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 various mini games. The Content folders of each of these contain any and all content used by the games, respectively. These are usually divided further into different sets: 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 (Oct 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 minigame'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 minigame, the current game is that minigame
    • 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 are candidates for the current game
    • The colony simulator always exists
      • This allows minigames to interact with the simulator mode
      • Colony Simulator's Update and Draw cycles are only called while 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 only switch to the "mode selector" mode, not a minigame directly
    • Minigames can give the main game resources, but should 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