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],
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].