# Welcome to Battle Royale!

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

# Quoridor Game Rules

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:

Figure 1: Initial board configuration with two players.

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!

Figure 2a: Legal pawn moves for the red player are shown in pink.

Figure 2b: Legal pawn moves for the red player are shown in pink. The player has two adjacent squares to move to, as well as a straight jump across the blue pawn.

Figure 2c: Legal pawn moves for the red player are shown in pink. The player can perform an L-shaped jump over the blue pawn, since there is a wall blocking the red player from jumping straight across the blue pawn.

Figure 3: Attempting to block off the opponent: The blue player is attempting to place the wall indicated by the arrow. This wall placement is illegal as it blocks the red player from its goal line.

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.

Figure 4: A four player game in progress.

# Student player: Project overview

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

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.

# Configuring the game: config.txt

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.