Logical Interactions
The interaction between Racket player components and the Racket admin framework is governed by the set of following interaction diagrams.
Starting a Tournament
|
manager <---------------------- player (p_1) . . . player (p_n) |
| | | % for n <= MAX_PLAYERS |
| | | |
| | | |
| | | |
| start(Boolean) | | % true means the tournament |
| -----------------------------> | | % is about to start |
. . . |
. . . |
. . . |
| start(Boolean) | | |
| -----------------------------------------------> | |
| | | |
Running a Tournament
|
manager player (p_1) . . . player (p_n) |
| | | |
| new(players[]) | | |
| -----------------> referee | | |
| | | | |
. . . . |
. . . . % play a game |
. . . . % (see below) |
. . . . |
. . . . |
| | | | |
| players[players[]], | | | % the ranking |
| players[] | | | % the "cheaters" |
| <=================== | | | |
. ___ . . |
. . . |
. . . % as long as |
. . . % one game can |
. . . % be played |
. . . |
| | | |
| new(players[]) | | |
| -----------------> referee | | |
| | | | |
. . . . |
. . . . % play last game |
. . . . |
. . . . |
| | | | |
| players[players[]], | | | % the ranking |
| players[] | | | % the "cheaters" |
| <=================== | | | |
. ___ . . |
| | | |
| | | |
Terminating a Tournament
|
manager player (p_1) . . . player (p_n) |
| | | |
| | | |
| end(Boolean) | | |
| -----------------------------> | | % true means "winner" |
| | | % false means "loser" |
. . . |
. . . |
. . . |
. . . |
| end(Boolean) | | |
| -----------------------------------------------> | |
| | | |
| | | |
Starting a Game
|
referee player (p_1) . . . player (p_n) |
| | | |
| play_as(color) | | |
| -----------------------------> | | |
| | | |
. . . |
. . . % p_i's assigned |
. . . % color for a game |
| play_as(color) | | |
| -----------------------------------------------> | |
| | | |
| play_with(color[]) | | |
| -----------------------------> | | |
| | | |
. . . |
. . . % the colors of |
. . . % other players |
. . . |
| play_with(color[]) | | |
| -----------------------------------------------> | |
| | | |
| | | |
| setup(state) | | |
| -----------------------------> | | |
| place | | |
| <============================ | | |
. . . |
. . . % choose a place |
. . . % for one penguin |
. . . |
| | | |
| setup(state) | | |
| -----------------------------------------------> | |
| place | | |
| <=============================================== | |
. . . |
. . . % repeat for as |
. . . % many penguins |
. . . % as allocated |
| setup(state) | | |
| -----------------------------> | | |
| place | | |
| <============================ | | |
. . . |
. . . % choose a place |
. . . % for one penguin |
. . . |
| | | |
| setup(state) | | |
| -----------------------------------------------> | |
| place | | |
| <=============================================== | |
Playing Turns
|
referee player (p_1) . . . player (p_n) |
| | | |
| tt(state,actions[]) | | % player receives: first calls & |
| -----------------------------> | | % - current state |
| action | | % - actions since last call to `this` player* |
| <============================ | | % returns a move |
. . . |
. . . % one turn per player |
. . . % skip if it cannot |
. . . % move in `this` state |
. . . |
| tt(state,actions[]) | | |
| -----------------------------------------------> | |
| action | | |
| <=============================================== | |
| | | |
. . . |
. . . % repeat until |
. . . % no penguin is |
. . . % able to move |
. . . |
| | | |
| tt(state,actions[]) | | |
| -----------------------------> | | |
| action | | |
| <============================ | | |
. . . |
. . . |
. . . |
. . . |
| tt(state,actions[]) | | |
| -----------------------------------------------> | |
| action | | |
| <=============================================== | |
| | | |
. . . |
. . . |
|
|
* oldest action unknown to player first, youngest last |
|
& the very first call (and only this call) to take-turn during any |
game will be limited to 3s |
Your server does _not_ have to implement the actions[] part of the take-turn protocol (always send [] instead) but your clients may use the actions if a server does deliver a non-empty actions[] array.
Convention The % parts on the right are interpretive comments. ~~ A missing return arrow means that method must successfully return void.
breaks the rules (a “business logic” bug)
raises an exception (a safety bug)
takes too long for a computation (a DoS bug).
These terminations are not specified in the sequence diagram.