Chapter 5 Application Demonstration
5.5 Implementation and result screenshot
Message Name Type Message Contents
LoginMessage 0x01 Username, password
LoginResultMessage 0x02 playerId, posX, posy PlayerMoveMessage 0x03 posX, posY
PlayerUpdateMessage 0x04 updateCode, playerId, postX, posy
AFKMessage 0x05 playerId
AFKBackMessage 0x06 playerId
NPCBornMessage 0x0A npcId
NPCUpdateMessage 0x0C npcId, posX, posy
NPCDieMessage 0x0E npcId
AttackNPCMessage 0x0F npcId
LogoutMessage 0xFF
Table 5-2 Message types and contents
The message types and contents are shown in Table 5-2. We have deployed the game on some mobile phones, such that Nokia 6111, Sony Ericsson Z800i and
Motorola E1070, and through 3G or GPRS to communicate with server. Following, we show some screenshots of the demo game emulated on Sun JavaTM Wireless Toolkit 2.5 for CLDC. When the MIDlet is loaded, it shows a form to fill in the login information and connect to server:
Figure 5-2 Login form and game world
Figure 5-3 Player in the paused state
The white space in the bottom is the message box and the character in the center is the player himself with other NPCs around. When other players login, we can get the player update message and locate the position of them. Within the AOI (area of interesting), they broadcast their information and update. When some players change to paused state, others will receive an AFKMessage and then display the corresponding character with gray scale (as shown in Figure 5-3).
Figure 5-4 Demo game on both mobile and PC clients
For PC version, we implement it by using Java SE and Swing/AWT technology to present the game world. Figure 5-4 shows the demo game running on different platforms. They share the same game world and can locate and identify each other.
We assume that the PC client should be always online and the offline gaming is only supported in the mobile version. Moreover, instead of offering the same functions on both sides, we can let the mobile client to support a special part or a subset of full game functionality. The combination of the mobile and PC client provides a novel way to design an online game.
Chapter 6 Conclusions and Future Works
6.1 Conclusions
It is not an easy task to develop a middleware platform for MMOGs on mobile devices. We have figured out the problems that may encounter when designing a MMOG on mobile handsets. In the following parts, we discuss and analyze our system by the objectives we mention in section 1.3
y Easy to Adapt and Extend
To offer a flexible game development platform, we use message-based communication mechanism and reserve as few platform-specific data as possible.
Also, we provide the most resilience for defining the game objects, application events and network protocol. Game developers can easily map the game logic to message-oriented protocol and implement the game objects, events and low-level networking to form the virtual game world.
y Easy to Develop and Deploy
Development speed and time to market is quite important for game provider. We provide a dedicated XML syntax to define the message protocol and generate the underlying programming codes and configuration files. This makes the development of game protocol faster and the deployment of the changeful MMOG contents easier.
Moreover, it also helps to alter the message contents effortlessly to prevent game protocol cheating.
y Dealing with the Mobile-specific issue
The mobile clients have more uncertain issues than PC clients. We use the observer design pattern to monitor the application status and network connectivity.
Game developer can define their own events and listeners to trace and process. To handle the intermittent connectivity on mobile devices, we provide a mechanism to support disconnected game playing and can easily switch to connected mode when network quality restored.
y Combination with mobile and traditional MMOG
By deploying the MMOGs on DOIT middleware, we can provide a game world for diverse client platforms with the same communication protocol. In our demo game, we have show an actual example of this kind of MMOG, but also keep the flexibility to offer different game play under some situation. Although most of existing MMOGs are centered on one kind of end device, the combination of different client devices can bring out another opportunity of game playing.
6.2 Future Works
In current work, we focus on the client-side framework for mobile device that offers the basic interfaces to design a MMOG. However, there are still plenty of problems should be taken into consideration.
In server-side, we can provide a mobile-specific proxy (gateway) to process the connection from mobile clients. The proxy can wrap the message to distinguish the data come from or sent to the mobile clients and provide different game service. Since the mobile clients may be paused or lose connectivity intermittently, the proxy can help to keep the connection information to hand over and even caches it to reduce the
back-end data access. Furthermore, we can even provide different mobile-specific proxy to support different mobile client platform and help to handle client application status change. For example, when MIDlet clients change to paused-mode, the proxy can buffer the message to prevent message lose.
For the client-side, we just design the framework with three layers and provide interfaces to be implemented. But there are still some common issues should be encountered. For example, since the client application may be interrupted regularly, to avoid the resource missing, we should provide a serializable object interface to store and restore the mobile resource we hold.
Chapter 7 Reference
[1] International Game Developers Association (IDGA) http://www.igda.org/
[2] IDGA, July 2005, IDGA 2005 Mobile Games White Paper
http://www.igda.org/online/IGDA_Mobile_Whitepaper_2005.pdf [3] Ultima Online - http://www.uoherald.com/
[4] Lineage - http://www.lineage.com/
[5] World of Warcraft - http://www.worldofwarcraft.com/
[6] Java™ Platform, Micro Edition (Java ME) http://java.sun.com/javame/
[7] Connected Limited Device Configuration 1.1
http://jcp.org/aboutJava/communityprocess/final/jsr139/
[8] Mobile Information Device Profile 2.0
http://jcp.org/aboutJava/communityprocess/final/jsr118/
[9] BREW - http://brew.qualcomm.com/brew/en/
[10] Symbian - http://www.symbian.com/
[11] Windows Mobile - http://www.microsoft.com/windowsmobile/
[12] Chen-en Lu, Tsun-Yu Hsiao, Shyan-Ming Yuan. Design issues of a Flexible, Scalable, and Easy-to-use MMOH Middleware. In Proceeding of Symposium on Digital Life and Internet Technologies 2004.
[13] Tsun-Yu Hsiao, Shyan-Ming Yuan, “Practical Middleware for Massively Multiple Online Games”, IEEE Internet Computing (SCI), Volume 9, Issue 5, Sep/Oct 2005, pp.47-54
[14] Chen-en Lu, Shyan-Ming Yuan. “Design Issues of a Flexible, Scalable, Easy-to-use MMOG Middleware”, 國立交通大學，資訊科學系碩士論 文，民國 93 年 6 月
[15] Lun-Wu Yeh, Shyan-Ming Yuan. “A Research of Persistence Component on MMOG Middleware”, 國立交通大學，資訊科學系碩士論文，民國 94 年 6 月
[16] Ko-Hsu Su, Shyan-Ming Yuan. “A Framework of MMOG Development and Management System”, 國立交通大學，資訊科學系碩士論文，民國 93 年 6 月
[17] BigWorld Technology - http://www.bigworldtech.com/
[18] Ex Machina - http://www.exmachina.nl/
[19] GASP - http://gasp.objectweb.org/
[20] R. Pellerin, F. Delpiano, F. Duclos, E. Gressier-Soudan et M. Simatic. GASP:
an open source gaming service middleware dedicated to multiplayer games for J2ME based mobile phones. In 7th International Conference on Computer Games, November 2005
[21] Sun Microsystems, Inc., June 2003, Supporting Disconnected Operation in Wireless Enterprise Applications
http://java.sun.com/blueprints/guidelines/designing_wireless_enterprise_ap plications/index.html
[22] Extensible Markup Language - http://www.w3.org/XML/
[23] Mobile RPG Engine - http://sourceforge.net/projects/mobilerpg/
Appendix
A.1 XML Schema Definition of Message Protocol
<?xml version="1.0" encoding="UTF-8"?>
<xs:element name="Version" type="xs:string">
</xs:element>
<xs:element name="PackageName" type="xs:string">
</xs:element>
<xs:element name="Messages" type="messages_type">
</xs:element>
</xs:sequence>
</xs:complexType>
<xs:complexType name="messages_type">
<xs:sequence>
<xs:element name="Message" type="message_type"
minOccurs="0" maxOccurs="unbounded">
</xs:element>
</xs:sequence>
</xs:complexType>
<xs:complexType name="message_type">
<xs:sequence>
<xs:element name="MessageName" type="xs:string">
</xs:element>
<xs:element name="MessageType" type="xs:string">
</xs:element>
<xs:element name="Params" type="params_type">
</xs:element>
<xs:element name="Handlers" type="handlers_type">
</xs:element>
</xs:sequence>
</xs:complexType>
<xs:complexType name="params_type">
<xs:sequence>
<xs:element name="Param" type="param_type"
minOccurs="0" maxOccurs="unbounded">
</xs:element>
</xs:sequence>
</xs:complexType>
<xs:complexType name="handlers_type">
<xs:sequence>
<xs:element name="OnlineHandler" type="xs:string">
</xs:element>
<xs:element name="OfflineHandler" type="xs:string">
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:schema>
A.2 Development Example
In this section, we describe the implementation detail of the demo game as an example of developing a game on our framework.
A.2.1. Game Application
The mobileRPG is a game engine for Java ME MIDlet games. Every MIDlet application should extend the MIDlet class to be managed by the application management software (AMS). In the original mobileRPG source code packages, it is the Main class that extends this class. In the section 4.2 we describe the application interface of our framework. By extending the Gamelet class, the mobileRPG application can easily be supported by the framework.
import mmog.game.Gamelet;
...
public class Main extends Gamelet implements CommandListener, Runnable
{ ...
}
To monitor the MIDlet life cycle, we can register the GameAppListener and handle when the MIDletStateChangeEvent occurs.
A.2.2. Game Center
The game center works as a communication medium of network and application layers. One can design his own game center by implementing the game center interface. In our demo game, we implement a game center that supports different gaming modes and monitors the network status. It implements the GameCenter and ChannelListener interfaces and initialize the network engine. The game application can start or stop network connection and send messages through the public methods it provides.
When the network status changed, the game center will call the onConnected or onDisconnected functions of the GameApp.
// some example codes in the Main class // initial game center and register GameApp
this.gameCenter = new GameCenterImp(); // construct
this.gameCenter.setGameApp(this); // register GameApp // send logout message
LogoutMessage msg = new LogoutMessage(); // create message this.gameCenter.seedMessage(msg); // send
// in the GameCenterImp
// callback function of the ChannelListener
public void channelDisconnected(ChannelEvent e) { this.setConnected(false);
System.out.println("Network connection fail");
this.netEngine.close();
this.game.onDisconnected(); // notify the GameApp }
// in the GameApp (Main)
public void onDisconnected() {
// handle the disconnected situation ...
this.alertScreen(map, "Warning!! Network is disconnected!");
...
}
A.2.3. Implement the message handler
In the section 4.4 we propose a method to define the game protocol and generate the message class codes automatically. The message and message factory class only solve the problem of sending and receiving data through the network engine. To process the game logic, we must implement the corresponding message handlers. The message handler interface is as below:
public interface MessageHandler { /**
* Initiation.
* By overriding this method, we can obtain the game center.
* @param gameCenter The GameCenter */
public void init(GameCenter gameCenter);
/**
* Receive a message.
* @param msginfo The message info */
public void onMessage(MessageInfo msginfo);
}
The init() function is called when the handler is first loaded and registered by the GameCenter. While the game center receives the messages and dispatches to the corresponding handler, the onMessage function will be fired. If the handler just processes the simple game logic, it may only need the information contains in the received message. But if it needs to present some graphical interaction, it can get the GameApp through the GameCenter that obtained in the init function and operate more complex functions. Following is an example of LoginHandler that handle the login result from the server.
public class LoginHandler implements MessageHandler { private GameCenter gameCenter;
private Main main;
public void init(GameCenter gameCenter) {
// obtain the game center and get the GameApp (Main) this.gameCenter = gameCenter;
this.main = (Main) gameCenter.getGameApp();
}
public void onMessage(MessageInfo msginfo) {
System.out.println("Receive LoginResultmessage...");
// get the LoginResultMessage LoginResultMessage msg =
(LoginResultMessage) msginfo.getMessage();
main.setPlayerData(
msg.getPlayerid(), msg.getX(), msg.getY());
main.startGame();
} }