Tsuro, A Local Protocol
The interaction between Racket player components and the Racket admin framework is governed by the set of following interaction diagrams.
Tournament Start Up
manager <-------------- player (p1) . . . player (pn) |
| | | | |
. . . . |
Running a Tournament
manager <-------------- player (p1) . . . player (pn) |
| | | |
| referee | | |
|--new(plrs1)-------+ | | |
| | | | |
. . . . an encounter among players in plrs1 |
|<================= | | | result: ??? |
| _ | | |
| | | |
. . . many games |
| referee | | |
|--new(plrs2)-------+ | | |
| | | | |
. . . . an encounter among players in plrs2 |
|<================= | | | result: ??? bad players, game order |
| _ | | |
| | | |
A Referee Interaction
The initial placements specify the current state of the board in terms of where other players have placed their avatars. The intermediate placements specify the complete configuration of the current game board. The format of this data is up to your implementation for the local protocol; the event flow has to be specified now because the distributed version will use the same one.
referee player: P-1 ... ... player: P-N |
| | | |
|------------------------|-------------->| playing-as(color) % avoids name clash |
| | | |
. . . |
| | | |
|-------------------|------------------->| playing-as(color) % avoids name clash |
| | | |
|-----------------> | | other-players (strings) |
| | | % the colors of the other players, |
. . . |
| | | % which is also the name of its workers |
|--------------------------------------> | other-players (strings) |
| | | |
|-----------------> | | initial(initial-placements) |
| <================ | | tile port place |
. . . |
|--------------------------------------> | initial(initial-placements) |
| <===================================== | tile port place |
. . . |
| | | |
|-----------------> | | take-turn(intermediate-placements) |
| <================ | | tile degrees |
. . . |
| -------------------------------------> | take-turn(intermediate-placements) |
| <===================================== | tile degrees |
| | | |
. . . |
Why do we take care of the first two kinds of failures here and why do we postpone the other two to the second phase of our plan?
the player breaks the rules (which concerns “business logic”)
the player raises an exception (due to an internal error).
players that cheat by exploiting the monolithic setting
players that take too long for an interaction (and are possibly in an infinite loop).
Terminated players no longer compete in the remainder of the tournament.
Closing Down
| ---------------------> | | end-of-tournament(results) |
| | | |
. . . |
| -------------------------------------> | end-of-tournament(results) |
. . . for all surviving players |
| | | |