DEVELOPMENT SYSTEM IMPLEMENTION

The DOIT platform provides the high performance game servers and gateways but doesn’t include the clients. Because the client side development will be different according to different kind of the MMOG. The platform keeps the elasticity of the client side design, it allows the client side development according to game developer design themselves. The client side design can be implement by JAVA or C++ or other program language and can use the high performance network engine which provided by platform. The only thing which the programmer should be considered in the client side development process is the message protocol definition; it must be implemented follow the server side definition.

At the server side, there are some components must be implemented according to the definition of the platform. There are message, message handler, message factory, NPC configure, and server configure, vwlogic list document and game objects. Figure 3-2 shows the DOIT platform inner message process flow, it explains the relationship between the message, message handler and message factory. When an unknown message is sand to the server, it will be process at the ControlMessageHandler first.

According to the AVID of the message, the message will be delivery to the relative region. AVID is the player’s avatar id in the virtual world, and each AVID will be assign to one region according to the player’s position in the virtual world. The region

will find out the message handler at the Object Adapter according to the type value of the message, and then send the message to the handler. The handler will cast the unknown message to the original message type by using the message factory. And then execute the message operation, and create an update message return to the client.

Figure 3-2 DOIT Platform Inner Message Process Flow

The components which programmers must development are the messages, message handlers, and message factories in the inner message process flow and they are the generality part of the work load in the server side development. Therefore, the development system which we presented will focus on to these components’

development. In order to descript these components, the first step is to define the XML schema document according to the format of the message, and find out the relationship between these components. In the DOIT platform, each message is defined as a byte buffer. In the Figure 3-2, there is an unknown type message be sent to the server. This message is composed by two components. First is the fixed component, they include a message type, total message length, avatar id, player id and

the length of custom component. Each message will have the same format at the first component and next component is the custom format. According to the different messages’ function, the client will need to send some different attributes to the servers for the game logic operation. Therefore, the custom component is composed by some attributes. In the DOIT platform, we support some types of the attributes include int, string, Boolean, byte, short, long and float. For example, a player login message is sent when a new client join to the virtual world and it must include the player id and password attribute. So the custom component in the player login message is composed by a player id string and a password string, the full format is show in the Figure 3-3.

Figure 3-3 Examples of the Message Format

Because of the total length, avatar id, ct id, custom length attributes’ value are assigned dynamically during the message sending process, so we will not necessary to describe them. We must describe the others, include the message type, and custom attributes and we also describe the message version number, package name and the class path. Figure 2-1 is a MMOG message description document; it describes the

login and move message protocol. And we defined an xml schema document to verify it; the xml schema document is show in the Figure 2-2. After defined the MMOG script document, the next step is to design the code generation engine. The code generation engine will generate the code according to the attributes’ value which we described in the script document. Therefore, we analyze the code which we want to generate to induce some regular and relationship between these codes.

Figure 3-4 The Code of MoveMessage and LoginMessage

Figure 3-4 shows the code of the move and login message. We block all the

components which are different form another in the programs. The first block is the red color block; it includes the message name and attributes’ name and type and the message type value which all described in the MMOG script document. Therefore, this block code will be generated according to the MMOG script document directly without others logic determination. Next is the blue color block; because each message program will have encode and decode method, and the method logic operation will be different according to the attributes included by the message.

The decode method function is to put the attributes’ value from the byte buffer, and the encode method is doing the inverse work. Therefore, we must insert the code into the method according to the type of the attributes. In the decode method, we must use the JAVA byte buffer API to get the values from the byte buffer, and the sequence which we get the attributes must follow the sequence of the attributes which we described in the MMOG script document. And the encode method is also. For example, we described the move message in the Figure 2-1, it defined the move message have two attributes; direction and accept, and they will have the same order in the byte buffer.

Therefore, in the decode method, we assign direction attribute value by using the get() method to get a byte value from the byte buffer and then we use some code to get the accept attribute value. Because the JAVA byte buffer API doesn’t provide the method to get or put the Boolean and string value, we use a shot value to replace the Boolean value, and we use a short value and a byte array to replace the string. In the decode method, we use getShort() method to get a short value from the byte buffer and to differentiate the value. If it is equal to zero then it represent the Boolean value false, if it is equal to one then it represent the Boolean value true. So, we can assign a Boolean

value to the accept attribute according to the short value. If the attribute type is the string, then we use a short value to record the length of the string and use the bytes to store the string. By the same way, in the encode method we also need to use some JAVA byte buffer API to put the value into the byte buffer according to the type and sequence of the attributes.

The last block is the purple color block, if composed by the get and set methods. Each attributes in the message will accompany a get and a set method. We must insert these methods according to the attributes’ name and type. For example, in the move

message, the attribute direction will have the getDirection() and the setDirection() methods. In the getDirection() method, we will return a byte value which is the value of the direction attribute. And in the setDirection() method, we will send a byte value into the method, and this value will be assigned to the direction. Others attribute will follow the same way to generate the get and set methods.

Besides the message code, we will also generate the message factory and message handler code. The code of the login message factory and handler is show in the Figure 3-5. They are also follow a fixed format and the only thing that different is the class name. We just only insert the message name into the program where the red block area. Therefore, we can generate these codes fast without do any logic determine. After generated the code, the last work is to generate the vwlogic properties file. The game server will load the message handlers dynamically when system startup according to the description of the vwlogic properties file. The vwlogic properties file will store the entire handler and factories name and class path, and the record format is show in the next page. Each line represents a message handler or factory and it distributes the class path and message type.

1=cis.game.common.message.LoginMessageFactory/0x01 2=cis.game.server.handler.LoginMessageHandler/0x01 1=cis.game.common.message.MoveMessageFactory/0x02 2=cis.game.server.handler.MoveMessageHandler/0x02

Figure 3-5 The Code of LoginMessageHandler and LoginMessageFactory

After analyzed the code of the message, factory and handler, then we designed a code generation engine according to the results. The code generation engine must have some functions like load, parser and generate each kind of the code. Figure 3-6 is the DOIT platform code generation engine architecture. At first, we load the MMOG script document from the assignment path, and then use a XML parser [DOM] to parser the MMOG script document. According to the content of the document, call each generator to generate the code.

Figure 3-6 DOIT Platform Code Generation Engine

These codes are not accomplish, because there are still have some logic code which can’t be generated and need to be inserted into the program. Like the message handler program, the onMessage method is responsible for process the message, and it will need to connect to the database or reference to the server state. Therefore, we didn’t define the script way in advance; the programmer must insert the logic code into the method according to their necessary.