In this chapter, we will learn how to go about designing the avatar for a multiplayer game. We will explore the Hello World sample related to avatar and the essential features related to an avatar, such as chat and making friends. We will start by learning about Pulse Modeler, a tool that will help us design all the objects required for a multiplayer game. Learning about the modeler is essential because that is where we begin designing our game objects that will be shared across the network with other players. In the following chapters, we will use the modeler to design rooms as well as the objects to implement the game itself.
Specifically, we will learn the following:
- The Pulse modeler
- Modeling the avatar in the game
- Displaying players in the game
- Managing friends
- Chat
- Keeping track of high scores
The Pulse game development begins with a game schema file. Pulse modeler, among other things, generates code based on your schema definition and helps us create an object-oriented environment for ease of programming. Behind the scenes, during runtime, it also helps reduce bandwidth during client-server communication.
You will find PulseCodeGen.bat under $in. It requires three arguments:
- Schema File: the game schema file.
- Package name: a suitable package name according to your game code structure.
- Output Directory: the directory where the modeler should put your source files into.
If your game does not need any custom objects defined, you still need to create an empty schema file as shown below and have it run through the modeler:
<ObjectSchema> <import> <client import="pulse.gsrc.client.*" /> </import> </ObjectSchema>
For each class defined in the schema file, you may specify the parent class, be it one of GameAvatar, GameRoom, or GameState.
The following are the only three classes from which the developer should inherit from and add properties that are required for the game:
- GameAvatar
- GameRoom
- GameState
The following schema is borrowed from the multiplayer jigsaw game example that comes bundled with the Pulse SDK, which we will explore in great detail in Chapter 7:
<ObjectSchema> <import> <client import="pulse.gsrc.client.*" /> </import> <class name="PieceMatch" parent="GameState" classId="600" > <public> <property name="pieceId" type="int"/> <property name="dir" count="1" type="int"/> </public> </class> <class name="JigsawAvatar" parent="GameAvatar" classId="601" > <public> <property name="x" type="float"/> <property name="y" count="1" type="float"/> </public> </class> </ObjectSchema>
The entire schema should be defined within the<ObjectSchema> tag.
The import section remains pretty much static and must be included as part of your schema. Failing to do so would get you compiler errors. The import section tells the code generator to include the parent class files so that it can resolve the parent class references in the generated class files.
Each class is defined within the<class> tag; the name attribute is the name of the class that gets generated; and the parent must be one of GameAvatar, GameRoom, or GameState. You would normally want to define just zero or one GameAvatar and GameRoom entities as required. Depending on the game, you may want to define zero or as many GameState entities. It is important to note that the class ID must be unique and must start from 600 or above.
The generated code for PieceMatch is PieceMatchClient—the suffix indicates that the generated class is a client-side entity.
All properties defined must be within the<public> tag. The private and system tags are used only in the GNet product family. The name of the property must be unique within the class definition. The following table describes data types allowed in the schema.
The count by default is 1 if specified, and if the count is greater than 1, then the property generated will be of AS3 type Array.
It is quite hard to get the schema right the very first time as you progress through the development of the game, and when adding those last minute features, one may discover that either new classes are needed or new properties are needed for an existing class or that even some classes or properties are defunct and are no longer needed.
Whenever such a need arises, any schema update should be followed with a code generation and then the game code may be able to access and use the new classes and properties.
The following table enumerates the various data types available for the properties within a class:
|
Type name |
Length (bytes) |
AS3 Type |
Notes |
|---|---|---|---|
|
chars |
1 * count |
String |
Converts to UTF bytes. The count specified in the XML schema file must be large enough to hold the encoded bytes. |
|
byte |
1 * count |
int Array (count > 1) |
Only one byte times count is transferred over the network. |
|
short |
2 * count |
int Array (count > 1) |
Only two bytes times count is transferred over the network. |
|
int |
4 *count |
int Array (count > 1) |
Four bytes times count is transferred over the network. |
|
float |
4 * count |
Number Array (count > 1) |
Four bytes times count is transferred over the network. |
|
double |
8 * count |
Number Array (count > 1) |
Eight bytes times count is transferred over the network. |
|
timestamp |
8 * count |
Date Array (count > 1) |
Eight bytes times count is transferred over the network. |