6 — Games!

Due Thursday, 05 November 2020, 11:59:59pm

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

Since Python’s naming system is badly designed and its convention interfere with the specified name, Pythonistas may substitute _ for - in these file names.

Programming Task Co-design implementations for the following components:

You are free to modify your designs in Planning/ according to any insights you may have. But, running a game does not involve any remote interactions. We are still working on the logic of the software.

• a player component that realizes the logic of the existing interface in Common/ and performs the mechanical tasks of initial moves and taking turns;

  The player.PP component relies on strategy.PP from 5 — The Strategy to make decisions. We may implement alternative strategies later in the semester.

• a referee component, which can run a complete Fish game for a sequence of players. The referee may assume that the sequence is arranged in ascending order of player age; your design decides how the referee is handed this sequence.

  The referee’s task is to run the game with the given players and deliver the outcome of the game.

  The implementation of the referee component demands identifying and dealing with possibly abnormal interactions between referee and a player. An interaction is abnormal if it cheats (a logical problem) or causes other undesirable run-time effects (which ones may happen entirely depends on design choices). When a referee notices such misbehavior. the corresponding player is eliminated. So, identify any abnormal condition that your referee must take care of in the purpose statement for the component. Also list those that you intend to leave for the 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 signed 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.

Design an interfaces for a tournament manager including its protocol. Spell out its purpose and workings so that you can ship off the specification to some third-party software producer and get something useful back.

Two pages should suffice. Less is more.

Testing Task Create a test harness named xstrategy The harness consumes its JSON input from STDIN and produces its results to STDOUT. Create five tests and place them in Tests.

The tests are formulated as pairs of files: <n>-in.json, the input, and <n>-out.json, the expected result, for an integer <n> greater or equal to 1.

Well-formed and Valid You may assume that all inputs for your test harnesses will be well-formed JSON and valid according to the homework description. You may also assume that the state is legal; furthermore, the given state describes a situation after players have placed all penguins and are ready to take turns. A valid State also comes with at least two players, each of which has the appropriate number of penguins on the board.

Its expected output is the best turn Action for the given depth D and State that the next (first in array) player can take according to the strategy.PP component from 5 — The Strategy. As before false is used to signal that there is no feasible Action.