Code Colosseum

Code Colosseum is a platform to create and play algorithmic multiplayer games. Its main purposes are to provide an easier way to create multiplayer games that can be played by programs, and to provide the necessary tooling to assist the creation and interconnection of such programs.

This documentation serves as the primary source to understand how Code Colosseum works, how to use it (be it on the client side or on the server side), and how to create programs to play its games. It also provides the descriptions of currently supported games.

License

Code Colosseum is free software. It's released under the Mozilla Public License v2.0.

Architecture

Code Colosseum has a peculiar architecture when compared with software with similar purposes (e.g. contest management systems): all user programs run on the user's machine. This is not that unusual, in fact some competitions, such as the Facebook Hacker Cup, already evaluate all contestants code on the contestant's machine. However, these competitions all share a common trait: there is no interaction between the user's code and the remote evaluation program but the initial input download and the final output upload. Such systems are unable to deal with interactive problems.

Code Colosseum provides a system that has both the ability to deal with the interaction between the user's code and the remote evaluator and executes the user's code on the user's machine. To achieve that, it creates a virtual connection between the user's program and the remote evaluator, such that, in its simplest form, the user's program standard output is redirected into the standard input of the remote evaluator, and vice versa.

Note that, unlike more traditionals contest management systems, Code Colosseum's primary purpose is to deal with multiplayer games, as such the concept of the more traditional evaluator is substituted with the concept of game manager, which is a program that manages an instance of a game, collects inputs from \( n \) clients, computes the game simulation accordingly, and sends back the updates.

Lobby

Code Colosseum provides no user authentication by design. The rationale is to keep its codebase and its setup as simple as possible. This, however, comes at the cost of having a (bit) more complicated match setup.

Code Colosseum keeps a lobby of waiting to start and running matches. The lobby serves as the sole access point for players to join a match waiting to start.

The command line client provides a way to show the current status of the lobby. Other clients could provide it as well.

Match Creation

A new match can be created by anyone, by either using the command line client or some other mean. When creating a match the user must specify the following parameters:

  • game to be played
  • name of the match
  • number of players
  • number of server bots
  • timeout for player inactivity
  • an optional password to join the match
  • optionally the server password to create a verified game
  • other parameters specific to the game requested

Note that, depending on the client used, some parameters could have defaults, and as such will not be needed to be specified. Also note that, depending on the game chosen, not all possible values of such parameters will be available (e.g. for Rock Paper Scissors creating a match with a number of players rather than 2 will cause an error and the match will not be created). Such restrictions will be indicated on the description of each game.

A match starts as soon as the number of players needed to start it has been reached. If a waiting-to-start match is inactive for some time, it will be removed from the lobby. The command line client provides an indication of such expiration time.

When created, the server will return the match ID, which is the identifier needed to join or spectate a match.

Spectators

Code Colosseum provides the ability to spectate any match, either be waiting to start or already running. Spectators can spectate password protected matches without needing a password. Thus, in the spectator sense, all matches are public.

Spectators will get a read-only stream of the match, the contents of which are specified in the description of each game. Note that, like the stream for playing parties, the stream is not supposed to be human-readable, and as such will likely need to be connected to a program that renders it in a human-readable way.

Note that some games provide such rendering programs, some even with a graphical user interface.

Command Line Client

Code Colosseum provdes coco, a command line client that provides an user interface to interact with a Code Colosseum server.

Prebuilt binaries

Prebuilt binaries for coco can be found in the Releases section of the GitHub page. It is advised to put the downloaded and extracted executable in a directory included in the system PATH.

If a prebuilt binary for the desired operating system and architecture is not found, then the only option is to build coco from the source code.

Building from source

The command line client is written in the Rust programming language. Thus, to build it the first step is to install Rust.

Once the Rust compiler has been installed, the source code can be downloaded here. Alternatively, it can be obtained by cloning the GitHub repository by using the following command:

$ git clone https://github.com/dariost/CodeColosseum.git

Then, the client can be built using the following command:

$ cargo build --release --bin coco

The resulting compiled binary file will be found in the target/release/ directory, and will be named coco.exe on Windows and coco on other operating systems. It is advised to put such program in a directory included in the system PATH.

Basic usage

coco provides several subcommands that will be discussed in the following subsections. It is advised to read such subsections as well as using the --help feature of coco to explore its options:

$ coco --help

The only common option to all of coco subcommands is the server directive, used to specify the server to which coco will connect and passed using the -s prefix.

The official server of Code Colosseum is located at wss://code.colosseum.cf/, thus all examples will feature such server. As a first example, the invocation of coco to list the available games on the official server would be:

$ coco -s wss://code.colosseum.cf/ list

list

This subcommand can be used to list the available games on a server:

$ coco -s wss://code.colosseum.cf/ list

This will print a list of available games.

This subcommand can also be used to retrieve the description for a game. To do so the game name must be specified after list. For instance, to get the description for the game roshambo the following command can be used:

$ coco -s wss://code.colosseum.cf/ list roshambo

Note that all descriptions should be written in MarkDown, thus, if pandoc is available, a PDF can be generated from the description of a game using the following command:

$ coco -s wss://code.colosseum.cf/ list roshambo | pandoc -o roshambo.pdf

lobby

This subcommand can be used to list waiting to start and running matches currently present in the lobby:

$ coco -s wss://code.colosseum.cf/ lobby

This will print a table with information about the matches:

  • ID: the unique identifier of the match;
  • Verified: whether the game has been created by a server admin;
  • Name: the name of the match;
  • Game: the game to be played;
  • Players: the number of currently connected players over the number of players needed to start the match;
  • Spectators: the number of currently spectators connected to this match;
  • Timeout: the timeout (in seconds) for players send some (valid) data before getting forcibly disconnected by the server;
  • Password: whether a password is needed to join the match;
  • Timing: expiration information for waiting to start matches and running time for running matches.

new

This subcommand can be used to create a new match. The bare minimum needed to create a match is to provide the game to be played. For instance, creating a match of roshambo can be done using the following command:

$ coco -s wss://code.colosseum.cf/ new roshambo

If the creation is succesul the unique ID of the match will be printed, otherwise an error message will be shown.

The creation of a new match can be further customised.

To add a custom name for the match you can add a positional argument at the end:

$ coco -s wss://code.colosseum.cf/ new roshambo "Test Match"

To specify the number of players for the match, the -n switch can be used:

$ coco -s wss://code.colosseum.cf/ new roshambo -n 2

To specify the number of server provided bots for the match, the -b switch can be used:

$ coco -s wss://code.colosseum.cf/ new roshambo -b 1

To specify the timeout for player inactivity, the -t switch can be used:

$ coco -s wss://code.colosseum.cf/ new roshambo -t 5

To specify a password to join the game, the -p switch can be used:

$ coco -s wss://code.colosseum.cf/ new roshambo -p "securepassword"

To specify further arguments specific to the game, the -a switch can be used (even multiple times), following the format -a key=val:

$ coco -s wss://code.colosseum.cf/ new roshambo -a rounds=100

To create a verified game, if in posses of the server master password, the -v switch can be used:

$ coco -s wss://code.colosseum.cf/ new roshambo -v "servermasterpassword"

connect

This subcommand can be used to join a waiting-to-be-started match or spectate any match (either already running or not). The bare minimum needed to join or spectate a match is the match unique ID and a local program to run which will be connected to the server data stream. The protocol of such stream is discussed in the description of each game.

To then join a match with ID abacaba using the program prog.exe the command would be:

$ coco -s wss://code.colosseum.cf/ connect "abacaba" -- prog.exe

And to spectate it the -s switch must be added:

$ coco -s wss://code.colosseum.cf/ connect -s "abacaba" -- prog.exe

Note that it is possible to provide arguments to the local program, for instance:

$ coco -s wss://code.colosseum.cf/ connect "abacaba" -- prog.exe arg1 arg2

This is useful when wanting to connect a program written in an interpreted language such as python. For instance, to connect the program prog.py che command would be:

$ coco -s wss://code.colosseum.cf/ connect "abacaba" -- python prog.py

Note that it is possible to omit the local program, however this is discouraged, as it will cause a cat-like program to be called instead.

If a match is password protected, the password can be provided with the -p switch:

$ coco -s wss://code.colosseum.cf/ connect -p "securepassword" "abacaba" -- prog.exe

When joining a match a custom username can be choosed by using the -n switch:

$ coco -s wss://code.colosseum.cf/ connect -n "verycoolname" "abacaba" -- prog.exe

Note that both the username and password options are ignored when spectating.

The communication with the local program is performed through a channel. There are two channels types available, stdio and pipe. The default is stdio. The channel can be choosed using the -c switch:

$ coco -s wss://code.colosseum.cf/ connect -c "pipe" "abacaba" -- prog.exe

The details of such channels are discussed in the further subsubsections.

stdio channel

The stdio communication channel uses the program stdout for output and stdin for input. This is the classically used communication method for most of the contents management systems.

Thus, to read from the server data stream is to read from stdin and to write to the server data stream is to write to stdout. Note that it is a good practice to flush stdout after each write, since some buffering might happend and the written command would not be sent to the server.

Since the stdin and stdout streams of the program are managed by coco to communicate with the server, they cannot be used to read or write strings from or to the terminal. However, the stderr stream is free, and can be used to write strings to the terminal. If more freedom is needed, refer to the pipe communication channel.

In spectator mode only the stdin stream is captured by coco.

A simple usage example in python of the stdio communication channel is provided:

#!/usr/bin/env python3

from sys import stderr

if __name__ == "__main__":
    from_server = input().strip()
    print("to_server", flush=True)
    print("debug print", file=stderr)

pipe channel

The pipe communication channel uses named pipes as the communication mean to and from the program. Since the implementation of named pipes is wildly different between Unix-like operating systems and Windows, they shall be discussed separately.

Unix-like (Linux, macOS, FreeBSD, etc.)

On Unix-like systems named pipes can be read and written as ordinary files. Thus, their use is no different than reading and writing using the common libraries that programming languages usually provide.

If a program is started by coco with the pipe channel, coco will pass to the program two environment variables: COCO_PIPEIN and COCO_PIPEOUT. These two variables contain the names of the files to be used for input and output, respectively.

The program shall read the file names from these environment variables and open the respective files in read and write mode as the first operation of the program.

coco will not consider the program as started until both files are opened.

Since the program sees these pipes as files, writing operations to the output pipe will be buffered even in the presence of a LF, since the rules for buffering are different between files and stdout. Thus, the output stream must be flushed manually when written.

In spectator mode only COCO_PIPEIN is provided to the program.

A simple usage example in python of the pipe communication channel is provided:

#!/usr/bin/env python3

from os import environ

if __name__ == "__main__":
    fin = open(environ["COCO_PIPEIN"], "r")
    fout = open(environ["COCO_PIPEOUT"], "w")
    from_server = fin.readline().strip()
    print("to_server", file=fout, flush=True)
    print("debug print")

Windows

The pipe communication channel is currently unavailable on Windows.

Games

The following subsections contain the descriptions of available games.

The standard format for a description contains:

  • an introduction to the game;
  • an Implementation details subsection, containing the description of the communication protocol between the players programs and the server, as well as the one for spectators;
  • a Game parameters subsection, containing the game-specific parameters that can be passed on the creation of a match via the -a switch, if using the command line client.

roshambo (Rock Paper Scissors)

Rock Paper Scissors (also called roshambo) is one of the most basic hand games.

It is played by two players, which in each round choose one of the gestures paper, rock or scissors and show them at the same time. If the two gestures chosen are different, the winner is computed as follows:

  • paper wins over rock
  • rock wins over scissors
  • scissors win over paper

For each round a point is awarded to the winner (if any). The player with most points at the end wins.

Implementation details

Both players and the spectators will receive three lines at the beginning of the match, containing the two players names and the number of rounds. Each player will receive its own name as the first line.

For instance, if there are two players Player0 and Player1 in a match with 42 rounds, then:

Player0 will receive:

Player0
Player1
42

Player1 will receive:

Player1
Player0
42

Spectators will receive:

Player0
Player1
42

Then, for the number of rounds specified, both players will have to send their choice of move to the server using one of the strings ROCK, PAPER or SCISSORS with a single LF (aka \n) at the end. After sending a move choice, they will have to read a single line containing the choice of the opponent. Other then the opponent choice, the string RETIRE can also be received, which means the opponent as retired and the player must exit the match. This cycle will then repeat for the remaining rounds.

Spectators will receive for each round two lines containing the choice of the two players. The lines are given in the same order as players names at the beginning of the stream.

For instance, if in a round Player0 chooses ROCK and Player1 chooses PAPER, then (sent lines are prefixed with a >):

Player0 will receive:

>ROCK
PAPER

Player1 will receive:

>PAPER
ROCK

Spectators will receive:

ROCK
PAPER

A complete game can look like this:

Player0 will receive:

Player0
Player1
3
>ROCK
PAPER
>PAPER
PAPER
>ROCK
SCISSORS

Player1 will receive:

Player1
Player0
3
>PAPER
ROCK
>PAPER
PAPER
>SCISSORS
ROCK

Spectators will receive:

Player0
Player1
3
ROCK
PAPER
PAPER
PAPER
ROCK
SCISSORS

Game parameters

There are two game specific parameters available:

  • rounds: specifies the number of rounds;
  • pace: specifies a minimum time interval (in seconds) between rounds.

royalur (Royal Game of Ur)

The Royal Game of Ur is one the oldest board games, dating back to at least 5000 years ago. This excellent video gives a thorough introduction to this game, explaining its rules from 3:41 to 5:10.

image/svg+xml

The Royal Game of Ur is a race game. Each player has 7 tokens, and it wants to send all tokens to the end of the track before the opponent does. Each player has a track of 14 cells (not counting start and end), with the cells from the fifth to the twelfth (included) shared between players. The game is played in turns alternating between the two players until one of them make all of their tokens exit the track, winning the game.

At the start of its turn, the player flips 4 two-sided coins, which will give a number \( n \) of heads. The player must then choose a token to move \( n \) cells forward. For a token, to exit the track, the exact number of cells remaining is needed (e.g. if a token is on the fourteenth cell, only a \( 1 \) can make it exit the track). If no moves are possible for the player (such as when getting a \( 0 \), but it's not the only such case) then it skips the turn, giving it to the other player.

The player cannot move a token in a cell already occupied by one of its token, however it can move it in a cell occupied by an opponent's token. In this case, the opponent's token gets instantly sent back to the opponent's track start, and the cell becomes occupied by the player token.

If a token lands on the fourth, eighth or fourteenth cell, the player gets to play also for the next turn, otherwise the opponent's turn begins. A token cannot land on one of these 3 cells if it's already occupied (even by an opponent's token).

Implementation details

At the beginning of the game both players will receive 3 lines:

  • the first line contains the name of the first player;
  • the second line contains the name of the second player;
  • the third line contains 0 if the receiver is the first player, 1 otherwise.

Spectators will only receive the first two lines. In the first turn the first player will play.

Each turn is subdivided into two sub-turns:

  • roll;
  • move.

In the roll sub-turn both players and spectators will receive a single line containing 4 space-separated binary digits. The 1s represent a head, the 0 a tail. The amount \( n \) is calculated as the number of 1s obtained.

If the player has no valid moves that move a token \( n \) cells forward, the the move sub-turn is skipped and the roll sub-turn immediately starts for the other player.

Otherwise, the move sub-turn begins. Each player has 7 tokens, numbered from 0 to 6 (inclusive). The player playing in this turn must write a single line with the number of the token he wants to move forward \( n \) cells, ended with a LF (aka \n). The move must be valid. If the move is valid, the other player and the spectators will receive the sent number, otherwise they will receive RETIRE, which indicates that the game has ended with a win for the opponent.

If the token lands on the fourth, eighth or fourteenth cell than the player has another turn, thus moving again to the roll sub-turn. Otherwise, the turns pass to the opponent, which begins its roll turn.

Example

This is an example of the streams of two players, PlayerA and PlayerB, and the spectators for an hypothetical game.

Note that all lines prepended with a > indicate that the line is sent rather than received.

Stream of PlayerA:

PlayerA
PlayerB
0
0 0 1 1
>3
1 1 1 1
0
1 0 1 0
0
0 1 0 0
>3
0 0 0 0
1 0 1 1
>3
0 0 1 1
0
0 0 0 1
>4
1 0 1 0
RETIRE

Stream of PlayerB:

PlayerA
PlayerB
1
0 0 1 1
3
1 1 1 1
>0
1 0 1 0
>0
0 1 0 0
3
0 0 0 0
1 0 1 1
3
0 0 1 1
>0
0 0 0 1
4
1 0 1 0
>2

Stream of spectators:

PlayerA
PlayerB
0 0 1 1
3
1 1 1 1
0
1 0 1 0
0
0 1 0 0
3
0 0 0 0
1 0 1 1
3
0 0 1 1
0
0 0 0 1
4
1 0 1 0
RETIRE

Game parameters

There's only one game-specific parameter:

  • pace: the minimum number of seconds between turns (default: 1.5, min: 0, max: 30).

Additional information:

  • the game can only be played by exactly 2 players;
  • the default timeout is 90 seconds;
  • no more than 1 server bot per game is allowed.

Dama

The checker takes place between two players, arranged on opposite sides of a damsel, who move their pieces alternately; one player has white pieces, the other black ones. The pieces move diagonally, only on the dark squares not occupied by other pieces and have the opportunity to capture (familiarly, "eat") those opponents, bypassing them. Captured pieces are removed from the damiera and excluded from the game. The player to whom all the pieces are captured or who, on his turn of move, is unable to move, has lost.

Simple pieces (checkers) can move only one box at a time, diagonally and forward; they can also take an opposing piece by making a movement of two squares in the same direction, jumping over the opposing piece in the middle box. If in the arrival box the checker is able to make a new grip, you are in the presence of a multiple grip, which must be completed in the same game turn.

When a checker reaches the opposing base, which is the most distant line in its direction of travel, it becomes a checker. The checker is marked by placing an additional piece above the first and enjoys special powers: unlike the checkers, can move and capture both forward and backward. Ladies can’t be eaten by pawns.

To conclude, the ancient rule of the "breath", that is to capture the opposing piece that even having right, for distraction or choice had not eaten, was abolished by the Federation Checkers in 1934.

Implementation details

At the beginning of the game the names of the players are printed on screen and it is indicated if you have the white or black checkers, then the damiera is printed and the game begins the player who owns the white checkers.

The spectators will receive the names of the players, the round and the damsel.

Each player is notified when it is his turn and during the latter will have to make a move or capture if possible. In case the move or a catch is not valid you will have to try again.

The game ends when one of the two players runs out of tokens and is later declared the winner.

Example

This is an example of the streams of two players, PlayerA and PlayerB, and the spectators for an hypothetical game.

Move

Stream of PlayerA:

PlayerA
PlayerB
Avvio la partita di dama...

   A  B  C  D  E  F  G  H
1 [ ][n][ ][n][ ][n][ ][n] 1
2 [n][ ][n][ ][n][ ][n][ ] 2
3 [ ][n][ ][n][ ][n][ ][n] 3
4 [ ][ ][ ][ ][ ][ ][ ][ ] 4
5 [ ][ ][ ][ ][ ][ ][ ][ ] 5
6 [b][ ][b][ ][b][ ][b][ ] 6
7 [ ][b][ ][b][ ][b][ ][b] 7
8 [b][ ][b][ ][b][ ][b][ ] 8
   A  B  C  D  E  F  G  H

Sei i Bianchi
Turno bianco!
E' il tuo turno.

Inserisci la pedina che vuoi muovere e poi le mosse che vuoi fare
Es > 6A 5B oppure 6A 4C 2A oppure 6A 4C 2A ...
6e 5d

   A  B  C  D  E  F  G  H
1 [ ][n][ ][n][ ][n][ ][n] 1
2 [n][ ][n][ ][n][ ][n][ ] 2
3 [ ][n][ ][n][ ][n][ ][n] 3
4 [ ][ ][ ][ ][ ][ ][ ][ ] 4
5 [ ][ ][ ][b][ ][ ][ ][ ] 5
6 [b][ ][b][ ][ ][ ][b][ ] 6
7 [ ][b][ ][b][ ][b][ ][b] 7
8 [b][ ][b][ ][b][ ][b][ ] 8
   A  B  C  D  E  F  G  H

Stream of PlayerB:

PlayerA
PlayerB
Avvio la partita di dama...

   A  B  C  D  E  F  G  H
1 [ ][n][ ][n][ ][n][ ][n] 1
2 [n][ ][n][ ][n][ ][n][ ] 2
3 [ ][n][ ][n][ ][n][ ][n] 3
4 [ ][ ][ ][ ][ ][ ][ ][ ] 4
5 [ ][ ][ ][ ][ ][ ][ ][ ] 5
6 [b][ ][b][ ][b][ ][b][ ] 6
7 [ ][b][ ][b][ ][b][ ][b] 7
8 [b][ ][b][ ][b][ ][b][ ] 8
   A  B  C  D  E  F  G  H

Sei i Neri
Turno bianco!


   A  B  C  D  E  F  G  H
1 [ ][n][ ][n][ ][n][ ][n] 1
2 [n][ ][n][ ][n][ ][n][ ] 2
3 [ ][n][ ][n][ ][n][ ][n] 3
4 [ ][ ][ ][ ][ ][ ][ ][ ] 4
5 [ ][ ][ ][b][ ][ ][ ][ ] 5
6 [b][ ][b][ ][ ][ ][b][ ] 6
7 [ ][b][ ][b][ ][b][ ][b] 7
8 [b][ ][b][ ][b][ ][b][ ] 8
   A  B  C  D  E  F  G  H

Stream of spectators:

PlayerA
PlayerB
Avvio la partita di dama...

   A  B  C  D  E  F  G  H
1 [ ][n][ ][n][ ][n][ ][n] 1
2 [n][ ][n][ ][n][ ][n][ ] 2
3 [ ][n][ ][n][ ][n][ ][n] 3
4 [ ][ ][ ][ ][ ][ ][ ][ ] 4
5 [ ][ ][ ][ ][ ][ ][ ][ ] 5
6 [b][ ][b][ ][b][ ][b][ ] 6
7 [ ][b][ ][b][ ][b][ ][b] 7
8 [b][ ][b][ ][b][ ][b][ ] 8
   A  B  C  D  E  F  G  H

Turno bianco!


   A  B  C  D  E  F  G  H
1 [ ][n][ ][n][ ][n][ ][n] 1
2 [n][ ][n][ ][n][ ][n][ ] 2
3 [ ][n][ ][n][ ][n][ ][n] 3
4 [ ][ ][ ][ ][ ][ ][ ][ ] 4
5 [ ][ ][ ][b][ ][ ][ ][ ] 5
6 [b][ ][b][ ][ ][ ][b][ ] 6
7 [ ][b][ ][b][ ][b][ ][b] 7
8 [b][ ][b][ ][b][ ][b][ ] 8
   A  B  C  D  E  F  G  H

Single catch

Stream of PlayerA:

   A  B  C  D  E  F  G  H
1 [ ][n][ ][n][ ][n][ ][n] 1
2 [n][ ][n][ ][n][ ][n][ ] 2
3 [ ][ ][ ][n][ ][n][ ][ ] 3
4 [n][ ][b][ ][ ][ ][n][ ] 4
5 [ ][ ][ ][ ][ ][ ][ ][ ] 5
6 [b][ ][b][ ][b][ ][b][ ] 6
7 [ ][b][ ][ ][ ][b][ ][b] 7
8 [b][ ][b][ ][b][ ][b][ ] 8
   A  B  C  D  E  F  G  H

Turno nero!

   A  B  C  D  E  F  G  H
1 [ ][n][ ][n][ ][n][ ][n] 1
2 [n][ ][n][ ][n][ ][n][ ] 2
3 [ ][ ][ ][ ][ ][n][ ][ ] 3
4 [n][ ][ ][ ][ ][ ][n][ ] 4
5 [ ][n][ ][ ][ ][ ][ ][ ] 5
6 [b][ ][b][ ][b][ ][b][ ] 6
7 [ ][b][ ][ ][ ][b][ ][b] 7
8 [b][ ][b][ ][b][ ][b][ ] 8
   A  B  C  D  E  F  G  H

Stream of PlayerB:

   A  B  C  D  E  F  G  H
1 [ ][n][ ][n][ ][n][ ][n] 1
2 [n][ ][n][ ][n][ ][n][ ] 2
3 [ ][ ][ ][n][ ][n][ ][ ] 3
4 [n][ ][b][ ][ ][ ][n][ ] 4
5 [ ][ ][ ][ ][ ][ ][ ][ ] 5
6 [b][ ][b][ ][b][ ][b][ ] 6
7 [ ][b][ ][ ][ ][b][ ][b] 7
8 [b][ ][b][ ][b][ ][b][ ] 8
   A  B  C  D  E  F  G  H

Turno nero!
E' il tuo turno.

Inserisci la pedina che vuoi muovere e poi le mosse che vuoi fare
Es > 6A 5B oppure 6A 4C 2A oppure 6A 4C 2A ...
3d 5b

   A  B  C  D  E  F  G  H
1 [ ][n][ ][n][ ][n][ ][n] 1
2 [n][ ][n][ ][n][ ][n][ ] 2
3 [ ][ ][ ][ ][ ][n][ ][ ] 3
4 [n][ ][ ][ ][ ][ ][n][ ] 4
5 [ ][n][ ][ ][ ][ ][ ][ ] 5
6 [b][ ][b][ ][b][ ][b][ ] 6
7 [ ][b][ ][ ][ ][b][ ][b] 7
8 [b][ ][b][ ][b][ ][b][ ] 8
   A  B  C  D  E  F  G  H

Stream of spectators:

   A  B  C  D  E  F  G  H
1 [ ][n][ ][n][ ][n][ ][n] 1
2 [n][ ][n][ ][n][ ][n][ ] 2
3 [ ][ ][ ][n][ ][n][ ][ ] 3
4 [n][ ][b][ ][ ][ ][n][ ] 4
5 [ ][ ][ ][ ][ ][ ][ ][ ] 5
6 [b][ ][b][ ][b][ ][b][ ] 6
7 [ ][b][ ][ ][ ][b][ ][b] 7
8 [b][ ][b][ ][b][ ][b][ ] 8
   A  B  C  D  E  F  G  H

Turno nero!

   A  B  C  D  E  F  G  H
1 [ ][n][ ][n][ ][n][ ][n] 1
2 [n][ ][n][ ][n][ ][n][ ] 2
3 [ ][ ][ ][ ][ ][n][ ][ ] 3
4 [n][ ][ ][ ][ ][ ][n][ ] 4
5 [ ][n][ ][ ][ ][ ][ ][ ] 5
6 [b][ ][b][ ][b][ ][b][ ] 6
7 [ ][b][ ][ ][ ][b][ ][b] 7
8 [b][ ][b][ ][b][ ][b][ ] 8
   A  B  C  D  E  F  G  H

Multiple capture

Stream of PlayerA:

   A  B  C  D  E  F  G  H
1 [ ][n][ ][n][ ][n][ ][n] 1
2 [n][ ][n][ ][n][ ][n][ ] 2
3 [ ][ ][ ][n][ ][n][ ][ ] 3
4 [n][ ][b][ ][ ][ ][n][ ] 4
5 [ ][ ][ ][ ][ ][ ][ ][ ] 5
6 [b][ ][b][ ][b][ ][b][ ] 6
7 [ ][b][ ][ ][ ][b][ ][b] 7
8 [b][ ][b][ ][b][ ][b][ ] 8
   A  B  C  D  E  F  G  H

Turno nero!

   A  B  C  D  E  F  G  H
1 [ ][n][ ][n][ ][n][ ][n] 1
2 [n][ ][n][ ][n][ ][n][ ] 2
3 [ ][ ][ ][ ][ ][n][ ][ ] 3
4 [n][ ][ ][ ][ ][ ][n][ ] 4
5 [ ][ ][ ][ ][ ][ ][ ][ ] 5
6 [b][ ][ ][ ][b][ ][b][ ] 6
7 [ ][b][ ][n][ ][b][ ][b] 7
8 [b][ ][b][ ][b][ ][b][ ] 8
   A  B  C  D  E  F  G  H

Stream of PlayerB:

   A  B  C  D  E  F  G  H
1 [ ][n][ ][n][ ][n][ ][n] 1
2 [n][ ][n][ ][n][ ][n][ ] 2
3 [ ][ ][ ][n][ ][n][ ][ ] 3
4 [n][ ][b][ ][ ][ ][n][ ] 4
5 [ ][ ][ ][ ][ ][ ][ ][ ] 5
6 [b][ ][b][ ][b][ ][b][ ] 6
7 [ ][b][ ][ ][ ][b][ ][b] 7
8 [b][ ][b][ ][b][ ][b][ ] 8
   A  B  C  D  E  F  G  H

Turno nero!
E' il tuo turno.

Inserisci la pedina che vuoi muovere e poi le mosse che vuoi fare
Es > 6A 5B oppure 6A 4C 2A oppure 6A 4C 2A ...
3d 5b 7d

   A  B  C  D  E  F  G  H
1 [ ][n][ ][n][ ][n][ ][n] 1
2 [n][ ][n][ ][n][ ][n][ ] 2
3 [ ][ ][ ][ ][ ][n][ ][ ] 3
4 [n][ ][ ][ ][ ][ ][n][ ] 4
5 [ ][ ][ ][ ][ ][ ][ ][ ] 5
6 [b][ ][ ][ ][b][ ][b][ ] 6
7 [ ][b][ ][n][ ][b][ ][b] 7
8 [b][ ][b][ ][b][ ][b][ ] 8
   A  B  C  D  E  F  G  H

Stream of spectators:

   A  B  C  D  E  F  G  H
1 [ ][n][ ][n][ ][n][ ][n] 1
2 [n][ ][n][ ][n][ ][n][ ] 2
3 [ ][ ][ ][n][ ][n][ ][ ] 3
4 [n][ ][b][ ][ ][ ][n][ ] 4
5 [ ][ ][ ][ ][ ][ ][ ][ ] 5
6 [b][ ][b][ ][b][ ][b][ ] 6
7 [ ][b][ ][ ][ ][b][ ][b] 7
8 [b][ ][b][ ][b][ ][b][ ] 8
   A  B  C  D  E  F  G  H

Turno nero!

   A  B  C  D  E  F  G  H
1 [ ][n][ ][n][ ][n][ ][n] 1
2 [n][ ][n][ ][n][ ][n][ ] 2
3 [ ][ ][ ][ ][ ][n][ ][ ] 3
4 [n][ ][ ][ ][ ][ ][n][ ] 4
5 [ ][ ][ ][ ][ ][ ][ ][ ] 5
6 [b][ ][ ][ ][b][ ][b][ ] 6
7 [ ][b][ ][n][ ][b][ ][b] 7
8 [b][ ][b][ ][b][ ][b][ ] 8
   A  B  C  D  E  F  G  H

Additional information

  • the game can only be played by exactly 2 players
  • no more than 1 server bot per game is allowed.