7 — The Administrator
Due Thursday, 31 October 2019, midnight
Delivery Place the product of this week’s project steps into your repo as follows:
for the Design Task, place README.md in Planning/ and xtest in your Tsuro/ directory.
- for the Programming Task, place
administrator.PP in the Admin/
The file must come with a preamble that explains which other components you had to change to implement the administrator.
second-s.PP in Player/
for the Testing Task, place xref and ref-tests in a directory named 7
Design Task A software architecture often still emerges from a number of ad hoc decisions on the design of components. Sooner or later someone will have to write down how things hang together because your Tsuro.com idea has taken off and you need more software developers.
what the components are,
how they statically depend on each other, and
how they dynamically interact with each other.
Create a test script xtest that runs all unit tests for your entire code base.
Programming Task
Implement the tournament administrator.
The purpose of the administrator is to run a single complete tournament.
Once all players for a tournament are "registered", the administrator assigns them to games with the maximal number of participants permitted. The assignment is on a first-come-first-serve ("age") basis. If there are fewer than the maximal minimal number of players left over, the last two batches of players are divided up so that two non-maximal games are run (in decreasing number of players). If there are too few players, the administrator declares the existing players winners.
The top two (sets of) finishers of every game in a round get to continue in the next round. When there is only one game per round, the winner(s) of this game is (are) the winner(s) of the tournament; they will split the Billion CodeManistan Dollar award.
According to the protocol, the administrator informs all players of the outcome of the game. Ours merely tells a player whether or not it won.
Implement a second deterministic strategy.
Specifically the strategy must perform two tasks as follows:When the player is asked to place an initial tile, it searches for the first legal spot available in clockwise direction starting from (0,0) [exclusive]. To place the avatar, the player searches for the first legal port again in clockwise fashion that faces an empty square. The player uses the third given tile, without rotating it.
This point illustrates that players should have the option of giving up. When the player is asked to take its turn, it starts the search for a legal option with the first tile type, trying all possible rotations starting from 0 degrees. If none of these possibilities work out, it moves to the second one and repeats the process. If no possible action is legal, it chooses the first tile at 0 degrees.
If you need to change the player, you must document how and why at the top of your second-s.PP module.
Testing Task Develop a test harness for the referee using first-s as the player strategy.
The input is an array of three to five JSON strings, which represent the names of the players. The Players are arranged in descending order of age.
{ "winners" : [sorted-string-array, ...], "cheaters" : rank sorted-string-array } |
The sequence of sorted-string-arrays in the "winners" field drops |
trailing empty array. Fields with empty arrays are also dropped from the object. |
|
[String, ...] |
where the Strings are ordered in ascending, lexicographic manner. |
Create two tests and place them in ref-tests.