Delta3d Game Manager

SOFTWARE DESIGN DOCUMENT (SDD)
Delta3D Game and Simulation Engine
Game Manager
Version 1.0
October 26, 2005
Authored by:
BMH Associates, Inc.
5365 Robin Hood Road, Suite 100
Norfolk, VA 23513-2416
Telephone: (757) 856-5670
Fax: (757) 857-6781
Copyright © 2005 by BMH Associates, Inc

Delta3D GameManager SDD Copyright © 2005 by BMH Associates, Inc
Table of Contents
1 OVERVIEW.......................................................................................................................................................1
2 SCOPE ................................................................................................................................................................1
2.1 GAME MANAGER ...................................................................................................................................1
2.2 MESSAGE PASSING ARCHITECTURE .................................................................................................2
2.3 GAME ACTORS........................................................................................................................................3
2.4 COMPONENTS .........................................................................................................................................3
3 GAME MANAGER DESIGN ...........................................................................................................................4
3.1 CLASS DIAGRAM .........................................................................................................................................4
3.2 CLASS DEFINITIONS ....................................................................................................................................5
4 MESSAGING ARCHITECTURE DESIGN....................................................................................................6
4.1 MESSAGE CLASS DIAGRAM .........................................................................................................................6
4.2 MESSAGE CLASS DEFINITIONS ....................................................................................................................7
4.3 MESSAGE CLASSES .....................................................................................................................................8
5 GAME ACTOR DESIGN................................................................................................................................12
5.1 GAME ACTOR CLASS DIAGRAM ..................................................................................................................13
5.2 GAME ACTOR CLASS DEFINITIONS .............................................................................................................13
5.3 GAMEACTORPROXY CLASS DEFINITIONS ...................................................................................................15
6 COMPONENTS DESIGN...............................................................................................................................16
6.1 DEFAULT MESSAGE PROCESSOR .....................................................................................................16
6.2 RULES AND VALIDATION ..................................................................................................................19
6.3 NETWORK COMPONENT.....................................................................................................................20
List of Figures
Figure 1 Game Manager Set Diagram ...........................................................................................................................2
Figure 2 High Level View of Message Traffic..............................................................................................................3
Figure 3 Game Manager Class Diagram........................................................................................................................4
Figure 4 Message Class Design.....................................................................................................................................7
Figure 5 Game Actor Class Diagram...........................................................................................................................13
Figure 6 Create Actor ..................................................................................................................................................14
Figure 7 Create Remote Actor.....................................................................................................................................18
Figure 8 Publish Actor.................................................................................................................................................20
Figure 9 Network Component Overview.....................................................................................................................21
Figure 10 Network Component Diagram ....................................................................................................................22
Figure 11 Actor Shoot Action - Stage 1 ......................................................................................................................24
Figure 12 Actor Shoot Action - Stage 2a.....................................................................................................................24
Figure 13 Actor Shoot Action - Stage 2b ....................................................................................................................25
Figure 14 Actor Shoot - Stage 3a ................................................................................................................................26
Figure 15 Actor Shoot - Stage 3b ................................................................................................................................26
Version 1.0 October 26, 2005 i

List of Tables
Table 1 Messages.........................................................................................................................................................11
Table 2 Initial Ownership ............................................................................................................................................16
Version 1.0 October 26, 2005 ii

1 OVERVIEW
Software engineering has evolved rapidly during the past decade. Good game engine design
used to revolve around algorithmic innovations; however, designs of today focus more on
structural aspects. Games are simply too large and too complex; your best developers are now
system architects rather than assembly language optimizers. Consequently, the design phase is a
much more important part of the project lifecycle. Early games were designed on a napkin by a
single developer. Today, that couldn’t be further from the truth. Games are now a tremendous
engineering effort with numerous complexities such as the creation of game logic, engine code,
textures, models, and even game levels. To build a modern game requires many individuals:
designers, programmers, animators, graphical artists, and sound effect artists.
Game engines are moving towards data driven design and focusing on the game content creation
pipeline. Game engines allows for rapid integration of huge amounts of content. They allow
artists and game designers to think at a high enough level without resorting to programmers for
each and every task they want to complete. Despite the increased focus on design and
architectures, game development has become increasingly more difficult. Developers often have
to spend significant time developing basic interactions and object management that is truly
needed by all game applications. To make matters worse, programmers are not always able to
reuse existing software; spending large amounts of time “re-inventing the wheel.” They spend
much of their time creating software tailored towards their specific simulation instead of gaining
benefit from generic interfaces and constructs.
2 SCOPE
This document describes a new architecture called the Game Manager (GM) which hopes to
alleviate the problems mentioned above. The Game Manager is a new architecture for Delta3D
managing the interactions and connections between actors and components within a game. The
GM is what people commonly identify as the ‘game engine logic’. It is the layer that manages
messaging, networking, and the spatial and logical organization of game actors. The Game
Manager provides a core architecture that helps decouple applications from the underlying
Delta3D engine; thus enabling developers to build better games, faster and cheaper than before.
The Game Manager is an abstract layer built on top of Delta3D. This section gives an overview
of the four main GM modules: the Game Manager itself, Messaging, Game Actors, and Game
Components. The details of each module are provided in each design section following the
overviews.
2.1 GAME MANAGER

The Game Manager is the core of the architecture; the glue that holds everything in the system
together. It is responsible for managing both game and non-game actors, ensuring messaging
and inter-object communication, and directing component behavior. It knows which components
exist, what actors are interested in which messages, and what actors exist in the simulation. It is
then responsible for making sure messages get to the components and interested actors as well as
handling low-level events from the Delta3D system such as frame and pre-frame events. The
following set diagram illustrates a high level relationship between the Game Manager, its actors
and game components.
Version 1.0 October 26, 2005 1

Figure 1 Game Manager Set Diagram
2.2 MESSAGE PASSING ARCHITECTURE

Without communication between actors, the simulation would be rather useless; actors and
components should not exist in a vacuum in this new architecture. Therefore, the Game Manager
provides a messaging architecture that can send and process messages to and from objects (actors
and components) in the system. A Message is a single event within the system, plus all the data
that defines that event. Events are generated either by components or by actors and sent to the
Game Manager. The Game Manager exposes methods for sending and processing messages. In
the case of a networked game, the Game Manager might forward messages to the game server or
perform message validation. By enforcing communication through a central interface, there is
more flexibility to extend the behavior of the message passing architecture without breaking
existing code. The following figure illustrates a high level view of the message flow to and from
components and actors within the Game Manager.

Figure 2 High Level View of Message Traffic
Note that the Game Manager and message passing architecture set do not enforce either server-
centric or client-centric games. As many or as few of the actors in the system can be simulated
on the server. In a client-centric game, the server would just be a rules enforcer and mail router.
In a server-centric game, the clients would only exist to display the scene and accept user input.
It would also be possible to implement a peer-to-peer system by writing a new network
component (see Section 6.3), but that configuration will not be supported directly.
2.3 GAME ACTORS

In order to support all the behavior required by the Game Manager, it is necessary to create a
new baseline for actors. This baseline is the GameActor and GameActorProxy. Game actors are
mostly like regular actors. However, they have a minimum set of properties such as location,
rotation, and scale. In addition, game actors contain invokable methods, understand the
difference between local and remote, and know what it means to be published. Game actors also
have special behaviors needed by a Game Manager such as entering the world and updating data.
2.4 COMPONENTS
Game Actors are not powerful enough to handle all the ways in which messages could be used.
How does one interact directly with global game state and information or intercept the game
message stream? The answer is game components. A Component is a special type of object
that works with the Game Manager. Components receive all messages and can therefore work at
much higher level than an actor (See Figure 2). Components perform all sorts of behavior like
network connectivity, message logging, and rules validation. Like actors, you can add
Components dynamically at either runtime or compile-time. The component is a direct result of
the component based design discussion in the Game Actor Layer technical document (see
referenced documents).

3 GAME MANAGER DESIGN

There are two primary functions the Game Manager provides not relying on components; namely
Actor management and message routing. Actor management within the Game Manager is
broken into two primary groups. First, the Game Manager is responsible for GameActors
(Section 3). This implies the Game Manager must route messages and provide query abilities
both spatially and logically. Second, the Game Manager is responsible for regular ActorProxies.
These mostly represent the static world geometry in a given map or scene. By storing these
separately we ensure locality (since they cannot be published) and provide the necessary hooks
for future components that may operate on world geometry in addition to game actors.
Before diving into the details of the Game Manager design, the following class diagram and class
descriptions illustrate the essence of what the Game Manager represents.
3.1 CLASS DIAGRAM

The Game Manager concept is represented by the following class diagram.
Figure 3 Game Manager Class Diagram

3.2 CLASS DEFINITIONS

The Game Manager Class diagram describes the following classes. Note that certain design
decisions were made when diagramming the Game Manager. Namely, we have chosen to
implement a client/server model in this design. However, the Game Manager and messaging
architecture was also designed to generically support any underlying infrastructure.
3.2.1 GameManager
The GameManager class is the base class for the client and server game managers. It provides
the necessary behavior not available in specific Game Manager components. The first primary
behavior is actor management. This implies the GameManager stores a list of actors currently in
the simulation as well as additional data structures allowing for easy searching of actors both
logically and spatially.
The second primary function provided is game message routing facilities. The GameManager is
a centralized interface for sending messages between actors, thus acting as a mailman of sorts.
The base Game Manager has no concept of high-level message types; it only understands generic
messages that it must ensure get to the desired recipient. It also understands the difference
between a local or remote object. Local objects are owned by this GM; where as remote objects
are owned by another GM (usually another client GM or possibly the server GM).
Third, the game manager exposes an interface for adding and removing game manager
components. Game manager components should contain most of the interesting behavior in an
application. Components can be added and removed dynamically. For example, if one were to
implement a message-logging component, merely adding the component to the game manager
would enable logging. To disable message logging, remove the component. This functionality
can occur at compile time or run time depending on the needs of a particular application.
3.2.2 ServerGameManager
As previously stated, the baseline managers are geared toward a client/server networking
architecture. This class exposes a high level interface for allowing other game managers
(clients) to connect to the server game manager. The ServerGameManager stores a list of each
client game manager that has been authorized to connect to it. In addition, the
ServerGameManager stores a map or table of all the registered actors in the game or simulation
to the client that owns them. This allows the ServerGameManager to correctly identity the
recipient of messages.
Although implicitly stated, in order for clients to communicate between one another, they must
send messages through the ServerGameManager. This behavior is controlled by the actual
implementations of the base GameManager, rather than by the overall GM architecture. The
ServerGameManager and ClientGameManager work together to enforce the client/server
architecture and provides a cleaner and simpler interface to the client. For a more detailed
discussion of the networking architecture, refer to section 6.3.
Note that in a client only application (one client, no network), the GM is most likely a
ServerGameManager.

3.2.3 ClientGameManager
The ClientGameManager class is primarily responsible for storing the current visual
representation of the game or simulation and providing the necessary functionality to share its
state with the ServerGameManager. Once a client creates an actor, it must use the
ClientGameManager to publish that actor, thus making it visible to the outside world. The
ClientGameManager also provides methods for connecting to a ServerGameManager.
3.2.4 GMComponent
This is the base class for all game manager components. The base class really serves as an
interface for receiving messages. The base GMComponent also has a reference to the Game
Manager that owns it. This allows the GMComponent to send any messages it generates to the
GM as well as providing access to actors in the game. For example, a game rules component
may wish to determine if guards are within a certain range of the player and if so instruct the
guards to attack the player. This scenario implies the rules component needs to ask the game
manager for actors within a given range or radius and requires the use of the game manager’s
process message functionality.
3.2.5 DefaultMessageProcessor
See Section 6.1.
3.2.6 RulesComponent
See Section 6.2.
3.2.7 MachineInfo
This is a simple data class used to represent a particular machine on the network, or in other
words, another game manager. This class contains various attributes such as name, IP address,
as well as, a globally unique identifier. No two machines will have the same identifier no matter
where they physically reside on the network.
4 MESSAGING ARCHITECTURE DESIGN

Without communication between actors in a simulation, the simulation would be rather useless.
Therefore, the Game Manager is the mechanism by which actors communicate to each other and
to the world. The Game Manager exposes a method for sending messages from one actor to
another. These messages are then propagated to the appropriate recipients. In the case of a
networked or multi-player game, the game manager might forward it to the game server or
perform message validation. By enforcing actor communication through a central interface, it
provides more flexibility and the ability to extend the behavior of the message passing module
without breaking existing code.
4.1 MESSAGE CLASS DIAGRAM

Before we discuss the message passing architecture in its entirety, we must first discuss the
messages themselves. Messages are registered and created using a message factory. This
ensures that only registered messages are valid. Using a message factory also allows messages
to be created dynamically based on a message type description; thereby providing an easy way

for messages to be recreated and propagated throughout the system. The message classes are
represented in the following class diagram with a detailed discussion of each class in the class
definitions below.
Figure 4 Message Class Design
4.2 MESSAGE CLASS DEFINITIONS

The message class diagram is described by the following class definitions.
4.2.1 MessageFactory
The MessageFactory is the primary interface for building messages. As the class name suggests
it is a factory for building messages; thereby enforcing a type safe and easy to manage method
for building messages. The MessageFactory stores a list of registered message types which
determine what messages the factory knows how to create. The MessageFactory uses the
singleton pattern. This is very similar to the way Actors are created in the Dynamic Actor Layer.
4.2.2 Message
Messages are a high level container for tagging blocks of data. A message is essentially a
discrete event that has data and a MessageTypeEnum. Messages contain a sender identifier, a
time stamp, and a target identifier - implying they know who sent them and when, as well as

where they are going. Next, the Message class provides two interfaces for serializing itself to
and from a given medium. Messages can be converted to and from strings as well as
DataStreams. The string or data stream representation contains the data that maps to a particular
message instance. Lastly, the Message class provides access to a causality message, or a
message that caused the current message to be sent. This is similar in concept to a stack trace
when dealing with exception handling. Using the causality message, we can trace the cause of
each message through its chain of events that brought about its existence.
Each message has a senderUniqueId, a recipientUniqueId, a sendingActor, and an aboutActor.
The first two fields refer the unique ids of the Game Managers that are sending and processing
the message, respectively. The second two fields are special purpose GameActorProxy handles.
They hold onto the UniqueId of the actor and have a Get() method that takes a reference to the
Game Manager and returns the actual actor if it exists.
4.2.3 MessageTypeEnum
This is a simple data class that encapsulates information used to identify a particular type or class
of messages. This class is used by the MessageFactory for message creation and is also a very
useful class for any message filters that may get implemented. For example, a filter could be
written to track only messages in the “Info” category or to only listen for the
INFO_ACTOR_DELETED message.
4.2.4 DataStream
This class is a byte stream with methods to read and write data of various forms. It is used by the
Message class to store any data associated with a given message. The data stream is also
converted to a network stream when messages need to be transmitted across a network medium.
4.3 MESSAGE CLASSES

The following table illustrates the basic messages that are provided and supported by default
from the Game Manager. Each row in the table represents a single Message class. The message
is represented using a MessageTypeEnum (first four columns) and a description of the data that
should be associated with the message (column 5). This list is by no means exhaustive, as many
more messages will be required during each implementation stage. This table is merely provided
as a starting point for message design.
Enumeration Name Category Description Data
This message is sent

signaling a frame event.
DeltaSimTime,
It implies that actors that
DeltaRealTime,
TICK_LOCAL “Tick Local” “Tick” are considered local
SimTimeScale,
should run the next
SimTimeOfDay
frame of simulation and
rendering code.

This message is sent

signaling a frame event.
DeltaSimTime,
It implies that actors that
DeltaRealTime,
TICK_REMOTE “Tick Remote” “Tick” are considered remote
SimTimeScale,
should run the next
SimTimeOfDay
frame of simulation and
rendering code.
When a timer registered TimerName,

“Timer
INFO_TIMER_ELAPSED “Info” on the game manager SimTimeOfDay,
Elapsed”
fires. LateTime,
Property list
Sent when a new actor representing a
INFO_ACTOR_CREATED “Actor Create” “Info” has been created and snapshot of the
published to the world. current actor’s
state.
Sent by the
“Actor GameManager locally
INFO_ACTOR_PUBLISHED “Info” None
Published” when an actor is
published.
Sent when an actor has

“Actor Delete” been removed from the
INFO_ACTOR_DELETED “Info” None
simulation both locally
and remotely.
Sent when an actor’s

state changes enough to
Property list
inform the game world.
representing a
“Actor The update and create
INFO_ACTOR_UPDATED “Info” snapshot of the
Update” messages are actually
current actor’s
the same message, just
state.
with a different
enumeration
Sent to other clients Information

“Client
INFO_CLIENT_CONNECTED “Info” when a new client has about the new
Connected”
connected. client.
Sent after a new map has Map name that

INFO_MAP_LOADED “Map Loaded” “Info” been loaded was successfully
successfully. loaded.
“Client Information
Sent when a client wants
NETCLIENT_REQUEST_CONNECTION Connection “Client” about the new
to connect to the server.
Request” client.

Sent when a client

“Client
NETCLIENT_NOTIFY_DISCONNECT “Client” wishes to disconnect Client identifier
Disconnecting”
from the server.
Sent from a server to a

“Accept client informing the
NETSERVER_ACCEPT_CONNECTION “Server” Nothing
Client” client that it is ok to
connect.
Sent from the server to

Reason why
the client if a client is
NETSERVER_REJECT_CONNECTION “Reject Client” “Server” rejection
not allowed to connect
occurred.
to the server.
Information
about the map to
load.
Tells the recipient to It may also have

COMMAND_LOAD_MAP “Map Load” “Command” the map loading
load a new map.
request that
triggered this
command as the
cause.
Tells the recipient to

COMMAND_PAUSE “Pause” “Command” pause the game or Nothing
simulation.

COMMAND_RESUME “Resume” “Command” resume from a paused Nothing
state.

Reason for
COMMAND_RESTART “Restart” “Command” restart the game or
restarting.
simulation.
A client request that a

map be loaded. This
message should be Information
“Request Load
REQUEST_LOAD_MAP “Request” received by whoever has about the map to
Map”
the authority to load a load.
map. Most likely, this
will be the server.
A message
stating the
A server message sent to reason for the
“Message a client that a message it rejection, and
SERVER_MESSAGE_REJECTED “Server”
Rejected” sent was rejected as the “GetCause”
invalid. method will
return the old
message.

Table 1 Messages
4.3.1 Tick
Two tick events are defined in Table 1. Both tick messages define the same data, perform the
same function, and have the same implementing message class. The distinction exists so that the
same actor classes can be used for actors being simulated locally and ones that represent actors
being simulated remotely (i.e. in another Game Manager). Thus, actors can register to receive
TICK_LOCAL or TICK_REMOTE depending on their status.
Tick has several time-based data fields. Typically, actors will use DeltaSimTime for any time
related calculations needed since it will represent the amount of simulated time that has passed
since the last tick event. In many cases, the DeltaRealTime will be identical to the
DeltaSimTime because the simulation will be running at real time, but programmers should
avoid using real time for anything that is based on the progression of the simulation, such as
animation speed or dead-reckoning because changing the simulation speed will then not work.
This is especially important for applications that support playback or after action review.
SimTimeScale is the factor of real time that the simulation is running. SimTimeOfDay is the
wall clock time that the simulation should be following.
4.3.2 Timers
Timers allow actors to receive messages after a certain time elapses. Timers are registered by
name and actor on the Game Manager using the “SetTimer(GameActorProxy, name, time,
repeat)” method. Timers can be set to repeat or only fire once. Repeating timers or incomplete
timers can be removed via the “ClearTimer” method. Once the timer is elapsed, a
“TIME_ELAPSE” message is sent with the registering actor proxy in the “AboutActor” field.
The message parameters contain the name of the timer, the simulated time of day, and the
amount of time the timer was late. Timers will always fire AFTER the time expires, i.e. on the
first tick after the time has expired. Since timers will generally be late, the amount of time they
are late is included in the message.
4.3.3 Map Loading

Three messages are defined to control map loading. They are a request, a command, and an
information response. These messages exist to allow centralized control of map loading and
simultaneously provide distributed access to the functionality.
The system does not define which Game Manager in a network is the controller of map loading,
but the server will need to enforce the control via a custom rules implementing component. Only
the controller or the server would be able to send a COMMAND_LOAD_MAP message. The
server could be the controller itself. If a COMMAND_LOAD_MAP is sent to a client, the client
must load the given map and respond by sending an INFO_MAP_LOADED message. The
sender of the message must also load the map, but should not send the info message.
In order to facilitate server control of map loading or to allow any client to access the feature, the
REQUEST_LOAD_MAP message exists. A non-controlling client may send this message to
request a map change. When the controller receives this message, it can decide to accept or
reject the request. If it accepts it, it should send out a COMMAND_LOAD_MAP. If it rejects
loading the map, it should send SERVER_MESSAGE_REJECTED.

There is a special case that needs to be handled when loading maps in a client-server
environment. If, for instance, a map developer adds actor proxies that extend GameActorProxy
to the map, a problem arises where these game actors would be local to all of the
GameManagers. To solve this, GameActors will need a property describing its initial ownership.
The “ChangeMap()” method will handle the various cases. When loading a map, all the actors
are created by dtDAL::Project class and returned in a dtDAL::Map class. Then the method will
iterate over each actor, adding it to the list of actors. Then it will call “InvokeEnteredWorld()”
on each of the game actors. Finally, the server will call “GameManager::Publish” on all the
actors that have the “Initial Ownership” value “SERVER_PUBLISHED.”
Actors that are “SERVER_PUBLISHED,” will be created as remote on the client game
managers so that the server doesn’t have to send a deluge of create messages to the clients on
startup. Actors that will be published by the client must be created at runtime.
4.3.4 Message Rejection

In a client-server model, there is always the possibility that a client could send an authoritative
message it is either not allowed to send or is invalid given the current state of the simulation. In
this case, the server can ignore the message and send SERVER_MESSAGE_REJECTED to the
client.
The client could be coded to handle this message in certain circumstances, or the message could
be an error. For example, a client could be coded optimistically such that when an action is
performed, it will send a message notifying the rest of the simulation that the event occurred. In
some cases, the message could be invalid because a conflicting event occurred in another
simulation in the meantime. The server would send a rejection and the client would rollback the
change. In other cases, the client may attempt to send a message that it is not allowed to send,
such as COMMAND_LOAD_MAP, and the server would reject the message. The message has
a string parameter stating the reason for the rejection. GetCause() will also return the message
that is being rejected. This behavior is provided as a helper for developers of large systems.
Since, the server is responsible for validating all messages from a client, it doesn’t necessarily
matter whether a client handles or ignores a rejected message.
5 GAME ACTOR DESIGN

This design divides actors into two groupings: game actors and non-game actors. Non-game
actors are the regular actors that have been around for some time; subclass of dtCore::
DeltaDrawable with behavior and rendering. Regular actors can be loaded dynamically from a
library and modified generically through a property interface.
The second grouping, game actor, is new to the Game Manager; this architecture defines a Game
Actor and a Game Actor Proxy. GameActor extends dtCore::Physical and is intended to be the
base class for all actors used with the Game Manager. All game actors, therefore, have position
and rotation properties and may have physics enabled. GameActor can also be flagged as either a
local or a remote actor. GameActorProxy is a subclass of dtDAL::PhysicalActorProxy. The
GameActorProxy is an abstract proxy class. It extends the property interface to add invokables,
which are dynamic and can be queried like a property, but represent an action or method call.
Invokables are also used as handlers for listening to messages.

Game actors are written specifically for the Game Manager and have no real meaning without a
game actor proxy. Therefore, the pattern for writing game actors is to put the game actor and
game actor proxy in the same header and source file and name the file after the actor. This will
join the two conceptually, and make it easier for a developer to work with the actor-proxy pair.
The intention is that the actor and proxy will be designed and implemented as a unit.
5.1 GAME ACTOR CLASS DIAGRAM

The following class diagram provides a high level view of the Game Actor design.
Figure 5 Game Actor Class Diagram
5.2 GAME ACTOR CLASS DEFINITIONS

The base GameActor has virtual “TickLocal” and “TickRemote” methods that handle tick
messages. The implementation is empty so they do not have to be overridden in the subclass.
These methods will only be called if an invokable is registered for the message. See Table 1 for
more information.
GameActors can be flagged as either remote or local. This lets the system react appropriately
depending on who owns the object. In the local mode, the local GM, local components, and the
actor itself can simulate any real behavior. In a remote mode, the actor is really a ghost of an
actor being simulated in another, remote, Game Manager. It would be possible for a Game
Manager to have functionality of transferring ownership by merely flagging the local/remove
field for the actor on a different game manager.

In addition to the remote or local flag, actors have a published flag. If the actor is remote, the
published flag is meaningless. For local actors, published means that messages about that actor
are sent over the network. For practical reasons, an actor may not be changed from published to
unpublished; the result on remote GM’s is undefined. Therefore, this flag should never be
directly set. Instead, it is set by the Game Manager by calling “Publish()”. When an actor is
added to the Game Manager, a flag may be passed to the method “AddActor()” telling it to
publish the actor after it’s added. See Figure 6 Create Actor.
Figure 6 Create Actor
The “Set” methods are private, but the GameActor declares the GameActorProxy is a friend
class so it can call them. This way, subclasses of the GameActor cannot set these values. The
GameActorProxy will only set them in its own “SetPublished(bool)” and “SetRemote(bool)”
methods.

5.3 GAMEACTORPROXY CLASS DEFINITIONS

The GameActorProxy is the sole interface the Game Manager uses to work with the GameActor.
The reasoning for this is that dynamic creation and property setting is necessary to make a
network transparent and dynamic messaging system. For this reason, the GameActorProxy takes
on a greater role in the system than the regular ActorProxy. To support this behavior, several
methods and features have been added to the GameActorProxy interface.
A GameActorProxy can be easily identified. It will have a read-only, boolean property named
“GameActor” that returns true.
5.3.1 Invokables
Invokables are to method calls what properties are to data members. Just like a property,
invokables are created when the proxy is created, have names, and can be requested by name.
Like a method, they can be called, or invoked. Instead of parameters, they take a message,
which holds the parameters. Functors are used to implement the invokables so that they can be
made to call methods on the GameActor. Any method used with an invokable must take a Game
Message as the parameter.
Invokables can be registered to receive certain message types both on the GameActorProxy and
on the Game Manager. Invokables registered on the Game Manager will receive all messages of
a given type, regardless of which actor the message is about. If a GameActorProxy wishes to
receive any message of a certain type about itself, i.e. it matches the “AboutActor” field on the
message; it can register the invokable on itself for the message type. When the Game Manager
receives messages about an actor, it will always lookup the GameActorProxy checking to see if it
has an invokable registered for the message type.
5.3.2 Remote and Published

The GameActorProxy has public methods to query if the GameActor is remote or published. It
also has private methods to set these flags. The methods are private so that neither external
objects nor subclasses can call them. The GameActorProxy declares the Game Manager as a
friend class so that it can call the set methods. The Game Manager is the only class that should
ever call these methods.
GameActorProxy also has a property named “Initial Ownership” that specifies how the actor is
added to the simulation when a map is loaded. This property is read when a map is loaded. See
Table 2. Note that CLIENT_LOCAL and CLIENT_AND_SERVER_LOCAL objects may never
be published because the unique ids will have duplicates on other game managers.
Enumeration Display Name Description
The actor is only created on the server, but is

SERVER_PUBLISHED “Server + Published”
published immediately.
The actor is only created on the server and is not

SERVER_LOCAL “Server Local”
initially published.

Enumeration Display Name Description
The actor is only created on client GameManagers.

CLIENT_LOCAL “Client Local”
Actors with this setting may not be published.
The actor is created on both the client and the server

CLIENT_AND_SERVER_LOCAL “Client and Server Local” as a local object. Actors with this setting may not be
published.
Table 2 Initial Ownership
5.3.3 InvokeEnteredWorld
In “AddActor()” after the GameActorProxy is added to the list of actors in the Game Manager,
the Game Manager notifies the actor by calling “InvokeEnteredWorld().” This is a non-virtual
private method on the GameActorProxy that the Game Manager can call since it is a friend class.
This method then calls “OnEnteredWorld()” first on the GameActor and then on itself. In both
cases, “OnEnteredWorld()” is a virtual protected method that does nothing. It is provided as a
virtual that can be overridden if the actor needs to, for example, do some configuration that needs
to happen after it has been initialized. In some extremely rare cases, an actor may decide, for
some reason, it cannot be added to the world. In that case, it may throw a dtDAL::Exception.
Then the Game Manager will remove it from the actor list and re-throw the exception.
5.3.4 Lifecycle Messages

GameActorProxy has a method named GetActorUpdate() for generating a “create” or “update”
message for the actor. This method will take a list of properties to add to the message so that an
update can contain only certain property values.
6 COMPONENTS DESIGN
Components are the high level processors in this architecture. They receive all messages from
the Game Manager and can potentially perform lots of complex behavior. Anytime system level
sophisticated behavior is required, a component is most likely constructed. The following
section defines three example components that are part of the baseline GM architecture: the
default message processor component, the rules component, and the networking component.
Note that the following components are advanced concepts that have complex interactions and
sequence diagrams. The sequences chosen for this design define some of the most important
behavioral interactions within the GM architecture.
6.1 DEFAULT MESSAGE PROCESSOR

The DefaultMessageProcessor is a Game Manager component to handle messages that are
common to all games and simulations. As noted in the class diagram above, actor create and
destroy messages are handled by the DefaultMessageProcessor. Most, if not all of the message
handling methods can be overridden thus providing a great entry point for custom game or
simulation applications to hook into the message stream if custom behavior is required for such
messages.

It also handles object lifecycle. When it receives a message that a remote object was created, it
will create that object locally. It will also apply updates from remote actors.
The INFO_CREATE_ACTOR messages are sent by the Game Manager locally, but can be
overridden in the DefaultMessageProcessor before the message is sent over the network. This
could also be done by overriding the creation of the message in the GameActorProxy. A
possible reason to override the default behavior is to change the object class of an actor or to
add/remove/change message parameters.
One will note below that there is no non-virtual OnDestroyActor method. This is simply because
it will do nothing but check if the message is remote or local, which ProcessMessage() will have
to do anyway.
6.1.1 ProcessTick(TickMessage)
A virtual method for handling tick messages on this component.
6.1.2 ProcessCreateActor(ActorUpdateMessage)
This non-virtual method is called from ProcessMessage() when an ActorUpdateMessage is
received and either the message type is INFO_ACTOR_CREATED or the “AboutActor” field
refers to an actor that has not yet been encountered in the case of a remote message. It exists
simply to call the ProcessLocalCreateActor or ProcessRemoteCreateActor virtual methods
depending on whether the message refers to a local object or not. Since the actor will not exist
when a remote create message is received, this will use the senderUniqueId to see if it matches
the local GameManager. The ProcessRemoteCreateActor returns the actor for the message.
This method will then add the actor to the scene as a remote actor. It will then call
OnUpdateActor.
6.1.3 ProcessLocalCreateActor(ActorUpdateMessage)
This virtual method can be overridden to add a global handler for local create messages. This
does nothing by default.
6.1.4 ProcessRemoteCreateActor(ActorUpdateMessage)
This virtual method, by default, creates the actor represented in the message. See Figure 7.

Figure 7 Create Remote Actor
6.1.5 ProcessUpdateActor(ActorUpdateMessage)
This is called whenever an ActorUpdateMessage is received. This non-virtual method will
verify that the actor exists. If it doesn’t it will call “ProcessCreateActor”, and return. This will
use the senderUniqueId to tell if this message was generated locally, and call the appropriate
handler method.
6.1.6 ProcessLocalUpdateActor(ActorUpdateMessage)
This virtual method called to handle an update to a local actor. It does nothing by default. If this
method is overridden, the implementer should log an error if the actor does not exist.
6.1.7 ProcessLocalUpdateActor(ActorUpdateMessage)
This virtual method called to handle an update to a remote actor. By default, it applies the
updates to the local actor representing the actor in the message. If the actor does not exist at this
point, an error is generated which is then logged.
6.1.8 ProcessLocalDestroyActor(DestroyActorMessage)
This virtual method can be overridden to add a global handler for local destroy messages. This
does nothing by default.

6.1.9 ProcessRemoteDestroyActor(DestroyActorMessage)
This virtual method will destroy the local version of the given actor. It will log a warning if the
actor does not exist.
6.1.10 ProcessUnhandledLocalMessage(GameMessage)
This virtual method is called when any local message not handled in the default implementation
is called. This allows subclasses to easily process game-specific local messages. The default
implementation logs the unhandled message to the debug log.
6.1.11 ProcessUnhandledRemoteMessage(GameMessage)
This virtual method is called when any remote message not handled in the default
implementation is called. This allows subclasses to easily handle game-specific remote
messages. The default implementation logs the unhandled message to the debug log.
6.2 RULES AND VALIDATION

The rules component is used to implement game rules based on messages. It is intended that this
GMComponent will be used for enforcing all the rules of the message passing system as they
apply to this Game Manager. In a client-server network, this component will certainly be
different on the clients and the server, so there are two default implementations:
DefaultServerRulesComponent and DefaultClientRulesComponent.
An example would be when an INFO_ACTOR_PUBLISHED message is processed. It will
create a INFO_ACTOR_CREATED message and call SendMessage() on the Game Manager.
Any update or delete messages received about a published actor are passed to
GameManager.SendMessage(). The rules component could also be overridden, for example, to
allow only certain actor types to be published.
In the following descriptions, whenever a method is said to “send out” a message, it means that it
is calling “GameManager::SendMessage.”
If a client or the server wishes to heartbeat an actor, it should be handled on the tick event of this
component or with a timer since it can then just call the “Process” method for update messages.
This functionality may be added to the Game Manager base class eventually.
6.2.1 ProcessTick(TickMessage)
A virtual method for handling tick messages on this component.
6.2.2 ProcessPublishActor(PublishActorMessage)
This virtual method is intended to send out an INFO_CREATE_ACTOR message for the actor
being published. The default behavior is to create an ActorUpdateMessage with the
INFO_CREATE_ACTOR via the actor and send it out. On the client, this method will verify
that the message is local. On the server, the message is sent to all clients except the one that
originated the message. See Figure 8.

Figure 8 Publish Actor
6.2.3 ProcessDestroyActor(DestroyActorMessage)
This virtual method will propagate destroy messages to other clients by default. The client sends
it to the server and the server version sends to all clients except the originator.
6.2.4 ProcessUpdateActor(ActorUpdateMessage)
This virtual method will propagate ActorUpdateMessage messages to other clients by default.
The client sends it to the server and the server version sends to all clients except the originator.
This method is called whether the type is INFO_CREATE_ACTOR or
INFO_UPDATE_ACTOR. Local INFO_CREATE_ACTOR messages are ignored because
actors aren’t published until after the local create message is sent.
6.2.5 ProcessUnhandledLocalMessage(GameMessage)
This virtual method is called when any local message not handled in the default implementation
is called. This allows subclasses to easily process game-specific local messages. The default
implementation logs the unhandled message to the debug log.
6.2.6 ProcessUnhandledRemoteMessage(GameMessage)
This virtual method is called when any remote message not handled in the default
implementation is called. This allows subclasses to easily handle game-specific remote
messages. The default implementation logs the unhandled message to the debug log.
6.3 NETWORK COMPONENT

Since the Game Manager plays such a central role in actor management and organization, it
serves as a perfect entry point for networking capabilities. The networking capabilities are
designed to follow the component based design strategy mentioned in Section 2.1. The
following figure illustrates how the network component interacts with the messaging architecture
discussed in Section 2.2. Figure 9 is basically showing the flow of messages from the Client

Game Manager to and from the Server Game Manager. Network components in general,
communicate with the Game Manager using its ProcessMessage() and SendMessage() interfaces.
In most cases, the network components themselves will only perform actions in response to
SendMessage() requests. This instructs the network components to prepare and send the
message across the network. Upon receipt of a message from the network, the components
inform the Game Manager by calling ProcessMessage().
Figure 9 Network Component Overview
Due to its complex nature, the networking component is actually comprised of two separate
components, one for the server side, and one for the client side. Before discussing this in further
detail, it is important to note that this component is not designed for Massively Multi-Player
Online (MMO) game network requirements. Where as the GMComponent and Game Manager
designs could easily support this, we decided based on current needs, that our initial component
design would be centered on games supporting roughly 2 – 64 Game Manager clients. Although
this is just an estimate as actual scalability of this design will be dependent of several
implementation factors.
When designing a networking component, we generally have a choice between a peer-to-peer
model and a client-server model. Given the scope of Delta3D, the number of clients in a given
game or simulation is likely to be higher than is typically practical when using a peer-to-peer

networking model; therefore, the Game Manager will provide a client-server networking model
and the networking component is responsible for any and all network connectivity and flow.
6.3.1 Class Diagram

The network component structure is represented in the following class diagram.
Figure 10 Network Component Diagram
6.3.2 Class Definitions

The network component class diagram is described by the following class definitions.
6.3.2.1 GNENetworkComponent
The networking component of the Game Manager will use, on the backend, the Game
Networking Engine (GNE) for the actual network communication. Therefore, the
GNENetworkComponent implements the base functionality required by the separate server and
client components. In addition to normal GMComponent behavior, the GNENetworkComponent
provides methods to convert game messages to and from network packets. Network packets in

the GNE sense are more similar to logical packets of data. Therefore, the conversion to and from
game messages relies on the data stream functionality of the game messages themselves.
6.3.2.2 ClientNetworkComponent
The ClientNetworkComponent is instantiated in a client-side application and provides methods
for connecting to and disconnecting from the game server. Once connected to a server, the
ClientNetworkComponent stores the server information in its MachineInfo field.
6.3.2.3 ServerNetworkComponent
The ServerNetworkComponent differs slightly from the ClientNetworkComponent in that it
provides functionality to manage a list of client connections. As noted in the above class
diagram, the ServerNetworkComponent maintains a map of clients to their actual connections
which are encapsulated within a NetworkBridge instance.
6.3.2.4 ServerConnectionListener
This is a fairly simple class instantiated by the ServerNetworkComponent. Its primary role is to
listen for incoming connections. When an incoming connection is detected, it informs the
ServerNetworkComponent of the event. This class is assigned the throttling bandwidth of its
parent ServerNetworkComponent where it is actually used to manage the established
connections.
6.3.2.5 NetworkBridge
The network bridge talks directly to the underlying networking infrastructure. It both sends and
receives network traffic and informs its parent network component when appropriate.
6.3.2.6 MessagePacket
This is a simple class that extends the default GNE Packet class. It provides the necessary hooks
into the GNE packet streaming system and allows for the conversion of game messages to and
from transmission packets.
6.3.3 Sequence Diagrams

In order to have a better understanding of the network component and networking infrastructure,
this section discusses a use-case in which an Actor wants to shoot a target. This use-case
assumes a networked environment thereby demonstrating all classes discussed in the networking
section. The details of each message for each event are beyond the scope of this discussion,
however, we present a high-level view of the architecture and what types of messages might be
involved.
6.3.3.1 Player Attempts to Shoot a Target

The first stage in this use-case occurs when the user interacts with the game and generates the
message “I think I shot something.” This event might occur when a user presses a keyboard key
mapped to a shoot action. As noted in the sequence diagram below, this message is processed by
the Client Game Manager which then loops through its components and asks them to process the
message. One important thing to note is how the ClientNetworkComponent deals with this

message. Ultimately, the ClientNetworkComponent could process all messages it sees.

However, in this use-case we also demonstrate how the rules and validation component
discussed in Section 6.2 fits into this scenario. Therefore, in this case, the message “I think I
shot something” is a validation message and the ClientGameComponent does not process these
types of messages.
Figure 11 Actor Shoot Action - Stage 1
6.3.3.2 Sending the Message over the Network

This stage demonstrates how messages get serialized across the network. As stated in the above
class discussions, the NetworkBridge handles the actual network data flow.
Figure 12 Actor Shoot Action - Stage 2a

6.3.3.3 Validating the Message

The ServerRulesComponent is the primary class by which game validation occurs. In this case,
the server network component has received a new message, thereby instructing all of its
components to process the message. Since this is a validation message the default processor
does not handle it. Next, the message is received by a logger component. The logger component
is not relevant to this discussion; however, it provides yet another component for use with the
Game Manager. Finally, the ServerRulesComponent gets the incoming message. Upon
validation it responds to the clients by instructing the Game Manager to send out a message.
Figure 13 Actor Shoot Action - Stage 2b

6.3.3.4 Responding to the Client

This is simply the reverse of what occurred to send a message from client to server, only this
time we are going from server to client.
Figure 14 Actor Shoot - Stage 3a
6.3.3.5 Performing the Intended Action, Taking Damage

At this point, the message has either been accepted as a valid action, or rejected by the server. If
the action is deemed valid, the DefaultMessageProcessor applies the appropriate damage to the
actual actor based on the parameters parsed from the message. Again, for simplicity’s sake, the
DefaultMessageProcessor performs the actual response to this action. In a real game or
application there may be a more suitable component to handle such actions.
Figure 15 Actor Shoot - Stage 3b

APPENDIX A NOTES
■ The “Publish” method on the GameManager will infrequently be called by an external object.
This will only occur when an actor is not published when it is added to the GameManager
but later reaches a state where it needs to be.
■ The GameManager has a very singleton-like nature, but how actors and components get to
the GameManager could be through a local “parent” variable or via a singleton getter. Either
way, the GameManager will need to be created manually at startup because there is more
than one GameManager implementation.
Version 1.0 October 24, 2005 A-1

Delta3d Game Manager

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Delta3d Game Manager

Caricato da

Copyright:

Formati disponibili

SOFTWARE DESIGN DOCUMENT (SDD)

Delta3D Game and Simulation Engine

October 26, 2005

Copyright © 2005 by BMH Associates, Inc

Version 1.0 October 26, 2005 i

Version 1.0 October 26, 2005 ii

2.1 GAME MANAGER

Version 1.0 October 26, 2005 1

Figure 1 Game Manager Set Diagram

2.2 MESSAGE PASSING ARCHITECTURE

Version 1.0 October 26, 2005 2

Figure 2 High Level View of Message Traffic

2.3 GAME ACTORS

Version 1.0 October 26, 2005 3

3 GAME MANAGER DESIGN

3.1 CLASS DIAGRAM

Figure 3 Game Manager Class Diagram

Version 1.0 October 26, 2005 4

3.2 CLASS DEFINITIONS

Version 1.0 October 26, 2005 5

4 MESSAGING ARCHITECTURE DESIGN

4.1 MESSAGE CLASS DIAGRAM

Version 1.0 October 26, 2005 6

Figure 4 Message Class Design

4.2 MESSAGE CLASS DEFINITIONS

Version 1.0 October 26, 2005 7

4.3 MESSAGE CLASSES

Enumeration Name Category Description Data

This message is sent

Version 1.0 October 26, 2005 8

Enumeration Name Category Description Data

This message is sent

When a timer registered TimerName,

Sent when an actor has

Sent when an actor’s

Sent to other clients Information

Sent after a new map has Map name that

Version 1.0 October 26, 2005 9

Enumeration Name Category Description Data

Sent when a client

Sent from a server to a

Sent from the server to

Tells the recipient to It may also have

Tells the recipient to

Tells the recipient to

Tells the recipient to

A client request that a

Version 1.0 October 26, 2005 10

4.3.3 Map Loading

Version 1.0 October 26, 2005 11

4.3.4 Message Rejection

5 GAME ACTOR DESIGN

Version 1.0 October 26, 2005 12

5.1 GAME ACTOR CLASS DIAGRAM

Figure 5 Game Actor Class Diagram

5.2 GAME ACTOR CLASS DEFINITIONS

Version 1.0 October 26, 2005 13

Figure 6 Create Actor

Version 1.0 October 26, 2005 14

5.3 GAMEACTORPROXY CLASS DEFINITIONS

5.3.2 Remote and Published

Enumeration Display Name Description

The actor is only created on the server, but is