EVALUATING MULTI USER DISTRIBUTED ACTION GAMES ARCHITECTURES ON A CORBA PLATFORM Hendrik T. Macedo, Alessandro C. M. de Araújo, Dave A. T. Cavalcanti, Rogério de C. Andrade, Charles A. G. Madeira and Carlos A. G. Ferraz Center of Computer Science Federal University of Pernambuco PO. Box: 7851,50732-970 Recife-PE, Brazil E-mail: {htm, acma, datc, rogerio, cagm, cagf}@di.ufpe.br Abstract. The development of distributed applications is rapidly growing and some applications, like those which manipulate graphics, images and sounds, need special care. In this paper, we extend the two architectures performance comparison we’ve made at [13] with another one based on CORBA event channel to design a multi user action game that heavily uses sounds and images, identifying the main drawbacks of this kind of implementation. We have run the three different game implementation in a dedicated network to measure the packets traffic, bandwidth use, events lost and data consistency on the redrawing process of each player’s screen. As results, we see that to different kinds of games the use of appropriate architectures may lead to a great processing economy, network traffic reduction and gains on the user presentation quality. Keywords: Distributed games, Architectures, CORBA.
1
INTRODUCTION
Distributed solutions have already been applied for many different application domains, and field-tested distributed systems are steadily increasing in number. It is extremely important to note that some software engineering is necessary to avoid some sources of failure, if not guarantee the complete success of the systems built. Distributed action games is a very interesting applications domain, not just because of the allure that stand alone or networked and distributed games cause in many people but, mainly, because of the diversity of architectures we can develop. A specific architecture could be made responsible for some bad final performance results, invalidating, for example, the commercial use of the game implementing it. In this paper we propose three different distributed architectures for action games, based on the CORBA platform. A game prototype has been developed to apply these architectures and to measure their impact in terms of generated network traffic, interface consistency and user presentation quality. The paper is structured as follows: in section 2 we show the main issues related to the development of distributed applications. In the section 3 we present the game chosen to be implemented using different architectures, and in 4 we detail the three architectures developed. The performance analysis is made in section 5. Finally we draw some conclusions in section 6.
2
DISTRIBUTED APPLICATIONS ISSUES
The development of distributed networked applications are a little bit complex yet. This complex usually leads to a bigger effort in managing eventual implementation time bugs. And why is that? First, because as networked applications, events are being processed in parallel. Second, because of the middleware. In contrast with the traditional client/server (CS) approach where the client identifies and communicate directly with the server, the software called middleware works as a functional layer between the client and the server. The Common Object Request Broker Architecture (CORBA) [1] is an example of some initiatives that exist to attempt to spread out the use of middleware. Developing applications that works on a middleware software is a little bit hard. To this, add the new concept of distributed objects [2]. The hard thing to be done is to hide from the final user (location transparency [2]) which machine is working as a server. The users must be saved of the concern on having to know which machine they have to connect to play. Besides, the application must present some desired features, discussed below.
2.1 INTERFACE CONSISTENCY, USER PRESENTATION QUALITY AND SYNCHRONIZATION Interactive applications must have fast answer to each user action. It is extremely necessary to generate a consistent view of these actions while reflecting the correct state of the application. The delay in a screen update may degrade the user presentation quality, and possibly cause faults in future actions. In the case of an action game, synchronization of the application states is critical since any small delay of some user’s screen update may be disastrous to the sequence of the game. Some of these problems could be solved introducing the idea of a centralized server object that would be responsible for performing all clients’ requests and keeps the global of the game state, guaranteeing consistent information back to the clients. 2.2 NETWORK TRAFFIC REDUCTION The traditional client/server approach, with a centralized control, generates a certain amount of network traffic, because of the continuous data swap between the server and the clients. To distributed multimedia applications [3], where sound, video and images pass through the network, network is an important traffic issue to deal with. This particular task involving continuous and intensive client/server interaction through the network may result in bandwidth waste. A possible solution to reduce the network traffic is to keep all the required media in the clients and summarize the messages exchanged between clients and servers to useful information about any application state change.
3
CASE STUDY: NETMAZE
The main objective of our work was to show that it is possible to think in distributed platform as a viable framework to the development of applications that use sound, images, and other kind of media, without a big memory consumption or a large bandwidth waste. NetMaze is a multi user distributed action game. An user is responsible for managing a prey and the others, hunters. The hunters should move through a maze trying to catch the prey. The longer the prey keeps alive, more points the user can make. The game has five phases and each one has a different maze and a different background image. The phase change occurs when the prey is caught. At that moment, an image announcing the phase change appears on each client screen, plays some specific prey or hunter sounds and restarts the game in the next phase, with a different client as the prey. We have also implemented another different way to play the game, by using the Intelligent Agent [4] idea to give some autonomy to the prey and even the hunters. JEOPS [5] was the inference engine adopted. Some direction rules were defined to guide the players through the maze. 3.1 INSIDE THE GAME We have implemented three different architectures for the game, but the essence is the same: there is a unique object that is responsible to maintain the game consistency and manage the clients requests to avoid unexpected situations. The interface operations methods are synchronous [2] to guarantee that only one client will modify the game state at a time. It is necessary to avoid inconsistency as images overlap. It is important to clarify that there is no multimedia data network traffic, since all the images and sounds are kept in the clients machines. A keyboard event1 is sent to the server object, which updates the player state with the new information in its information base. In case some sound or image is needed, the server informs the clients about this and the clients are completely responsible for trigging those. The way how information is sent back to clients from server is what distinguishes one architecture from another.
4
THREE ARCHITECTURES
We called Active Client (AC) the first architecture. The AC architecture is based on a single server object. The clients have to send movement signals to the server object and also require the current state of the game. In this architecture, even if there is no change in the state of the game, screen, etc, the clients keep requiring and receiving information from the server (figure 1.a). The second architecture is called Call-Back (CB). In CB, the server object itself is responsible for sending to the clients the current state of the game, and just when there is a modification in this state. Then, 1
Information of which direction key was pressed.
the server object accesses the clients interface methods to send the new game state. In contrast to the previous architecture, there isn’t unnecessary screen updates in the client machines (figure 1.b). The third architecture (EV) uses the CORBA Event Service [6]. The clients are connected to the event channel which is kept open along the game duration. When any game state modification occurs, the server object generates one single event which is multicasted through the channel (figure 1.c).
1
1
2
Clients
Clients
1
2
server object
a)
Client object
2 server object
server object
b)
event channel
c)
Figure 1: a) : AC, where 1 is the request for movements and 2 is the request for current state. B) CB, where 1 is the request for movements and 2 is when the server sends a state update. c) EV, where 1 is the request for movements and 2 is the multicasting of the event.
5
PERFORMANCE ANALYSIS
To evaluate the gains of each designed architecture, we ran the game in a dedicated network (figure 2) and measured the network traffic using TCP-dump [7]. The game objects communicate via Inprise’s Visibroker [6]. Pentium® Computers MMX-200MHz, 64 Mbytes RAM, Windows NT Workstation ® A B C
Unix FreeBSD
HUB 3Com® with 12 portas Ethernet
Server
Traffic Monitor
Ethernet 10 Mbps Network
Figure 2: Network Topology
The autonomous version was used to make the tests. It was an attempt to avoid some human intrinsic movements imprecision; without having to use the control keys, we gain on movement uniformity. Each experiment was measured for 2 minutes. We observed the amount of packets over the network, the amount of screen updates sent by the server in function of the amount of clients movement requests and the number of events lost2. 5.1 PACKETS TRAFFIC AND EVENT LOST We analyzed the network traffic related to the number of packets sent and received by clients. There is no traffic between clients, only between clients and the server. The figure 3 below show the comparative results between the architectures. The darker bar represents the number of movements request, the brighter, the number of received updates. packets
packets
packets
3,000
3,000
3.000
2,500
2,500
2.500
2,000
2,000
2.000
1,500
1,500
1.500
1,000
1,000
1.000
500
500
500
0
0
a)
A
B
C
0 A
B
A
C
b)
B
C
c)
Figure 3: a) AC architecture, b) CB architecture, c) EV architecture
The first architecture presents an extra client to server traffic (represented by the intermediate color tonality). The screen updates requests are responsible for that. We note that the number of screen updates 2
The amount of game state changes that were not received by the clients.
sent by the server and the number of movements requests made by the clients were very similar for both AC and CB architecture. With the respect to the EV architecture, more movements request were made by the clients, while there was a small reduction on the number of screen updates sent by the server. The following figure show the total amount of movement requests made by three clients and the number of screen updates sent by the server. The first column represents the sum of all clients movements request. The clients are represented by the letters A, B and C. packets
pacotes
pacotes movimentos enviados
8,000 7,000
movimentos enviados
8,000 7,000
8.000 7.000
6,000
6,000
6.000
5,000
5,000
5.000
4,000
4,000
3,000 2,000 1,000 0
A
4.000
3,000
atualizações bid
B
2.000
1,000
1.000
0
a)
3.000
atualizações recebidas
2,000
C
sent movements
A
B
0
C
b)
received updates
A
B
C
c)
Figure 4: a) AC architecture, b) CB architecture, c) EV architecture
Considering that each player move represents a game state change, we could easily think that the number of server requests should correspond to the total players movement requests. However, as an action game, there are frequently many movement requests from various clients at same time and the game state changes referring to these movements may be passed to the clients in one packet only. Even though the high percentage of events lost, this does not affect the user screen update consistency. A higher number of received updates would not affect the user presentation quality, due to no visual perception of these extra movements. We’ve noted that for the EV architecture the total amount of received updates was exactly the same for all clients. 5.2 BANDWIDTH To compare the bandwidth consumption of the architectures, we compute the length, in bits, of all these packets. The graphs below (figure 5) show the results related to the clients sent or received data for the measurement duration. The darker line represent the messages sent by the clients. The lighter, the received ones. 35Kbits 30
35 Kbits 30
250
25
25
200
20
20
150
15
15
10
10
5
5
100 50
0
0
b)
seg.
0 10 20 30 40 50 60 70 80 90 100 110 120
120
110
90
100
80
70
60
50
40
30
20
0
seg.
10
seg.
120
110
90
100
80
70
60
50
40
30
20
0
a)
10
0
Kbits
c)
Figure 5: a) AC architecture, b) CB architecture, c) EV architecture
We note that the first two architectures got similar curves, with a small reduction on the total amount of sent messages by the clients to the server on CB architecture. The increase of the server to clients sent messages is because of the GIOP protocol [2] used by CORBA. The EV graph shows us that this architecture generated much more traffic than the other ones. The reason is the very large amount of GIOP messages. The instants where there is no traffic shown are the moments where the prey was caught by a hunter.
6
CONCLUSION AND FUTURE WORKS
In this work we have developed a multi-user distributed action game on CORBA platform to measure the impact of three different architecture, in terms of generated network traffic, interface consistency and user presentation quality. The global performance of the game within the three versions was satisfactory and the low bandwidth use of the AC and CB architectures has shown that it is possible to play the game through the Internet, for example, even with a dial-up connection, since the maximum transmission rate required by the game is approximately 33Kbps. The other architecture, EV, had a higher bandwidth use, but it didn’t affect the user presentation quality. We are continuously working on the design of architectures to find the most acceptable. We’re also working on adding some functionality like fault tolerance, platform interoperability, and the Internet adapt.
The main objective is to design a general and flexible architecture based on distributed objects to the implementation of distributed action applications with low network effort.
7
REFERENCES [1] Coulouris, G., Dollimore J. and Kindberg, T. Distributed Systems Concepts and Design. Addison Wesley, 1994 [2] Orfali, R. and Harkey, D. Client/Server Programming with Java and CORBA. Second Edition [3] Tiraks, A. et al- Distributed Multimedia Architectures – State-of-the-Art Report http://viswiz.gmd.de/DVP/Public/deliv/deliv.222/act222.htm [4] Russel, Stuart J., Norvig, Peter, Artificial Intelligence: A Modern Approach, New Jersey, Prentice-Hall Inc., 1995. [5] Figueira, C. – JEOPS – The Java Embedded Object Production System, UFPE, 1999 http://www.di.ufpe.br/~csff/jeops [6] Visibroker – Programmer’s Guide, Inprise Corporation, Inc., 1999 http://www.borland.com/techpubs/books/vbj/vbj40 [7] TCPDUMP – Lawrence Berkeley National Laboratory, Network Research Group ftp://ftp.ee.lbl.gov/tcpdump.tar.Z [8] Ben-Natan Ron, CORBA on the Web, McGraw-Hill, United States, 1998. [9] Bernt Habermeier – Internet Based Client/Server Network Traffic Reduction. http://www.boltaction.com [10] Jain, R. – The Art of Computer Systems Performance Analysis: Techniques for Esperimental Design, Measurement, Simulation and Modeling, John wiley & Sons, Inc. 1991 [11] Lamothe, A. – Tricks of the Windows Game Programming Gurus – Fundamentals of 2D and 3D Game Programming, Sams, United States, 1999. [12] Siqueira, F. – A Framework for Distributed Multimedia Applications based on CORBA and Integrated Services Networks. http://www.cs.tcd.ie/Frank.Siqueira/PhD-Project/index.html [13] Andrade, R. C., Cavalcanti, D. A. T., Madeira, C. A. G., Araújo, A. C. M., Macedo, H. T., Ferraz, C. A. G. Avaliação de Arquiteturas para Jogos de Ação Distribuídos Desenvolvidos em Corba. Submited to SBRC 2000
