Report On

Design and Implementation Of

Distributed Virtual Hockey

 

Implemented Features

 

·         Client-Server Architecture implementation

·         .NET  Remoting Technology for communication among distributed parts

·         Support for Two and Four players

·         Environment synchronization among players

·         Concurrency control mechanism through Monitors

·         Different ‘Pitch Shapes’ for Two and Four players

·         Synchronous score updating in all players (clients)

 

Outline of Report

 

1.   Abstract

 

2.   Distributed Architecture - Interaction and Coordination among players

 

3.   Concurrency Control Mechanism

 

4.   Justification of Distributed Architecture and Distributed Technology used

 

5.   Conclusions

 

6.   User Guide

 

7.   References

 

1.   Abstract

This report mainly addresses the techniques used in the implementation of a Distributed Virtual Hockey game. The emphasis is on the choice and implementation procedure of Distributed Architecture and Distributed Technology, which are, Client/Server Architecture and .NET Remoting Technology respectively. This report also describes the concurrency control mechanisms used and the method of coordination and interaction between multiple players.

 

2.   Distributed Architecture – Interaction and Coordination among players

The distributed architecture that has been used to implement this multi-player game is the Client-Server Architecture. This simple architecture indicates that on a network, a computer or a process can act as a server or as a client (webopedia). A client interacts with a server process or computer and in turn the server can interact with other processes or computers.

 

 

 

 

 

Implementation in Game

The procedure that has been used to implement this Client-Server Architecture in the Distributed Virtual Hockey game is described below.

 

The implementation of the whole has been depicted in the figure below. The description here under uses this figure as a reference.

 

Fig. Procedure of Implementation of Client Server Architecture for Distributed Virtual Hockey Game.

 

 

Game Physics Simulation as a Server Process

The server is a process or a computer which runs the physics simulation for game and implements different Collision Detection and Collision Response algorithms. The ‘server code’ part stores the state variables that are to be transferred over the network. The state variables are continuously updated by the simulation routine, which are then made available to the client processes or machines.

 

Client Process

The Client is a process or a single machine that passes user actions (i.e. Key Hits and Flipper Force Updates) to the server process and in turn reads the state variables in the server code that are updated by the server’s simulation routines and renders them. The operations that are performed by client in sequence are as here:

·         Detect User Actions

·         Pass them on to server to act

·         Read the state of game from server

·         Render the objects as per the state variables.

 

 

3.   Concurrency Control Mechanism

Concurrency control is an important feature that has to be considered while designing a distributed application. In this game of Distributed Virtual Hockey the state variables are being updated by the server and at the same time they are being read by client for current state. So situation might occur where a variable is being tried to read by a client while it is being updated by the simulation routines of server. An inconsistency occurs which should be avoided in order to provide coherent and consistent state of game to all clients. This state is termed as an Anomaly. (Pares, 2002)

 

Monitors are one of the concurrency control mechanisms that can be used to be safe from such operations. Monitors are briefly described below.

 

Monitor is a concurrency control mechanism that makes a block of code to be accessed in a sequential way. And this process of control is called as blocking and signaling (Pares, 2002). For example, a read operation on a variable should not be done while an update operation is being performed on that variable. Monitors ensure this. They allow the code to be executed as a transaction.

 

A monitor accomplishes this by locking the resources while it is being used. It sits on a server component and listens for calls from clients and executes these calls as a transaction, that is, one after the other there by avoiding the state of anomaly (Pares, 2002). Monitors guarantee the indivisible execution of a critical section of code and thereby a consistent state of data is maintained (Foglietta, Bonuccelli, 1997).

 

An example code for a monitor in Managed C++ that sits on a server process or machine and continuously listens to the calls from client processes or machines is given below.

            Object* LockObj = new Object();

            Monitor::Enter(LockObj);

            Monitor::Wait(LockObj);

And Object class is the ultimate base class of all classes in the .NET framework. These objects are safe to use for multithreaded operations. The Monitor class provides a mechanism that synchronizes access to a block of code, generally called as Critical Section. The Enter method acquires and exclusive lock over the object that the monitor receives through Remote Method Invocation (RMI). The Wait method releases the lock on the current object and blocks the current thread to acquire a lock on it when another object or method with object as parameter is called (MSDN, 01-02).

 

With these monitor structures; the concurrency over the critical section of code as described above is achieved thereby maintaining a consistent form of data.

 

4.   Justification of Distributed Architecture and Distributed Technology used

The Client-Server Architecture and .NET Remoting Technology are used in this distributed game implementation for following reasons.

 

 

 

Distributed Architecture – Client/Server Architecture

The following advantages offered by Client/Server Architecture over other distributed architectures are considered to justify the choice of Client/Server Architecture.

 

·         Client/Server Architecture is best suited for Local Area Networks.

·         Only a single copy of state variables is enough to provide a consistent state of process.

·         A powerful machine can be used for server process and client processes can be run on less powerful Network Terminals.

 

Distributed Technology - .NET Remoting (Remote Method Invocation)

The following advantages offered by .NET Remoting Technology over other distributed technologies are considered to justify the choice of .NET Remoting Technology – Remote Method Invocation.

 

·         Packing and Unpacking of data into buffers is not necessary using .NET remoting

·         Calling a method from remote object is as simple as calling a local method

·         Provides an abstract from of interaction between distributed components rather than a low level jargon

·         Components can be designed in Object Oriented style rather than procedural style

·         It provides a consistent and standard form of data representation across various platforms

·         Components can be distributed over various hardware and software platforms

 

Because of the above advantages offered by the Client/Server Architecture and .NET Remoting Technology, they have been used in the design and implementation of Distributed Virtual Hockey Game.

 

5.   Conclusions

Therefore, a Distributed Virtual Hockey game has been implemented using Client/Server Architecture and .NET Remoting Technology. Synchronization among players has been provided which is depicted in the figure 1. A Server process will be executing the whole game physics simulation and collision detection/response algorithms and a Client process reads the state variables maintained by server and renders the objects.

 

Also, justifications to the choice of client/server architecture and .NET remoting are provided which make them better techniques for implementing this game. This description is made on a two player game but the same applies to all other clients (players) and the client processes or machines shown in figure 1 extend to four with extra number of method invocations and data transfer.

 

6.   User Guide

Various controls for Distributed Virtual Hockey game are as below.

Start Playing:                          Key B (Only on Server)

Hit with Left Flipper:             LEFT MOUSE BUTTON, Key 3 (Only on Client)

Hit with Right Flipper:           RIGHT MOUSE BUTTON, Key 4 (Only on Client)

Toggle Puck/Normal view:     Key V (Both on Client and Server)

Reset Game:                            Key R (Only on Server)

Wire-Frame Model:                 Key N (Both on Client and Server)

Pitch:                                       RIGHT MOUSE BUTTON + MOUSE MOTION

                                                (Both on Client and Server)

Yaw:                                       LEFT MOUSE BUTTON + MOUSE MOTION

                                                (Both on Client and Server)

Move Front:                            Key A (Both on Client and Server)

Move Back:                             Key S (Both on Client and Server)

Move Up:                                Key Z (Both on Client and Server)

Move Down:                           Key X (Both on Client and Server)

Increase Flipper Force:            Keys 5, 6 for flippers Left and Right, respectively. (Only on Client)

Decrease Flipper Force:          Keys 7, 8 for flippers Left and Right, respectively. (Only on Client)

Lights On/Off                         Keys 1, 2, 9, 0 for red, green, blue and yellow lights respectively (Both on Client and Server)

Invert Colors:                          Key C (Both on Client and Server)

Toggle Full screen/Window:   Key F (Both on Client and Server)

Exit:                                        ESC (Both on Client and Server)

 

7. References

 

Foglietta, Bonuccelli, 1997, Assured Selection – A Relaxed Concurrency Control Mechanism [online], Linkopings Universitet, Sweden.

Available:http://citeseer.ist.psu.edu/cache/papers/cs/15840/http:zSzzSzvir.liu.sezSz~rtslabzSzpublicationszSz1999zSzx98cinfo-xjobb.pdf/assured-selection-a-relaxed.pdf/ [Accessed 06 May 2004].

 

MSDN, .NET Framework Class Library, Documentation Version 1.1.0, Microsoft Corporation.

 

Pares G, 2002, Concurrency Control in ADO.NET using Threads and Monitors [online], C# Corner. Available: http://www.c-sharpcorner.com/Code/2002/Dec/AdoNetConcurre

ncy.asp [Accessed 06 May, 2004].

 

Webopedia, 2004, Client/Server Architecture [online]. Jupitermedia Corporation.

Available: http://www.webopedia.com/TERM/C/client_server_architecture.html [Accessed 06 May, 2004].