Welcome to the Battle Royale web site!  Here you’ll find the game rules, project overview, downloads, and other documentation.

Some of you might have heard of or perhaps even played the board game Quoridor (http://en.wikipedia.org/wiki/Quoridor), designed by Mirko Marchesi and published by Gigamic Games. Quoridor received the Mensa Mind Game award in 1997 and Game of the Year in the USA, France, Canada and Belgium.

The game board is composed of 81 squares (9×9). There are a total of 20 walls (of length 2 units) that can be placed in grooved slots between squares. The walls are evenly divided between the players. Each player starts in the middle of one side of the board and aims to get to the opposite side – whoever does this first, wins. In every move, a player either moves their pawn to an adjacent square, or places a wall to make the path for the other player(s) more complicated.

The game is played with either 2 or 4 players. We will first describe a two player game in detail.

Two player game:

Initial configuration. The figure shows the initial board configuration for two players. At the start of the game the players are positioned in the middle of two opposite sides of the board, the first (red) player in the bottom row and the second (blue) player in the top row. The red player aims for the top row (the red squares), and the blue player aims for the bottom row (the blue squares). Each player has 10 walls in storage to begin with, as indicated below the players’ names on the right.

The circled number next to a player indicates the player’s player ID (player 1 or 2) and it is shown when it is their turn to move. The circled numbers on the left and above the board represent a coordinate system on the board and they are not essential for the game rule description. They are needed for the actual implementation. To learn more, see the Specifications.

Move. The players alternate turns to take their move. On a playerʼs turn they can choose to do one of 3 things:

• Move to a legal adjacent square that is not blocked by a wall. If an adjacent square is occupied by another pawn, a player can jump over the pawn. If the square in the direction of the jump is accessible (i.e., not blocked by a wall and within the boundaries or the board), this is the only possible place where to jump to. If the square is inaccessible, a player can perform an L-shaped jump by following the direction to the pawn and then moving left or right of the pawn, provided the respective squares are accessible. See Figures 2a-c.
• If walls remain in storage, place one wall in a groove to impede their opponentʼs progress. Walls are not allowed to overlap each other. More importantly, access to the goal line for each player must always be left open. This means a player is not allowed to completely block off a player from reaching their goal line. See Figure 3.
• Stay on the current square (effectively a “pass”). This is only allowed if no other move (pawn or wall) is possible!

 

Four player game:

The rules are identical to two players, except the player order is now: Red, Blue, Green, Yellow and the players start in the middle of the bottom, top, left, and right side of the board, respectively. The corners squares are on the goal line for two players. Each player gets 5 walls in storage to begin with. Also, it is forbidden to jump over more than 1 opponent.

First, read the rules of the Quoridor game by Mirko Marchesi, published by Gigamic Games. Just like in most other board games, if played in person, the players take turns to perform their moves. We will play the game electronically.

You will implement a “student player” module that will contain code that will determine the next move for your player. We provide a “game engine” that calls the individual player functions when it is time to perform their moves. When called, your player module will specify which move to take and the engine will display it. You will not execute your player module – your code will be called by the engine and the move that you return to the engine will be displayed.

More specifics:

The game engine talks to your code through these functions:

• init, used to initialize your data structures,
• move, used to determine the next move for your player,
• last_move, used to inform your module about the moves that its opponents make, as well as its own, and
• player_invalidated, used to inform your module when an opponent makes an invalid move or times out and is therefore removed from the game.

There are two other functions that are used in the initial stages of the project (Part 1 of the project, see below). These functions are designed to help you get started with the project:

• get_neighbors: For a specified location on the board, your module computes all valid neighboring locations.
• get_shortest_path: For two specified locations on the board, your module reports a shortest path between the locations.

Execution flow:

Below is the sequence of function calls made by the game engine in a 2 player game.

step	function called	on which player	comments
1	init	player 1
2	init	player 2
3	move	player 1
4	last_move	player 1	player 1 updates its data structures with its move
5	last_move	player 2	player 2 updates its data structures with player 1′s move
6	move	player 2
7	last_move	player 1	player 1 updates its data structures with player 2′s move
8	last_move	player 2	player 2 updates its data structures with its move
Repeat steps 3-8 until the game is over.

Individual project parts:

We split the project into several parts to help you design and implement your code. The parts are roughly split as follows:

• Part 1: Design your data structures and find a shortest path between a given pair of locations. In subsequent parts of the project you might find this function helpful to get to your destination.
• Part 2: Play the game as a single player, alternately placing walls and moving your pawn.
• Part 3: Play the game against other player module(s).
• Part 4: Add strategy to beat the BeatMe player

More information about the individual parts will appear on this website throughout the quarter. Alternatively, feel free to follow the instructions in the provided code - see the download section.

Please use the link below to download the Quoridor game client, which you will use to play the game and implement your player code:

Quoridor Client v1.1.1 Download (ZIP)

Inside the ZIP file, you will find two folders: one for Python 3.2, and one for Python 3.3.  Find out which version of Python you have on your system, and then copy the contents of that folder to your eclipse workspace.

The code you need to modify is located in /StudentPlayers/RenameYourPlayer.  Remember to choose a unique name for your player!

Once you’ve downloaded these files and configured your workspace, you will need to get an API key before being able to use the web service.  We have a website that generates API keys for each student; for now please use bfaecec6fa4e1791c0. Paste this API key into config.txt, in the appropriate field near the top of the file.

Once you have downloaded and installed the game, and included your API key in the config.txt file, you can set the following parameters of the game in config.txt:

• Player modules: which player modules play the game (specify 1, 2, or 4 modules). Even though the official rules assume 2 or 4 players, we included a 1 player option for the first two parts of the project.
• Part 1: whether the game is supposed to behave as in part 1 of the project, where there is no move-making, merely path generation between two selected locations – click on a pair of squares and the computed path will be displayed on the screen.
• UI: whether the game is supposed to display graphically. In certain situations you might opt to forgo the graphical display for testing/debugging purposes.
• Auto play: gives you the option to manually step through the progress of the game.
• Animation speed: change it to speed up or slow down the game play.
• Logging: saving the log of a game into a file and/or printing it on standard output.
• Pre-moves: moves that happen before the beginning of the game. This is useful for debugging when you want to start with a predetermined sequence of moves. It is also used in Part 1 to place walls on the board. The pre-moves are in the PlayerMove constructor format as described in Model/interface.py.

Advanced:

• Number of walls: allows you to change the number of walls available for the players. This might be useful for debugging part 1, if you want to place more than 20 walls.
• Time limit: increase the time limit when debugging so that the game engine does not kick you out of the game.
• Part 1 autograde: disable it if you want to manually test shortest paths using the graphical interface. If autograding, the game engine tests all possible paths (a total of 81×81 paths), resulting in a slower execution of your code. Enable it to check how many paths you got right and disable it when manually debugging.

The Quoridor game engine uses a coordinate system to specify the location of a wall or a pawn.

Wall coordinates. The coordinate system for the walls is shown in the grey circled numbers on the left and above the board. For example, the blue wall next to the blue pawn runs from coordinate (1,6) to coordinate (3,6), and the yellow wall runs from coordinate (7,1) to coordinate (7,3). The wall coordinates are listed from left to right for horizontal walls and from top to bottom for vertical walls. As such, a wall from (r1,c1) to (r2,c2)  satisfies r1<=r2 and c1<=c2.

Pawn coordinates. The rows and the columns of the board are numbered 0 through 8, with (0,0) representing the top left corner. For example, the blue pawn is at location (2,5) and the yellow pawn is at (5,4).