Albert Vaca Omer Giménez Jordi Petit Salvador Roura
In this game, each player has control over an army of knights and farmers in a tile-based board.
The goal of the game is to "farm" as many tiles as you can, converting them to your team color. Your score at a given time is the number of tiles of your color at that point, and the winner is the player who has more tiles of his color at the end of the game.
At the beginning of the game, all the knights and farmers of a player are randomly placed at the spawn point of that player: one of the four quadrants of the board.
Each round the players can move each unit one position in one of the 4 cardinal directions.
Moving a farmer to an empty tile will convert the tile to the farmer’s team color, even if it already has the color of a different team. Moving a farmer to an non-empty tile is an invalid move.
Moving a knight to a tile occupied by another player’s unit will make it attack that unit, performing a random amount of damage. If the health of a unit drops to less or equal than zero, that unit will be converted to the attacking player’s team and will respawn at his spawn quadrant with full health. (When this happens, the players can say out loud: Wololo!)
Deliberately not moving a unit will increase its health by a given constant. A unit cannot recover more health than its initial amount. Performing an invalid move will result in that unit not moving, but will not regenerate health.
The boards will have "walls", obstacles that units cannot go through. Trying to move a unit into a wall is an invalid move.
Other invalid moves are moving a farmer to a tile occupied by another unit, or moving a knight to a tile occupied by a unit of the same team.
If the board does not have walls all around, moving out of the board will make a unit wrap to the opposite side.
The order of the actions performed by players is chosen at random, so you cannot expect any execution order of your actions. A notable case is when two units try to move to the same tile: the unit that happens to move first will be able to occupy the tile, while the second one will not.
A game is defined by a board and the following set of parameters:
The first thing you should do is download the source code.
The source code includes a C++ program that runs the games and an HTML viewer to watch them in a nice animated format. Also, a ”demo” player is provided to make it easier to start coding your own player.
Here we will explain how to run the game under Linux, but it should work under Windows, Mac, FreeBSD, OpenSolaris... You will only need g++ and make installed on your system, plus a modern browser like Mozilla Firefox or Chromium.
./Game Demo Demo Demo Demo < maze.cnf > game.br
Here, we are starting a match with 4 instances of the player ”Demo” (included with the source code), in the board defined in ”maze.cnf”. The output of this match will be redirected to ”game.br”.
Use ./Game --help to see a list of parameters you can use. Particularly useful is ./Game --list, that will show a list with all the recognized player names.
If needed, remember you can run make clean to delete the executable and object files and start over the build.
To create a player copy the file AINull.cc or AIDemo.cc to a new file with the same name format (AIWhatever.cc).
Then, edit the file you just created and change the
line to your own player name. The name you choose for your player must be unique, non-offensive and less than 12 letters long. This name will be shown in the website and in the matches.
Then you can start implementing the virtual method play(), inherited from the base class Player. This method will be called every round and is where your player should decide what to do, and do it.
Of course, you can define auxiliary methods and variables inside your player class, but the entry point of your code will always be this play() method.
From your player class you can also call functions to access the board state (defined in the Board class in Board.hh) and to command your units (defined in the Action class in Action.hh). Those functions are made available to your code using inheritance, but do not tell your Software Engineering teachers because they might not like it. The documentation about the available functions can be found both in the header files of the above mentioned classes (and also PosDir.hh), and as a PDF you can download from the game website.
Note that you should not edit the factory() method from your player class, nor the last line that adds your player to the list of available players.
When you think your player is strong enough to enter the competition, you should submit it to the Jutge. Since it will run in a secure environment to prevent cheating, some restrictions apply to your code: