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)
