Colours Multiplayer Board Game

Background

The task is to implement a client-server Java application for a multi-player board game. Each player will be represented as a client program, and the server is a program coordinating the game. The game is as follows.

• The game is played by two to five players. Each player is assigned a 'colour' (can be a shape or letter or anything else that would allow identification of the player; in the examples below, coloured letters 'R', 'G' and 'B' will be used). We will say that players place stones on the board, like in the Go game.
• The board has 6 rows and 10 columns. Initially, the server places one stone of each 'colour' on the board, randomly picking the locations.
• The players make their 'moves' in turn. The order of the players is the same as the order in which the clients connect to the game server. In the demos below, we will assume that the first player to connect was 'R', followed by 'G', followed by 'B'.
• In each move, a player places one stone of their 'colour' on the board. They can place a stone only on an empty cell, and only on a cell adjacent to one of their stones. Below is an example of the first few steps of the game.
• Each player is given three influence cards at the beginning of the game. A player can use any of their influence cards when making a move. Once a card is used, it is discarded (i.e. each influence card can be used at most once by each player). An influence card makes an exception from the previous rule:
  • Double-move card: allows the player to place two stones in one move. (In terms of the adjacency rule, this move is interpreted as two consecutive moves.)
  • Replacement card: allows the player to place a stone even if the cell is not empty. The adjacency rule still applies.
  • Freedom card: allows the player to place a stone on any empty cell, even if it is not adjacent to their existing stones.
• A player is called 'blocked' if they cannot make a move, even if using one of the influence cards available to them. If a player is blocked, they skip their turn. In this example, the 'G' player is blocked (assuming they don't have either replacement or freedom influence cards)
• The game ends when all the players are blocked.
• The winner of the game is the player with the highest number of stones on the board. If there are several such players, the one of them who joined the game last, wins. The demo below shows the last few moves of the game. At the end, the scores are as follows: 'R': 21, 'G': 18, 'B': 21. Of the two players with the highest scores, the winner is 'B' because they joined the game later than 'R'.

Part A: Game with User Interface

Implement the game as a client-server application in Java.

• The server should be implemented either using sockets or as a Jersey web service.
• The client can be implemented either using Putty or using Java (GUI or text interface) or as an HTML/JavaScript web page.
• The server has to ensure that the players adhere to the rules (e.g., a player cannot place a stone on an occupied cell, unless the replacement influence card is used).
• Try to use the templates, classes, etc. provided with the assignment.

Also write some unit tests that check the correct implementation of the basic game logic on the server side.

Part B: Automated Player ("Bot") (Challenge)

Implement an automated ('bot') player which can replace human players in the game. The bot should be implemented as a client which communicates with the game server; the server will not know if the connected client is a bot or a human player. It should be possible for the game to be played by the bots only, or the human players only, or by a mix of bots and human players.

To make it possible to watch the game between the bots, implement two features:

• Each player should take at least one second per move (can be imposed by the server).
• Even if only the bots are playing, there needs to be a way to watch the game. When watching the game, the user should be able to understand not only what moves are made but also to see the remaining influence cards of each player.

Part C: Report

Write a PDF report that includes:

• Precise instructions on how to run start the server and the clients from a command line / web browser. Running the program should not involve IDE (Eclipse, IntelliJ, etc).
• A description of your program architecture including the rationale behind it. If you have used web services, describe the API. If you have used sockets, describe the protocol. Give a summary of unit tests, if any. Explain how your program design ensures correct behaviour in the face of concurrency.
• A description of the user interface design and any steps you have taken to make your program more user-friendly.
• A description of the logic of the bot player.
• A review of your project how did it go? Which parts were easy, which parts were challenging? Are there any features you are particularly proud of? Are there any unfinished parts or problems with the quality of the program? How was your project management? Is there anything you would do differently next time?