8.3.0.5

6 — Games!

Due Wednesday, 03 November 2021, 11:59:59pm

Delivery Place the product of this week’s milestone into your repo as follows:

Programming Task Co-design implementations for the following components, which interact according to Logical Interactions:

For this milestone, you will need to think about failures within plug-in components such as house players, external players, observers, etc. Such failures should not bring down the system. This assignment thus demands the identification of possibly abnormal interactions between referee and a player. An interaction is abnormal if the player cheats (a logical problem) or causes other undesirable run-time effects. Which of those your implementation has to deal with depends entirely on design choices, but exceptions and overly-long response time are guaranteed to be problems. When a referee notices such misbehavior, the corresponding player is eliminated without ado.

When the referee removes a cheating/misbehaving player from its state, it makes the player's occupied connections available for future use. Its rails and cards are discarded.

In the purpose statement for your referee component, explicitly state what kind of abnormal interactions that referee takes care of now and what kind are left to the project phase that adds in remote communication.

Design Task The next step is to design the tournament manager component. It interacts with the 1000s of players that sign up for a tournament, How they sign up at the communication layer is not the manager’s problem, because this is definitely going to involve some remote interactions. the referee, and possibly tournament observers.

Expand the API for the player component so that the manager may also interact with it. Supplement the protocol for referee-player interactions to include manager-player interactions. Finally write down a specification of the manager, i.e., what it receives, what it has to compute during a single tournament, and what it may return.

Two pages should suffice. Less is more.

Keep in mind our Trains.Com, a Plan when you work on designs.

Testing Task Create a test harness for the Hold-10 strategy and name it xstrategy The harness consumes its JSON input from STDIN and produces its results to STDOUT. Create five tests and place them in Tests.

Constraint No test file may exceed the size limit of 20Kb.

The input files consist of two JSON objects: a Map and the PlayerState. The former represents the game map, the latter the state that the referee sends to a player when it is its turn. The given PlayerState must be consistent with the given Map.

Its expected output is an Action.

    An Action is one of:

      - the string "more cards"

      - an Acquired.

As always, the tests are well-formed and valid JSON.