The project consisted in developing a 2D multiplayer game (LAN/W-LAN) using Java. The main goal wasn't the development of a full game but to discover and implement the architecture which is used to develop
this kind of game.
The main components are the network communication inside a client/server architecture, the content replication between server and all connected clients, and the connection of this model with a human-machine interface.
StarBattle is a team multiplayer game which can be joined by up to 10 players (5 vs. 5) within a space war. Each player controls a spaceship which he can move on a wide squared game area.
Each team owns a base which the opponent team has to destroy to win the game, aside with several destructible defensive towers. Also, a flow of small spaceships, controlled by a small artificial intelligence, move along several paths from a base to the other, attacking ennemy players and buildings on their way.
All ships and buildings are equiped with weapons, shield and armor. Shield is damaged first and regenerates while not attacked, and armor is damaged when shield is exhausted. When a ship or building's armor amount reaches 0, it is destroyed. When a player destroyed, he has to wait for a defined time to respawn in his base, depending on how many times he has been killed.
All these strategical factors are to be considered in order to defeat the opponent team.
To develop this game, we used Java 6 and the Slick library for the graphical display, which allows to save a lot of time for this part of development (which was not our main goal), and ProActive library for the network part.
The graphical layer's role is to display on the player's screen a representation of the "logical world" replicated between the server and the different clients. 2D games imply the following specifications :
We chose the graphical library Slick which is a full high level library (dealing with images, animations, sounds, input/output devices) encompassing LWJGL and requiering any manipulation of OpenGL (low level).
Our communication protocol is based on message transfer between client and server. From client to server, messages are to notify the server from the user actions (mainly device inputs), and the server notifies all clients of the world modifications (moves, lives, deaths, attacks, etc.)
To carry our messages, we used ProActive, an asynchronous RMI-based library. This has the advantage of avoiding our applications to be blocked while performing a remote call each time a message or an update is carried. It also offers some nice possibilities, e.g. performing a remote call to a group of clients.
A multiplayer game implies that all users see the game in the same state at the same time, or something as close as possible. To achieve this, developers have to consider the latency, or ping, inherent in every client/server communication. There is no guarantee that all clients will have a good connexion or the same latency to send and receive messages.
There are many approaches to deal with that issue. The one we chose consists in considering that the server is always right and owns the real version of the current game. Each client has to adapt his display considering his own latency, by computing and refreshing his own version of the game. Between two updates, each client has to proceed to an interpolation of the movement of each elements on the scene. When he receives a position and trajectory update, he may have to correct the position of an element which has kept moving while an update was coming from the server. Then, we used the "Dead reckoning" solution, which consists in calculating a new approximated trajectory the element has to follow to join as soon as possible his real position without having to move it instantly (which would work but would be weird and uncomfortable for the user).