9 — Cleaning Up

Due Thursday, 14 November 2019, midnight

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

Design Task The first phase of the project is coming to an end. Now that we have the game logic in place and well tested, it is time to plan the second phase of our Tsuro.Com, a Plan.

The key to this second phase is a refinement of the local protocol into a distributed protocol. This change should not affect the logical structure of the protocol. Instead it should spell out (1) which remote proxy objects take on which task and (2) what the format of the TCP messages looks like.

Keep this memo to at most one page.

Programming Task

For those of you who have not taken theory, it is mathematically provable that there is no algorithm that discovers whether a function (or method) call goes into an infinite loop.

• Modify your referee and administrator so that no exceedingly slow calls to players pull down the system. Use 3s as your limit.

  Collect in slow.md all github commits necessary (message and id) to accomplish this goal. Describe your implementation in a short paragraph.

• Your first proper programming task is to implement a third strategy that works as follows:

  • When the player is asked to place an initial tile, it searches for the first legal spot available in counter-clockwise direction starting from (0,0) [exclusive]. To place the avatar, the player searches for the first legal port again in counter-clockwise fashion that faces an empty square. The player uses the third given tile, without rotating it.

  • When the player is asked to take its turn, it starts the search for a legal option with the second tile type, trying all possible rotations starting from 0 degrees. If none of these possibilities work out, it goes back to the first one and repeats the process. If no possible action is legal, it chooses the second tile at 0 degrees.

  If you need to change the player, you must document how and why at the top of your third-s.PP module.

• Ensure that all three strategies can be loaded dynamically via the test harness. Write a navigation document (loader.md) that explains (1) where the code for dynamically loading files exists in xadmin and (2) how this code works in your language.

• Optionally, modify your game observer so that a humob can inspect a game’s history via the left and right arrow keys. If you tackle this task, create a one-line observer.md file in Planning/ describing the basic change.

Testing Task Develop an additional three tests for your tournament administrator integration harness.

The tests use the same input and output format as 8 — Tournament and Game Observers. Every player configuration may point to any one of the three deterministic strategies.

Your test may not use more than 20 players.

Pedagogy In a professional setting you would probably develop a suite of stress tests now. You would then profile your code base to discover hot spots. An inspection of every hot spot would help you differentiate those that have to be “hot” from those that are hot because of inappropriate coding. Sadly a single semester does not come with enough time to explore these (and other) realistic issues of software development.