Game Message Types and Format

The game messages are used for network communication and they provide an easily understood interface to game developers. A game message is an object and game developers only need to add their message to the properties of the object and then pass the object to the Network Toolkit via the Game Management Toolkit. Game developers do not need to know how the Network Toolkit deals with the game message as long as they know how to deal with a normal programming object. The properties of the object provide tooltips to game developers and hence the difficulty of maintaining game messages is reduced. There are two types of game message in this case, operational messages and tactical messages. The position message is the only tactical message and the others are

categorized as operational messages. The position message is used to communicate a robot update and other messages are used to set up the game such as connecting to a remote Master table, aborting a game, receiving the network status and the latest peer-list. Operational messages are mainly used for game control, network communication setup, network connection checking and peer list management. Hence, the operational messages are more important than tactical messages. Tactical messages are used to communicate robot updates on remote tables and missing a few robot updates is acceptable as long as a game can still run smoothly.

The following list outlines the possible messages associated with the two types.  Operational messages

 Network Message: messages about the status of network communication. They are sent between tables and are used for internal network status checking such as checking the network connection for a peer.

 Game Control Message: messages about the controlling commands. They are sent between tables for important game controls such as connecting with a remote master table, or sent between developers and tables such as receiving/ sending a robot image, colour and game map.

 Game State Message: messages about the current game state. They are sent between tables for state update (System State, Network State and Robot State).  Game Peer list Message: messages about the latest peer list. They are sent by the

 Other Messages such as text messages, goal messages and custom messages. These messages are sent between developers i.e. a developer can send these messages to all other developers. Game developers can use the events provided by the Game Management Toolkit to receive the messages and use the methods provided by the Game Management Toolkit to send them to all tables.

 Tactical messages

 Game Position Message: messages about the robot position and orientation. Each message contains information about the IP address, Port number, RoboTable Name and Robot Name of the sender at the head of the message. The reason we need this information is because the Network Toolkit deals with messages from multiple tables. Therefore, tables need to know where the message comes from and which peer object is associated with the message. The combination of IP address, Port number and Robot Name is the key string of peer objects. We can use the key string to locate quickly the sender reference peer object from a peer list. Hence, the header information is important for this project. The Robot Name is optional and is reserved for future improvement when multiple robots can play concurrently on a table. We need to be able to identify each robot is if we have multiple robots running on a table. Hence, the Robot Name is important to be part of the key string.

The timestamp used in the game message is obtained from a NTP (Network Time Protocol) server, and it is used for synchronization across the different tables at different locations.

The format of each message uses XML (Extensible Markup Language17) because it is easy to manipulate using regular expressions. The message string format contains four parts, as follows:

 Document Head: contains information about the message’s object type and the document identification to distinguish a game message from other messages. The object type is the assembly-qualified name of the system type (.NET environment) of the message object. The .NET environment provides a technique to create a new object based on the string format of the object type. Hence, we can reconstruct the original message object based on the string format of the message object.

 Message Head: contains general information such as IP, Port, RoboTable Name and Robot Name.

 Message Body: contains specific information.

 Message Tail: contains timestamp information for message sending.

There is serialization capability from the .NET environment that provides functionality to convert objects into XML files directly but the serialization has some disadvantages that we wish to avoid in this project. These disadvantages are listed below (Makofske et al., 2004).

 It is very inefficient because it may include information that is useless outside the context of the common language runtime (CLR)18. CLR is provided by the .NET Framework, which executes the code and provides services that simplify the development process.  It contains overheads to provide flexibility that may never be required by the end user.  Serialization and remote control cannot be used when a different wire format (standardized

protocol) has already been specified. For example, a serialized message has been sent using TCP protocol, and then the message has been forward by the receiver to another receiver using UDP protocol. The receiver may fail to deserialize the message.

We have developed a class called NetStream, which is used to convert the properties of the network messages into a flat string and reconstruct the flat string back to the original message object based on its object type. A sample of the output string is as follows:

<Identification>NTStream</Identification>

<ObjectType>NetworkToolkit.Class.ControlMessage</ObjectType> <Head>

<IP>10.4.17.3</IP> <Port>3334</Port>

<RobotableName>Lincoln-Table</RobotableName> <RobotName>Robot-Test</RobotName>

</Head> <Body>

<Controltype>System</Controltype> <Control>Connect</Control>

</Body> <Tail>

<SentTimeStamp>20/02/2012 5:34:42 p.m.</SentTimeStamp>

</Tail>