6 — Games!

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

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

• for the Programming Task, place

  • player.PP in the Player/ directory

  • referee.PP in a new Admin/ directory in Trains/

• for the Design Task, place

  • manager-player-interface.md in Planning/

• for the Testing Task, place xstrategy and Tests/ in a repo-level directory named 6

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

• a player component that performs the mechanical tasks and otherwise relies on strategy.PP from 5 — The Strategy to make decisions.

  The component must include a construction functionality that creates a player (representation, speak object, closure, etc.) from a file path to a strategy class, module, or file. Hint The strategy to be used does not exist yet, and this functionality must work without any change for these new strategies at distinct file paths that you will create in the future.

  Here are things it could do: (1) build a strategy chain; (2) spawn a thread that explores the tree of scenarios for the next time the referee grants it a turn; (3) spawn many threads, each exploring different strategies and compare their results. The point is that a properly designed software system separates play mechanism from strategy.

  Right now, this player component is extremely simple. It mostly passes data to its strategy and forwards the results to the referee.

• a referee component, which can run a complete Trains game for a given game-map and a bunch of players (between 2 and 8 players, inclusive).

  The referee may assume that the players are arranged in descending order of player age. Your design decides how the referee is handed this sequence. Its task is to run the game with the given players and deliver the outcome of the game: a ranking of the surviving players plus those players that cheated or malfunctioned.

  For testing purposes, the referee should be optionally abstracted over two pieces of functionality: (1) in what order to select (enough) destinations from the map for players to pick from; (2) a sequence of cards to hand to players. Once a player picks two destinations, the referee removes them from the sequence of destinations and leaves the sequence alone otherwise. The defaults should be a method for randomly picking destinations and another one for randomly shuffling a sequence of 250 colored cards.

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.

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