AI player for Risk Project Requirements
Dirk Brand, 16077229 July 16, 2013
The project involves designing and implementing a computer player (AI) for Risk, as well as a game framework for Risk.
Wolf [?] used various techniques in the design of his AI player for Risk. He also did a thorough analysis of the complexity of Risk by measuring test runs of the real game. He developed sophisticated evaluation functions to evaluate the game state at any given time. The evaluation function coupled with a game tree search approach formed the basis for his AI player. This project will make use of the approaches described by Wolf. Franz Hahn investigated heuristics with the goal to eventually develop an adaptive artiﬁcial player for Risk [?]. His heuristics may be useful for the design of a benchmark computer player that generates legal moves based on simple rules. The heuristics may also prove useful for ordering moves and providing more accurate play-out results in a Monte Carlo Tree Search [?] based player. Yura [?] has done a similar project as this project, where he created java based Risk game, a map editor with a simple format for maps (to allow users to add their maps to the game), multiplayer playing and single player playing. His map format has a simple design that the maps used in this project could be based his. He also has an archive of maps that could then be used for testing the framework. His artiﬁcial intelligence players implement an interface that could be used to base the structure of the AI players for this project on. For testing purposes, the AI players implemented in this project could then be inserted into the back-end of his program and compared against his current AI players. Risk Rules This project will be based on a simpliﬁed form of the rules of the original Risk game, as detailed in Appendix A.
A framework must be developed that must consist of the following components: • A controller. • A graphical user interface (GUI) for human players. • Both an engine that acts as a back-end for the GUI, as well as an artiﬁcial intelligence based engine. • A communication protocol that facilitates communications between the components.
The framework structure will be based on a model described in the Go Text Protocol (GTP) [?]. The structure is described as a controller-engine model where there is a central controller that communicates with the engines (either the AI player or the human Player) via a communication protocol. An example of the controller-engine relationship is illustrated below: Controller
The protocol consists of request and reply messages. The controller will send all request messages and the engines the reply messages. There will be no direct communication between the engines and engines cannot send requests to the controller.
The framework must allow bidirectional communication between the controller and the engines (requests from the controller and replies from the engines). Sending 10 arbitrary messages from the controller to the engine and vice versa and verifying the messages arrive correctly. The communication protocol must be asynchronous, i.e. a requests may be sent before the previous request has been replied to by the receiving party. Send multiple request from the controller to an engine and hold the replies until all requests have arrived. Then send the replies in the same order and verify that the replies are received correctly. 2
The communication protocol must allow for the following actions: • A command from the controller to an engine to set the game state. • A command from the controller to an engine requesting a list of army placements (during the recruitment phase), and the relevant reply command from the engine. • A command from the controller to an engine requesting a source and destination of an attack action (during the battle phase), and the relevant reply command from the engine. • A command from the controller to an engine requesting a source and destination for a manoeuvre action (during the manoeuvre phase), and the relevant reply command from the engine.
Verify that all the commands are implemented by sending the commands from the controller and verifying the replies from the engines (in the case of requests).
The controller facilitates the game playing by connecting to the engines and sending requests according to the communication protocol. The controller must manage a game state that should contain the following: • The current phase of the game. • The name of the player currently playing a turn. • The number of troops per player. • The distribution of the troops per territory per player. • The current cards held by each player respectively. • Any other relevant information. The controller must also keep a representation of the world map. The controller must satisfy the following requirements: R04: The controller must implement the controller parts of the communication protocol.
Verify that all the requirements of the communication protocol, as applicable on the controller, are met. The controller must be able to connect to the engines. Initiate a connection from the controller to an engine and verify that the engine receives and accepts the request, and creates a valid connection. The controller must communicate changes in the game state (due to a player taking actions) to the other player. See test scenario. The controller must accept a map speciﬁcation in text format and be able to store the map with the required map representation. Create ﬁve text ﬁles representing real maps (World map, Roman Empire map, United Kingdom map, German Empire map, Middle Earth map [?]) and verify that the controller stores and represents the maps correctly.
R06: Veriﬁcation: R07: Veriﬁcation:
The requirements that follow are applicable on both the engine for human players and the engine for computer players. The computer engine speciﬁcally must store the game state eﬃciently (hashing should be investigated). R08: Veriﬁcation: The engines must implement the engine parts of the communication protocol. Verify that all the requirements of the communication protocol, as applicable on the engines, are met. The engines must accept a valid connection request from the controller. Attempt to establish a connection to and engine from the controller and verify that the engine accepts the connection request and a valid connection is created. The engine for human players must have a graphical user interface that satisﬁes all the requirements listed in the User Interface section below.
Verify that all the requirements regarding the user interface are satisﬁed.
The framework must have a graphical user interface (GUI) for the human player engine. This interface must allow players to interact with the engine and to view information relayed via the controller to the engine. The requirements for the interface are listed below. R11: The GUI must display and update the game state (as managed by the controller) in response to actions taken by other users. Only the following aspects should be visible to the user: • The current phase of the game and which player is currently playing their turn. • The troop distribution of both players per territory. • The cards held by the player (not that of the opponent). • Any other relevant information that should be made known to a player (excluding conﬁdential information about the other player). Veriﬁcation: Verify that the listed aspects of the game state are visible to the user. The interface must allow the user to upload map ﬁles that will be used in a game. Upload the map ﬁles listed in R07 and conﬁrm that the maps are displaying correctly. Display an error message if a user attempts to upload a map that is not correctly formatted. Before commencement of the game, the interface must allow the user to select a computer opponent or another human opponent to play against. See test scenario. Before commencement of the game, the interface must allow the user to select a map to play on.
R12: Veriﬁcation: Error:
Veriﬁcation: R15: Veriﬁcation: R16:
See test scenario. The interface must display the map. See test scenario. During the setup phase as well as the recruitment phase, the interface must allow players to specify on which territory they wish to place armies. See test scenario. Display an error message if an invalid territory is selected (territory that does not belong to the opponent). During the battle phase, the interface must allow players to select the territory they wish to attack as well as the territory they wish to attack from. The interface must only allow a player to select the attacking territory from territories that they own and a territory to attack from territories that belong to their opponent. See test scenario. Display an error message if a user selects two territories that are not adjacent. During the manoeuvre phase, the interface must allow a player to select the territories that they want to manoeuvre to and from. The interface must only allow a player to select territories that they own. See test scenario. Display an error message if a user selects two territories that are not connected by some path of territories that they own.
R19: The controller should have logging functionality that produces a log at the end of a game with data about the game state throughout the game, data about the players and also the result of the game. A player should be able to successfully reproduce a game (on a physical Risk board) from the data in the log alone. Play a game according to test scenario and verify that the game can be successfully reproduced.
For testing purposes, a test scenario is outlined below that utilises all the major features of the framework. 1. Start the controller. 2. Select the submissive AI player as opponent and the World Map as playing map. Verify that these selection options are available and that the controller recognises the selections. 3. Start a game. Verify that either you or the opponent is shown as the starting player. Verify that the map is visible. 4. Starting territories will be allocated randomly. In an iterative way, select a territory that you own and place three armies from your available armies pool. Repeat until the pool is empty. Verify that territories can be selected for placement and that the placement of armies on territories is correctly displayed on the interface. 5. Play your ﬁrst turn or wait for the AI to play its ﬁrst turn. Verify that all the relevant aspects of the game state is visible as listed in the user interface section. 6. During the recruitment phase, place all recruited armies on any single territory adjacent to an enemy territory. 7. During the battle phase, attack from that territory until the territory contains no more armies. If an enemy territory is defeated, continue attacking adjacent territories. Verify that repeated attacks from a single territory can be done. 8. During the manoeuvre phase, select any territory you own and a connected territory (via a path of territories that you own) as the source and destination and manoeuvre the maximum number of troops available from the source to the destination. 9. Repeat steps 5 to 8 until either player is eliminated from the board. Verify that all actions (army placement, territories selected for battle and territories selected for manoeuvre) taken by the opponent is updated and shown on the user interface. When a game is created, verify that the correct error message is displayed when an invalid map ﬁle is provided. During the recruitment, battle and manoeuvre phases, purposefully select invalid territories and verify that the correct error messages are displayed.
Two computer players must be investigated and developed according to the following game tree search approaches: expectiminimax with alpha-beta pruning [?] and Monte Carlo Tree Search (MCTS) [?]. For testing purposes, a submissive player that may only defend, should be developed, as well as a baseline player that plays legal moves based on a simple scheme. Heuristics and evaluation techniques based on previous work ([?], [?]) must be investigated and used in both the expectiminimax player and the MCTS player. R20: Veriﬁcation: The baseline player should only play legal moves. Automate the playing of games between the submissive player and the baseline player and verify that the baseline player plays no illegal moves. If an illegal move is played, verify that the correct error message is displayed. A computer player based on expectiminimax with alpha-beta pruning must be developed. Verify that the player has been created and can successfully play a game against the baseline player. If Monte Carlo Tree Search proves to be a viable option, a computer player based thereon must be developed. Heuristics for move ordering and evaluation function techniques should be investigated to improve the MCTS player. If investigation into a MCTS player proves it to be an ineﬀective approach for an AI for Risk, a report will be generated. Otherwise, verify that the player has been created and can successfully play a game against the baseline player.
The quality of the expectiminimax player and the MCTS player can be evaluated and compared using the evaluation plan.
Appendix A - Rule Limitations
The rules for the original Risk game can be found online at http://www.hasbro. com/common/instruct/risk.pdf. The game will be limited to two players playing the world-domination scenario where the game ends when one player controls the world (i.e. one player has been completely eliminated from the game). A player’s turn will consist of three distinct phases. These phases are 1. Recruit troops phase. 2. Battle phase (with Attack phase). 3. Manoeuvre troops phase. The variation from the original rules are described below. Initial Setup In the two player world domination game of the original risk board game, the game is set up by ﬁrst allocating the two players their starting territories randomly, as well as for a third neutral player (that may only defend and not attack). For the scope of this project, all the territories will be randomly allocated to only the two players playing the game (there will be no neutral player). The players (including the AI player) then each receive a pool of sixty armies. They then proceed to place these armies in a turn-based way on their respective territories. All territories are allocated the minimum of one troop by default. Recruit Troops Phase Although various card trading system exist for Risk, the trading card system used in the framework will be limited to the system based on sets of three cards. In the original version of Risk, players could trade combinations of their cards in for armies and were forced to trade in a set when they had ﬁve or six cards. Every time a set is traded, the number of armies obtained from the trade increases (ﬁrst set is worth 4 armies, second set is worth 6 armies, etc.). For the scope of this project, players will by default trade when they have a set that can be traded. If they have two diﬀerent sets that could be traded, one is picked at random. The number of armies obtained from the trades will increase in the same way as in the original game. Battle In the battle phase the player has the choice of where they want to initiate an attack. In the original version of Risk, the attacking player could choose to attack with any number of armies between one and three. It was proven by Wolf [?] that a player that attacks or defends with the maximum number of armies possible, has the highest winning probability. Thus, for the scope of this project, both the human and computer players will by default always attack and defend with the maximum permitted number of armies.