Summary

To evaluate our platform, we use three rounds to experiment our platform. In the first round, we hope to realize the performance of underlying NetEngine. Until the client numbers reach to 4000, the average response time also have the level of less than 100 ms. But there is steep rise of standard deviation when the client number reach to 4000. In the second round, we try to find the performance baseline of client-gateway-architecture. The result is very similar to round 1 expect that the average response time is slightly larger than that of round1. So the client-gateway-server architecture doesn’t downgrade the performance very much. In round 3, we simulate the real game world. We implement the most significant game logic, avatar movement, in our experiment platform. We found that the performance bottleneck lay on the gateways. Furthermore, we observed the amount of update messages forwarded by gateway. We construct a formula to calculate the number of updates for one command. The result is that the gateway can bear about 5000~6000 messages per second.

Chapter 7 Future Works and Conclusions

7.1. Conclusions

To craft a MMOG middleware is not an easy job. In this paper, we figured out the issues we may encounter when designing an MMOG middleware. We discuss them in four criteria: scalability, flexibility, easy-to-use, and high performance.

In scalability, we use client-gateway-server architecture to scale up the platform.

In view of real world, we can scale up the number of clients connected by way of multiple gateways. In view of virtual world, we can scale up the number of game objects by way of spanning regions over the server cluster.

In flexibility, we reserve as few footprints as possible for the protocol. We also reserve the most resilience of game objects for developer. In addition, developer can extend the platform by designing their own plugin. There are also some flexibility concerns in designing the feature of Avatar Migration and Region Migration. We always hope the data can be migrated successfully as well as the data format is as flexible as possible. Furthermore, we use the Login Region pattern to overcome the login problem.

In easy-to-use, we simplify the underlying complexity of MMOGs by clean and thread safe API. We provide three layer of API: NetEngine library, DOIT API, plugin framework. Using DOIT API, game developer can develop a MMOG rapidly. We also suggest a easy way to send updates and receive update from an game object (by means of GameSpace and GameSpaceUtil). We also purpose a way to separate

the AI logic and game logic when designing the logic of NPC.

In high performance, we use an abstract NetEngine library, and different threading model for different demand. We deploy the event-driven NetEngine at the external interface of gateway for serving numerous clients concurrently while deploying the threaded NetEngine at the internal interface of gateway for exploiting the message aggregation feature to gain better performance. We also provided 3 experiments on our platform. We found, in some configuration, it got good performance when there are 4000 players on the same virtual world concurrently with 2 gateways and 2 servers. The bottleneck lay on the gateway component. It can hold 5000 messages per second with acceptable response time. We also can add more gateways in this platform if we need better service quality and quantity.

7.2. Future Works

In the current work, we focused on the scalable, flexible, high performance and easy-to-use issues. However, there are still plenty of issues should be taken into consideration.

Failover mechanism is absent in the current work. We hope that if a game server is done, we can recover the game states and continue to serve the clients. We may make use of the Serializable Capsule mechanism in Region Migration. We serialize the region state to the persistence store instead of another game server.

Cheating prevention is another place that has not been taken into consideration in the current work. The cheating prevention can be implemented as a gateway plugin.

We may allow the game developers to monitor and the incoming command messages and filter out the illegal message. Besides, we may provide the SSL version of

NetEngine in order to meet the requirement for high demand of online game, such as online shopping mall.

We also hope to provide a script language framework for game developers for writing game logics. There are some good script language implementation for java platform, like Jython and Groovy. We may provide a scripting framework on top of the DOIT API.

Furthermore, the easy-to-manage is also important for MMOG middlewares. The components are distributed over plenty of machines. It is desirable to have a centralize management console. In fact, we have made efforts on this feature. We adopt the JMX[19] and JMX Remote technology.

The last one is the location-free communication. In the current work, it is easy to implement the feature that the avatars talk to others around him. However, we didn’t provide the mechanism to communicate with a group located around the future world in the current work. We hope to provide this kind of location-free communication in our framework. Maybe the JMS[8] is a good choice to implement this feature.

Bibliography

[1] Zona Inc., http://www.zona.net/

[2] Butterfly.net, http://www.butterfly.net/

[3] Nathan Sheldon, Eric Girard, Seth Borg, Mark Claypool, Emmanuel Agu. The Effect of Latency on User Performance in Warcraft III. In Proceedings of ACM NetGames at Electronic Arts Headquarters Redwood City, California, USA May 22-23, 2003.

[4] M. Mauve, S. Fischer, J. Widmer. A generic proxy system for networked computer games, In Proceedings of ACM NETGAMES ’02, pp.25-28.

[5] Wish Engine, http://www.mutablerealms.com/

[6] Massively Multiplayer Middleware ,

http://www.acmqueue.com/modules.php?name=Content&pa=showpage&pid=1 15

[7] Xuan-Feng Lee, Tsun-Yu Hsiao, Shyan-Ming Yuan. A Scalable Middleware Architecture for Supporting Massive Multiplayer Virtual Worlds. In Proceeding of Symposium on Digital Life and Internet Technologies 2003.

[8] Sun Microsystems Inc. Java Message Service, http://java.sun.com/products/jms/

[9] BigWorld Technology, http://www.bigworldgames.com/

[10] K. Lee and D. Lee. A Scalable Load Balancing Scheme for Large-Scale

Multi-Server Distributed Virtual Environment Systems. In Proceedings of ACM Symposium on Virtual Reality Software and Technology (VRST2003), Osaka, Japan, 1-3 October 2003.

[11] P. Morillo, J.M. Ordu.na, M.Fern andez. An Adaptive Load Balancing

Technique for Distributed Virtual Environment Systems. Proceedings of the IASTED International Conference Parallel and Distributed Computing and Systems November 3-5, 2003 in Marina del Rey, CA, USA.

[12] Lars Aarhus, Knut Holmqvist and Martin Kirkengen. Generalized TwoTier Relevance Filtering of Computer Game Update Events. Proceedings of ACM NetGames 2002.

[13] Ashwin R. Bharambe. Mercury: A Scalable Publish/Subscribe System for Internet Games. Proceedings of ACM NetGames 2002.

[14] Sandeep Singhal, Michael Zyda. Networked Virtual Environments, Design and Implementation. Published by Addison-Wesley, 1999.

[15] Daniel Bauer. Network Infrastructure for Massively Distributed Games.

Proceedings of ACM NetGames 2002.

[16] Matt Welsh, Steven D. Gribble, Eric A. Brewer, and David Culler. A Design Framework for Highly Concurrent Systems. UC Berkeley Technical Report UCB/CSD-00-1108, Submitted for publication, April, 2000.

[17] Sun Microsystems Inc. JavaBeans Architecture,

http://java.sun.com/products/javabeans/

[18] Sun Microsystems Inc. Java Servlets API,

http://java.sun.com/products/servlet/

[19] Sun Microsystems Inc. Java Management Extension,

http://java.sun.com/products/JavaManagement/

Appendix A System Protocol

ID Name Direction Description

0x01 CTRL GÆS The control message 0x02 UPDATE GÆS The update message 0x03 AVACONN GÆS Notify that a channel connected.

0x04 AVADISC GÆS Notify that a channel disconnected

0x05 AVACLOSE SÆG Notify that a avatar channel is close by game logic

0x06 AVAMIG GÆS SÆG

Send when a avatar migrated.

0x07 GATHEL GÆC GÆS

Say hello and tell the gateway information.

0x08 SRVHEL SÆC Say hello and tell the server information

0x09 RMINIT C broascast(*1) Send when a coordinator initiate an region migration

0x0A RMREADY SÆC The destination server says he is ready to receive migration data.

0x0B RMCOMPLETE SÆC C broadcast(*1)

Send when the region migration is complete

0x0C RMFAIL SÆC C broadcast(*1)

Send when a region migration fails.

0x0D AVACONN_ACK SÆG ACK of AVACONN 0x0E AVAMIG_ACK SÆG ACK of AVAMIG

G: Gateway, S: Server, C: Coordinator

*1 A coordinator broascasts the messages to evey participents of the region migration.

0x01 CTRL Direction: GÆS Description:

The control message Format:

long avatarid short controlType short controlLength byte[] wrappedMessage

0x02 UPDATE Direction: GÆS Description:

The update message Format:

long avatarid short updateType short updateLength byte[] wrappedMessage

0x03 AVACONN Direction: GÆS Description:

Notify that a client connected.

Format:

long avatarid

0x04 AVADISC Direction: GÆS Description:

Notify that a client disconnected.

Format:

long avatarid

0x05 AVACLOSE Direction: SÆG Description:

Notify that a avatar channel is close by game logic Format:

long avatarid

0x06 AVAMIG

Direction: GÆS, SÆG Description:

Send when a avatar migrated.

Format:

long avatarid int srcRegionid int destRegionid int x

int y

short dataLength

byte[] data

0x07 GATHEL

Direction: GÆS, GÆS Description:

Say hello and tell the gateway information Format:

int gatewayid

0x08 SRVHEL Direction: SÆC Description:

Say hello and tell the server information Format:

int serverid

0x09 RMINIT

Direction: C broadcast Description:

Send hen a coordinator initiate a region migration Format:

int rmid

int regionid int srcServerid int destServerid

0x0A RMREADY Direction: SÆC, CÆS Description:

The destination server says he is ready to receive migration data. This message will be forwarded to source server by the coordinator.

Format:

int rmid int host int port

0x0B RMCOMPLETE Direction: SÆC, C broadcast Description:

Send when the region migration is complete.

Format:

int rmid

0x0C RMFAIL

Direction: SÆC, C broadcast Description:

Send when the region migration fails.

Format:

int rmid

0x0D AVACONN_ACK Direction: SÆG

Description:

ACK of AVACONN Format:

long avatarid

0x0E AVAMIG_ACK Direction: SÆG Description:

ACK of AVAMIG Format:

long avatarid