Astro-MuitiX

Overview of Project:

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:

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:

1. First player A starts the game and broadcasts a hello message.
   
2. No one else is playing so the hello goes unanswered.
   
3. Player B starts and sends out their hello message.
   
4. A receives B’s hello message.
   
5. A adds B’s IP address to its IP list.
   
6. A responds by sending B its space ship in a serialized object.
   
7. B receives the ship and checks its IP list which will be empty.
   
8. B determines it is not the first player.
   
9. B adds A’s IP to its list.
   
10. B sends A its ship and requests A’s asteroid information.
    
11. A receives B’s ship and forwards the Asteroid information.
    

Ship movements & shoot:

1. Each time a player maneuvers its ship a multicast is sent out indicating to all others to display their ship.
2. 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.

Problems:

Coding problems

I found when I was programming, the difference between passby value and passby reference would catch me out sometimes.

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.

GITHUB