INFT 3030 Concurrent Programming - Assignment: Multi-player game server
School of Information Technology and Mathematical Sciences INFT 3030 Concurrent Programming
Concurrent Programming Assignment SP2 2019
Introduction
This document defines the requirements for the assignment in Concurrent Programming. The assignment is intended to give you experience in modelling a concurrent requirement and writing a concurrent program in Java to implement it. The application is a multi-player game server (MPGS).
A MPGS is software that runs on a computer connected to Internet. It enables and handles all communication between players of games running on Internet connected devices so that they can participate in a shared game. A turn based game is often played using a multiplayer game server. In these games each player (using client software) takes a turn in giving input to the game server.
Google (PlayServices) and Apple (GameCenter) provide a MPGS for their mobile platforms. There are also independent companies providing these services; examples of which are Photon (https://www.exitgames.com/en/OnPremise) and Smartfox (http://www.smartfoxserver.com/products).
MPGS can quickly become very complex and contain many functions that we won’t be implementing in this assignment. The scope of the MPGS to be implemented by you and your team in for the Concurrency Programming assignment are the ability for players to connect and to play a game together, noting the following: Only players who are registered are allowed to connect to and play on the MPGS. It is acceptable to have a list of registered players in an external database, i.e. you can assume that the registration is taken care of by a separate piece of software and the list of registered players is provided by that software. Typically, when a player connects to the MPGS, they are often placed into a “lobby”. Normally a player in the lobby would then choose a game to join or start their own and hope others will join. However in this assignment, you are only required to have one multiplayer game to join and everyone who is logged in will have to play in that one game. The game to be hosted by the MPGS will be called multiplayer snakes
Multiplayer snakes
Single player versions of snakes can be found in many places on the internet, e.g. http://playsnake.org and http://codeincomplete.com/projects/snakes/. The rules vary between different variants: you can get points for eating fruit, as well as simply surviving as long as you can it can be OK to cross the edge of the screen, or this can end your game game time can be limited so you get a fixed time to score, or the game can go on until you cross the edge of the screen or collide with yourself or another player.
A downloadable multiplayer version of snakes for windows is here: http://sandbox.yoyogames.com/games/172375/download. In this case there are no food items you just try to block other snakes and need to be the last snake left with somewhere to move to win. Another example of the idea can be viewed at https://www.youtube.com/watch?v=hRy_qQLdptA although you may not understand the German commentary! For the purposes of this assignment, you are free to choose your own rules for the actual snakes game. The main focus for this assessment is the way your MPGS supports multiple concurrent players.
Server design
After they have connected and joined a game, players send to the game server their moves. These moves are very simple: Up, Down, Left, Right or No Move. A No Move could mean either keep going in the same direction as the last move or stop and wait. The game server takes all the moves from all the players and updates its copy of the game board. If you chose to have fruit the snakes eat to get points, the server will need to detect if fruit has been eaten and updates player scores. The server then broadcasts the game board (with all the other players shown and any fruit left or added) to each player so they can make the next move. In a fully networked implementation of this game each player will have to display on their screen the current state of play and then transmit moves to the server (using TCP/IP or UDP sockets) over the internet. Given this can be a time intensive exercise, in this assignment, we are going to limit the implementation to save on programming time and leave time to concentrate on the concurrent aspects of the server and players. For the MPGS you will implement, no networking is required. In keeping with the rest of this course we will restrict the game server and players to be threads all on the same Java process (JVM). This means that you will not have to write TCP/IP or UDP socket code, rather you will need to manage the communication between players and the server using Java constructs. This also means that initially at least you can get the server to draw the game state on a single screen where all the players can see it rather than sending a copy down to each player for them to draw on their own screen.
Modelling
In addition to writing concurrent Java code for the game server and clients (players), you will need to construct a model of their game server and players using the LTSA tool. The modelling will need to accurately capture the concurrent behaviour of your proposed server and show that it is both safe, i.e. it is not likely to freeze. And that it is in fact using multiple threads to perform its functions in a way than can be scaled up to many different players.
Testing
You will be required to demonstrate testing to show that the game can be played by 4 real players and up to 100 simulated players. Simulated players just make random moves on the board. It would be expected that you apply testing concepts that have been discussed in the lectures (JUnit assertions and mock objects).
Assessment summary
For internal students this will be a group project with teams of 4. External students will work alone on the assignment and hence will not need to provide an as complete a solution as internal students. The assessment scoring is divided into two stages.
The following subsections provide details that are focused on internal students. Clarifications for external students are provided at the end of each section.
Checkpoint 1
This body of work is to be presented in the week 6 lab slot. The purpose of the check point provides an opportunity for the design of the server to be checked before implementation commences. At this checkpoint the group should have finalised the concurrency design of the server and player roles and created a Java class design document. The group should also have a draft LTSA model of their concurrency design. All this is to be gathered in a design report of approximately 3000 words (or equivalent with diagrams). The report needs to allocate Java classes to group members for the first sprint to implementation. External students will do this as individuals. The deliverable is the same, but they do not need to prepare such a large document (1000 words).
Checkpoint 2
This body of work is to be presented in the week 8 lab slot. The purpose of this checkpoint is to evaluate some early working code as planned for the first sprint in checkpoint 1. There should be an emphasis on a thread-safe monitor controlled buffer between clients and the server and some initial implementation of the threaded server code especially the thread safe game state code. The LTSA model should be nearing completion. Some attention should be focused on testing and how this will be performed. Finally plans for the final implementation should be finalized and every team member should have some coding allocated to complete the assignment. An updated report will be required for this checkpoint and working code is required. External students do not need as large an updated report (1000 words) and the scope of code implementation will be reduced.
Final Submission and Presentation
The final submission will provide working code which allows four players to engage in the game and code to allow simulated play for up to 100 players. There will also be a completed LTSA model of the concurrent behaviour the players and the game server. The model should demonstrate that the game server is capable of concurrent operation and that it has no potential freezes (deadlocks). A report will describe the structure of the code for both the model and the actual implementation. The report should be approximately 5000 words or equivalent diagrams. The group will present the server working with 4 real players and 100 simulated players. The group mark will be allocated for successful integration of group member’s code and model and the demonstration/presentation. The individual marks will be allocated to the code each student has written and their individual contribution to contribution to the model and the report. External students need only demonstrate one real player, and scaling up to 4 simulated players. External students need only provide a report of 1000 words. External students can demonstrate via a screen capture or video.
Technical Specifications
Stage 1
The first stage of the project should be to allow players to login. Each player will be modelled and coded as a concurrent thread. The server design should be able to handle concurrent login requests from different players.
Logins must be thread-safe on the server. It is not necessary to support registration. Registering players can be handled by manually loading their usernames and passwords into a suitable database. A suggested package is MapDB (as presented in Appendix 1) which is a good choice for a thread-safe embedded database. It is a requirement for the concurrent login code that a thread-safe standard Java collection is NOT to be used to pass messages between the player logging in and the server. It is also a requirement that monitors be used to manage access to this collection.
Stage 2
The second stage of the project is to implement the game playing part of the server. Once the server starts it should be ready to accept logged in players playing the game. It is a requirement to use thread safe collections for the communication channels between players and the server for game playing and for the storage of the game state. It is a requirement to use a thread pool for game player interactions based on the java.util.concurrent.executor model. The actual game playing will adopt the pure client server model. The server's main loop would be a concurrent version of this pseudo code:
while not done
for each player in world
if input exists
get player command
execute player command
tell player of the results
simulate the world
broadcast to all playersThe client's main loop would be like this:
while not done
if player has typed any text
send typed text to server
if output from server exists
print outputIn the case of the assignment Java threaded version with no networking the server could take care of updating the screen since all players can see the single screen. There is a simple snake single player code example at: https://code.google.com/p/java-snake/source/browse/trunk/javasnake/src/snake/Main.java. Code from here tested on IntelliJ 14 community edition can be found in Appendix 2
