Robot Game Systems Overview

Introduction
This article describes each of the major systems that are present in Robot Game
mini-game. Understanding these systems will help you to modify or re-use the
functionality provided by the Robot Games source code.
Most of this article is presented as diagrams that illustrate the relationship between
various classes, objects, structures, and members. These diagrams will aid you as
you explore the Robot Game source code. For more information about the function
of these classes, refer to the comments in the code, particularly the block comment
at the beginning of a class declaration.

Project Organization
This is the basic layout of the Robot Game mini-games projects:

Game Project (RobotGameWindows, RobotGameXbox):

This is the primary game project for the Robot Game mini-game. There are
separate projects for the Windows and Xbox 360 platforms
RobotGameWindows and RobotGameXbox. The game project references the
data project for the same platform as the game project (RobotGameWindows
references RobotGameDataWindows, and so on).
Most of the games content is built by the content project that is contained by
the game project, and this project references the content pipeline-extension
project, RobotGameProcessors.

Content Pipeline-Extension Project (RobotGameProcessors):

This project extends the content pipeline by providing additional importers
and processors for Robot Games content. This project references the data
project, and since content can only be built on Windows, this project
references the data project RobotGameDataWindows, regardless of the
platform associated with the solution and game project. That is why the
solution for the Xbox 360 platform contains both the Windows and Xbox 360
data projects.

Data Project (RobotGameDataWindows, RobotGameDataXbox):

This project contains the basic data types that are used by Robot Game. The
code in this project is not strongly associated with the Robot Game gameplay,
which means that this code can be easily re-used in other types of games.

Data Project Node Inheritance Diagram

Each object on the screen is treated as a node, and these types must first inherit
from NodeBase. Each node has a parent and child relationship. Each child node is
affected by the visible or enabled properties of its parent node.
This following diagram shows the chain of inheritance between NodeBase-derived
classes, with a brief description of what functionality each class provides.
Data Project
Classes
NodeBase

NodeBase: Maintains parent and child relationships

and property inheritance.

GameNode

GameNode: If Enabled is true, OnUpdate is called

on each registered GameNode when the game is
updated.

GameSceneNo
de

GameSceneNode: If Visible is true, OnDraw is

called on each registered GameSceneNode when the
game is drawn.

GameModel

GameAnimateM
odel
GameUnit

GamePlayer or
GameEnemy
Game Project
Classes

GameModel: Contains and processes an XNA

Framework Model object.
GameAnimateModel: Contains and processes
animation data for the Model object.
GameUnit: Contains and processes weapons,
collisions, and other actions for a Robot Game mech.
GamePlayer or GameEnemy: Contains and
processes data specific to player or enemy units in
Robot Game.

Data Project FrameworkCore Ownership Diagram

The FrameworkCore class, defined in the data project in Core\FrameworkCore.cs,
holds all of the game data statically and processes it throughout the lifetime of the
application. It manages this data through several management classes, including
SoundManager and InputManager.
The following diagram illustrates the ownership relationships between the top-level
objects in the data project, where each line represents a has-a relationship
between the types.

FrameworkCore

ResourceMana
ger

GameResource

CollisionContex
t

CollideElement

InputManager

InputCompone
nt

ParticleManager

ParticleSequence

SoundManager

SoundElement

GameScreenMana
ger

GameScreen

Viewer

RenderContext

ViewCamera

scene3DRoot
(GameSceneNod
e)
scene2DLayer
(GameSceneNod
e)
scene2DOverla
y
(GameSceneNo
de)
CameraBase

Viewport
Notes

All 3D game objects should be derived from GameSceneNode, and they

should be attached as children under the scene3DRoot object within the
RenderContext object.
All 2D game objects should be derived from GameSprite2D, and they should
be attached as children under the scene2DLayer object within the
RenderContext object.

Data Project Particle Description File (.Particle) Layout

Diagram
Particle systems are defined via .Particle files in the game project, in the Content\Particles
directory. Internally, a .Particle file is defined with XML, which is deserialized at runtime into
a ParticleSequenceInfo object.
Each ParticleSequenceInfo object contains several nested objects. The relationships
between these data types are shown by the following diagram, with each line representing a
has-a relationship.

ParticleSequenceI
nfo

TimeSequenceInfo
(1 - n)

ParticleInfo
(1)
TextureSequence
(0 - 1)

Data Project Particle System Class Ownership Diagram

At run time, particle systems are represented by ParticleSequence objects, which are
reconstituted from ParticleSequenceInfo objects, which are in turn loaded from .Particle
files. The ParticleSequence class derives from the GameSceneNode class, and all of the
active ParticleSequence objects are attached to the 3D scene root node.
Each ParticleSequence object contains several nested objects. The relationships between
these data types are shown by the following diagram, with each line representing a has-a
relationship.

scene3DRoot

3D scene root node in

RenderContext

ParticleSequen
ce

ParticleSequenc
eInfo

TimeSequence
(1)

TimeSequence
Data
(1 n)
Referenc
e

Particle
(1 - n)

Node

TimeSequence
Info

Owner
(GameSceneNo
de)
sceneRoot
sceneMesh
(GameSceneNo
(GameMesh)
de)
TextureSequen
scenePointSpri
ce
te
(0 1)
(GamePointSpr
ParticleObject
(1 n)

sceneSprite3D
(GameSprite3D
)

Non-node
member

sceneBillboard
(GameBillboard
)

Game Project User Interface Flow Diagram

The following diagram shows the flow between game screens over the lifetime of
the application.
MainMenuScreen
(GameMenuScre
en)
START

LoadingScreen
(GameScreen)

VERSU
S

VersusReadyScre
en
(GameMenuScre
en)

EXI
T

End of program

FirstStageScreen
(SingleStageScre
en)
VersusStageScre
en
(BaseStageScree
n)

LoadingScreen
(GameScreen)
SecondStageScr
een
(SingleStageScre
en)

Game Project User Interface Class Relationships Diagram

The following diagram shows the relationship between the user interface classes
that are defined in the Screen directory of the game project, including has-a and
inheritance relationships.
Class
inheritance
Member

GameScreen

BaseStageScreen

GameLevel

GamePlayer

GameSkybox

GameEnemy

GameWorld
TracerBulletManag
er

GameItemBox
TracerBullets

SingleStageScreen

FirstStageScreen

VersusStageScreen

SecondStageScree
n

GameWeapon

Game Project Scene Object Class Relationships Diagram

This diagram shows the NodeBase derived classes, expanding the earlier Node
Inheritance diagram to include all of the gameplay-specific classes defined in the
Items, Unit, and Weapon directories in the game project.
NodeBase
GameNode

GameWeapon

GameSceneNo
de

modelWeapon
(GameModel)
GameWorld

GameModel

GameSkybox

GameAnimateMo
del

GameItemBox

GameUnit
GamePlayer

GameEnemy

In the Data Project

In the Game
Project
Class inheritance
Class member

EnemyMech

EnemyTank

EnemyBoss

Game Project GameEnemy Artificial Intelligence Decision

Diagram
The following diagram shows the decision paths that a GameEnemy objects
artificial intelligence may take, where each node represents an AIBase objects
added the AIContext container in the GameEnemy.Initialize method
(Unit\GameEnemy.cs).

aiAttack
aiAttack
(OnAIAttackEvent)
(OnAIAttackEvent)
Attack time is
over.

The target is
on the left
side.

aiTurnLeft
aiTurnLeft
(OnAITurnLeftEve
(OnAITurnLeftEve
nt)
nt)

The target is
within the
shooting range.

There is no
obstacle in front.

There is an
obstacle in
front.

aiSearch
aiSearch
(OnAISearchEvent)
(OnAISearchEvent)

Turning right is
complete.

The target is on
the right side.

The target is
outside the
shooting range.

Turning left is
complete.

aiTurnRight
aiTurnRight
(OnAITurnRightE
(OnAITurnRightE
vent)
vent)

Movement is
complete.

There is no
obstacle in front.

aiMove
aiMove
(OnAIMoveEvent)
(OnAIMoveEvent)

There is an
obstacle in front.
Collided with
other mech while
moving.

AIBase object
Condition
Change

Game Project - Level Data Diagram

Each game level is defined in a .Level file, in the Content/Data/Stage directory
within the game project. Within each .Level file is XML data that defines the
contents of the level, which is deserialized at run time into a GameLevelInfo
object. (This object is defined in the game project in GameLevel\GameLevel.cs.)
Each level refers to many other objects that may be placed in the level, which are
referred to by filename. Each of these objects may themselves refer to other
content files. The following diagram shows the nesting relationship between these
data files, including the directories where the files are found and the expected
number of objects in each file.
<stage>.level
Content/Data/Stag
e
(1 - n)
<player>.spec
Content/Data/Playe
rs
(1)

<model>.FBX
Content/Models/Mech/Players
(1)
<animation>.Animation
Content/Animation/Players/
(model)
(0 - n)
<weapon>.spec
Content/Data/Players
(1)

<enemy>.spec
Content/Data/Ene
mies
(1 - n)

<model>.FBX
Content/Models/Mech/Enemies
(1)

<weapon>.spec
Content/Data/Playe
rs
(0 - n)
<itemBox>.spec
Content/Data/Items
(0 - n)

<model>.FBX
Content/Models/Weapons
(1)

<animation>.Animation
Content/Animation/Enemies/
(model)
(0 - n)
<weapon>.spec
Content/Data/Enemies
(1)

<model>.FBX
Content/Models/Items
(1)

<model>.FBX
Content/Models/Weap
ons
(1)