8 — The League

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

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

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/.

Dealing with failure during informative calls. The project code is ready for integration testing of the referee, but to get this right, it is necessary to settle a question that could remain open until now:

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?

Here is the decision:

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.

This decision allows ranks in a ranking to be empty.

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

Its inputs are three JSON values:
  • 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 three values specify the game map to be used for a game, the participating players (in descending order of age), and which colored cards to hand out and in which order the referee hands out. — The referee determines the destinations and hands them out in the lexicographic order specified in 5 — The Strategy.

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.

Here are the new JSON data definitions:

    A PlayerInstance is a JSON array of two values:

      [PlayerName, Strategy]


      INTERPRETATION The JSON array specifies the construction of a player

        from the mechanism (of 6 — Games!) and a strategy (5 — The Strategy)


    A Strategy is one of the following three JSON strings:

      - "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.


    A PlayerName is a non-empty String of maximally 50

      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 test harness must turn the string into a file path to dynamically load an instance of a strategy class | function | module. It must not hard-wire connections to the strategies.Pedagogy We want to practice the construction of dynamically extensible systems.

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.