What are you in the mood for today?

Sunday, 2 December 2007

This
project was based over seven weeks and was aimed at developing a
network based multiplayer clone of the arcade game Asteroids. This
project was taken on an individual basis to allow each person to get
a feel for programming on a distributed application.

For
my version of the game I have decided to develop a completely peer to
peer version where each player maintains their own game environment
which is updated based on other players messages. This allows each
player’s game to be connected but also resilient to node failures.

Protocols:

UDP Multicast

UDP
Multicasts were used for the basic communication to all nodes
participating in the game. The advantage of this is simple
information can be received by all nodes simultaneously

TCP Socket

TCP
Sockets were used for transferring critical information between
nodes. TCP allowed for transferring of objects which allowed for
several complex values to be processed and then returned.

It
is also connection orientated which makes it more reliable than UDP
which again is important when dealing with crucial information.

Architecture:

Code:

JAVA :

Java
is an object orientated programming language developed by Sun Micro
Systems. I decided to use JAVA for this project because I was
familiar with it from my under-grad course and I knew the native
networking ability would prove invaluable,

Processing
was initiated by Ben Fry & Casey Reas. It is developed by a small
team of volunteers. It is a library built on top of the Java 2D and
3D libraries to simplify the programming of graphics in Java.

Scene graph:

The internal
structure of the programme is constructed as a scene graph. This
allows objects to call methods on their parents as well as the
objects they create. An advantage to this is that objects can alter
the system wide behavior in real time. A disadvantage is that it can
lead to a higher coupling between objects.

Network:

Starting/joining:

First player A starts the game and broadcasts a hello
message.

No one else is playing so the hello goes unanswered.

Player B starts and sends out their hello message.

A receives B’s hello message.

A adds B’s IP address to its IP list.

A responds by sending B its space ship in a serialized
object.

B receives the ship and checks its IP list which will be
empty.

B determines it is not the first player.

B adds A’s IP to its list.

B sends A its ship and requests A’s asteroid information.

A receives B’s ship and forwards the Asteroid information.

Ship movements
& shoot:

Each time a player maneuvers its
ship a multicast is sent out indicating to all others to display
their ship.

Each time a player fires a shot
from their ship one multicast is sent out to indicate the origin and
direction of the shot. Each other player who receives this will
automatically place the bullet in the game and progress the bullets
path in time with the game.

Ships
colliding:

Hit tests are
performed against all other ships and asteroids in relation to your
ship to see if a collision has occurred.

Shooting an
asteroid:

Each player is
responsible for testing if their shots have hit any other players or
asteroids in the game. If contact is made with a ship the player for
whom the bullets belong to will notify the player they have hit to
inform them of this. If an asteroid is hit, the local player will
recalculate the new asteroids locations and will push an update out
to all players in the game to inform them of this.

Removing the
last asteroid & refilling the screen.

If a player shoots
the last asteroid they will be in charge of repopulating all the
asteroids and pushing the update. This ensures that people who
destroy asteroids cannot leave before they have added the value back
to the game.

Disconnected
players / Hearth beat

When every player
starts the application a thread is created which sends a multicast
every half second to indicate the player is still present within the
game. Every node listens for this message and keeps a log of all of
them which are received. Each node will also check to see if one has
been received from every IP in its IP list to determine if they are
still in the game. i.e. each node should receive 3 heart beats
between each check even though only one is needed to prove they are
still playing. This is done because of the unreliability of the UDP
multicasts. If the check fails that player’s ship is destroyed and
their IP is removed from the list.

The scene graph
meant that there was high coupling which at the end I rewrote some
classes to minimize this in order to allow for reuse in the future.

Synchronizing
Asteroids

I found when
transferring the asteroid information it was very easy for them to
become unsynchronized. I may put this down to using two very
differently specced computers over a wireless but a solution to
managing this was to enforce that any change in an asteroid would
synchronize all of them

Other
features:

3D

I built the game
graphics in 3D because I was somewhat familiar with the techniques
and I thought it would create an interesting look for the game.

Sound

Sound was added
using the Java sound library linked to the game object insuring it
could be called when needed.

XML

I created XML
files describing how the ships in the game are to be displayed. I
felt there were several advantages to this: People could develop
their own ships, I may use this file type in future games. People
could change the ships without touching the code.

Network Graph

I added a network
graph in the top right corner which displays the network traffic in
and out of the game (Red is for outgoing traffic and Yellow is for
incoming traffic)

Conclusion:

This was really a
fun project to work on and something I feel which helped was thinking
about the message passing and the ordering of messages in different
situations help the project to move more smoothly.