Text based API

Be sure to read and understand the rules before reading this page.

All agents (even python ones) are stand alone programs which qchess spawns instances of to play a game. Qchess sends state updates and requests moves from players through pipes. From the agent's point of view, all it has to do is read commands from stdin and respond to stdout.


Overview

In the following, lines prefixed with "<< " indicate input to the agent, lines prefixed with ">> " indicate output.

The end line character is a unix new line character '\n'. There is no carriage return.

A token prefixed with '$' is taken to be variable, whilst all other tokens are to be interpreted literally.


Game start

<< $colour

Where:

  1. $colour is either "white" or "black" and indicates the colour the agent will be playing as.
  2. The agent should make no response to this message. If it does, it will be declared illegal.

Request: Selection

<< SELECTION?

>> $x $y

Where:

  1. $x and $y are the x and y co-ordinates of the piece that the agent wishes to select.
    1. $x and $y must be the co-ordinates of a square that is on the board, and occupied by a piece belonging to the agent.
      1. The top left square is (x,y) = (0,0). The bottom right is at (x,y) = (7,7).
      2. Qchess does not recognise standard chess square names (eg: E5)
      3. A piece belongs to the agent if its colour matches that of the agent.
  2. An invalid selection results in the game ending with the offending agent declared illegal
  3. A valid selection results in a response from qchess; see Update: Agent selects a piece

Request: Movement

<< MOVE?

>> $x $y

If an agent selects a piece that cannot move, it will not receive this request before its next selection.

Where:

  1. If an agent selected a piece that couldn't move, it will not receive this request before another selection request
  2. $x and $y are the co-ordinates of the destination square
    1. The selected piece must be able to move into the square, and the square must be unoccupied or occupied by a piece of the opposing colour
    2. If the square was occupied by a piece of the opposing colour, that piece is "taken" and removed from the game
    3. If the "taken" piece was the opposing king, the agent will win the game.
    4. The agent must always make a move
  3. An invalid move results in the game ending with the offending agent declared illegal.
  4. A valid selection results in a response from qchess; see Update: Agent moves a piece

Update: Agent selects a piece

<< $x $y $index $type

Where:

  1. $x and $y are the x and y co-ordinates of the selected piece
  2. $index is either "0" or "1" and indicates which of its two states the selected piece is in.
  3. $type is a string indicating what the state of the piece actually is.
    1. This string is one of: "king", "queen", "rook", "knight", "bishop" or "pawn".
    2. The piece's next move will obey traditional chess movement rules for a piece of this type.
  4. The agent should not respond to this message, or it will be declared illegal

Update: Agent moves a piece

<< $x1 $y1 -> $x2 $y2

Where:

  1. The piece will have been been selected immediately prior to being moved.
  2. $x1 and $y1 are the x and y co-ordinates of the piece's original square.
  3. $x2 and $y2 are the x and y co-ordinates of the piece's destination square.
  4. Qchess does not provide any indication as to whether the move captured a piece or not

Note: The token between the two pairs of co-ordinates is a minus sign followed by a greater than sign. It's supposed to look like an arrow, but in html it's a bit hard to see.


Game ends

<< QUIT

Where:

  1. The agent should immediately exit cleanly without sending any response.
  2. Agents which do not exit after 2 seconds shall be sent SIGKILL

Notes:

  1. The "update" messages give no indication as to which player performed the selection or movement. However this is trivial for agents to keep track of.
  2. Agents can expect to receive an "update" message after responding successfully to the corresponding "request"
  3. If no request was made, the agent can assume the "update" is due to the action of the opponent.

Page last updated 2013-03-29 by matches

The UCC Website

UCC::Progcomp 2013