Assignment 7 – Backgammon: Playing a Game

Due Friday 5/14 11:59pm for the code deliverables

For this assignment, your task is to build an administrator that can manage a game of Backgammon between any two players. In particular, the administrator must be designed in a way that (once some startup phase has completed) it is completely agnostic to whether the players are remote players or are specific players you have implemented that run directly on your machine.

That is, you must have multiple implementations of the player interface (one of which knows how to play via a network connection and others that do not) and the administrator must not know or care which kind of player it is given to play the game.

1 Design, Build and Test

As the administrator starts up, it should wait for a connection from a remote player and then it should manage a game between the remote player and a specific local player that is specified as part of the administrator’s startup. No matter the strategy it uses, the local player’s name must be "Lou" (the CI uses this name to determine if a test case passes or fails).

After the game is complete your program must close the network connection and then it should write the name of the winning player to STDOUT as a JSON string.

You may assume that if a local player cheats it is a bug to be fixed, not a situation to handle gracefully. That is, the administrator can just ignore that possibility.

You may not make that assumption for the remote player, however. If the remote player cheats in some way, the game must finish by replacing the remote player with a local one whose name is "Malnati". Its strategy is up to you, but it must play legally, according to the rules of Backgammon. (Using the random player from assignment 5 is a good choice.)

Here are the precise inputs and outputs sequence (delivered on stdin and stdout respectively) of the administrator. It should wait for admin-config. Once it has that, it should dynamically load a player that uses the given strategy: the random strategy from assignment 5 for "Rando" or the other strategy you implemented for that assignment for "Bopsy" (if you used a different strategy for that player that’s fine, still load it when you see the strategy name "Bopsy"). Although we will not test this in CI, the idea is that if a new strategy name shows up, someone can merely deposit a new file in some specific directory and start a game against a player that uses the new strategy.

Once the administrator has loaded the player, it should start a TCP listener on the specified port and, once the listener has been created and network connections are being accepted, print admin-networking-started and await a connection from the remote player. Once the remote player connects, your administrator should manage the game. When the game is over, the program should produce admin-game-over on stdout, based on what the administrator decides about the games’ result.

The remote player should play according to the protocol in assignment 6.

To achieve the above you may have to adjust components you designed in previous assignments. That said, you may not modify the communication message format and protocol for player components from assignment 6. As before, note any changes you make to existing parts of your code base so that we can discuss them during code walks.

To test your administrator you should play a large number of games; use your random player to try to exercise different behavior in your administrator. In contrast to the unit and integration testing of previous assignments, this assignment introduces the idea of system testing. That is testing the game system as an integrated complete composition of different components.

Code Deliverables: In your team’s GitHub dev repository, create a directory "Deliverables/7/7.1/" and deposit there a Makefile that creates run, as usual. The run executable should start the administrator. We will use it to play a number of games with our own remote players. You can assume that our players do not disconnect randomly and always deliver valid JSON. They may deliver illegal moves or even JSON that does not correspond to a move, however.

There are no test deliverables for this assignment. Note that the CI will run each of our tests multiple times (you’ll see that there are multiple copies of the same test case in different files). This is because the correct outcome of a test depends on the players and so the CI runs each one multiple times to try to ensure that both possible outcomes appear.

You will receive up to sixty points for your administrator depending on how many games we try it handles appropriately.