8 —
Due Wednesday, 17 November 2021, 11:59:59pm
Delivery Place the product of this week’s milestone into your repo as follows:
for the Programming Task, place manager.PP into the Admin/ directory;
for the Design Task, place remote.md in Planning/
for the Testing Task, place xref and Tests/ in a repo-level directory named 8 and cheat.PP into your Player/ folder
Programming Task Implement the tournament manager.
Do not worry about how players sign up; this piece of functionality is added when we get to the communication layer. Once all players for a tournament are "signed up", they are handed to the tournament manager in descending order of age.
The purpose of the manager is to run a tournament until a set of winners is determined. Its first task is to inform the players that the tournament has begun; their responses are maps. The manager chooses one of the submitted maps for all tournament games.
The manager runs the tournament as a knock-out elimination system. The first-placed finisher(s) of every game of round n move on to round n+1. The tournament ends when two tournament rounds of games in a row produce the exact same winners, when there are too few players for a single game, or when the number of participants is or has become small enough for single game, which is then run as the last and final game to determine the final surviving winners. In all cases, the surviving players share the Billion Thalers (nah, make this a Trillion; we’re all printing money now) TrainsHacker Award.
The allocation of players to games works as follows. The manager starts by assigning them to games with the maximal number of participants permitted in descending order of age. Once the number of remaining players drops below the maximal number and can’t run a game with the remainder, the manager backtracks by one game and tries games of size one less than the maximal number and so on until all players are assigned.
The manager’s result consists of two pieces: the tournament winner(s) and the misbehaving players.
See Logical Interactions 2 for a diagramatic summary of these specifications.
For testing purposes, the manager 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. The defaults should be a method for randomly picking destinations and another one for randomly shuffling a sequence of 250 colored cards.
Design Task We have reached the end of the second prototype stage. Our investors are surely going to be happy with the tournament demo. It is time to plan for the third and final stage, getting ready for the release. See Trains.Com, a Plan.
Design a remote collaboration protocol. The design document should consist of two parts. The first one is an interaction diagram that specifies the kinds of interactions between the Trains.com server (plus its relevant Admin components) and the remote clients (and their relevant Player components), including the JSON exchange format of each interaction. The second part of the document supplements the first with English explanations.
Start with the logical interaction diagram, sever the connections between the administrative and the player side, and develop a layer that connects the two parts. This last step demands both the design of new components and message formats, for which you can and should re=use the integration test formats. (Your software architect planned ahead.) According to our plan, this design step should not demand any changes to your logical components, which are now well-tested. Touching them would only re-introduce bugs.
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 named xref The harness consumes its JSON input from STDIN and prints its results to STDOUT. Create three tests; place them in Tests/.
What happens to the ranking of a game or tournament when a player fails while the referee or manager, respectively, informs the player of the outcome?
For these calls, the referee and manager, respectively, move the failing player from the ranking to the collection of failed player. No other action is needed.
Constraint No test file may exceed the size limit of 20Kb.
a Map with at most 20 cities and 40 connections,
an array of between 2 and 8 PlayerInstances, and
CONSTRAINT The PlayerNames are pairwise distinct.
an array of 250 Colors.
The output is either the JSON string "error: not enough destinations" or the outcome of running the game. The former means not every player had the chance to pick 2 destination cards from a selection of 5 such cards. The latter consists of a JSON array that contains a Ranking and a Rank. The first is the result of the game; the second are the misbehaving players.
As always, the tests are well-formed and valid JSON.
|
INTERPRETATION The JSON array specifies the construction of a player |
from the mechanism (of 6 — |
|
- "Hold-10" |
- "Buy-Now" |
- "Cheat" |
|
INTERPRETATION The string dictates to the test harness which strategy to load |
into which player. See below for some more details. |
|
lower- or upper-case alphabetical chars ([A-Za-z]). |
|
A Ranking is an array of Ranks. |
|
INTERPRETATION The ith array contains the PlayerNames of all |
ith-place finishers. An ith-place finisher is a player that has the ith-highest score. |
|
CONSTRAINT The last Rank in a Ranking corresponds to the last-place finisher. |
|
A Rank is a JSON array of PlayerNames sorted according |
to string<?. |
The Cheat strategy is like the Buy-Now strategy but attempts to acquire a non-existent connection the very first time a player is granted a turn. You need to implement it and place it into your Trains/Player folder.