This project is due on 10/13 at midnight.
Submission Directory: project07 in your pair’s GitHub repository.
Your task is to design and implement an automated Acquire player. The player’s interface must accommodate all phases of an Acquire game. In addition, you must parametrize the player component over a strategy that chooses where to place tiles and which shares to buy. Your solution must include two distinct strategies:
an ordered strategy, which picks the "smallest" tile that can be placed on the board and buys as many shares in hotels possible in alphabetical order
a random strategy, which randomly chooses a tile from the player’s pool and buys a random number of shares (aka stock certificates) for random hotels. Both requests must satisfy the rules of the game.
The smallest tile is tile with the smallest row. If two tiles have the same row, the smallest tile is the one with the smallest column.
Your second task is to implement and deliver a test harness, dubbed player-tester that responds to requests in the form of XML elements with responses. It should come with a subfolder, player-tests, with up to three test cases specified as a pair of files: inN.xml and outN.xml for N = 0, ..., 2. Each test case that exposes a flaw in some other code base gets you a bonus point. A test case that does not pass my reference implementation means a loss of one point.
The test harness must deal with one kind of request. Each grammatically correct and valid request receives an Action response; for others, the test harness issues an Error response.
Turn = <take-turn> Player Board Tile ... Share ... XHotel ... </take-turn> Player = <player cash=Cash>Share ...</player>
Action = <action Win> Place</action> <action Win hotel1 = Label> Place</action> <action Win hotel1 = Label hotel2 = Label> Place</action> <action Win hotel1 = Label hotel2 = Label hotel3 = Label> Place</action> <action Win hotel1 = Label /> <action Win hotel1 = Label hotel2 = Label /> <action Win hotel1 = Label hotel2 = Label hotel3 = Label /> Place = <place row=Row column=Column> </place> | <place row=Row column=Column hotel=Label> </place> Error = <error msg=String /> Win = win = "yes" |
Board = <board> Tile ... Hotel ... </board> Hotel = <hotel name=Label>Tile Tile Tile ...</hotel> XHotel = <hotel label=Label /> Tile = <tile column=Column row=Row /> Share = <share name=Label count=Nat /> Label = "American" | ... | "Worldwide" Row = "A" | ... | "I" Column = "1" | ... | "12" Cash = String, interpretable as a natural number (non-negative integer) Nat = String, interpretable as a natural number less than 26 NN = String, 20 chars or less
A request informs the automated player of the complete state as far as the player is concerned: the current state of the board, its available tiles, its available shares, and the available hotel labels (unallocated hotels). Think of it as a request to the player to take its turn.
The player’s response to a request is the actions it wishes to take. An action specifies two distinct forms of information:
where the player wishes to place tile and, if needed, which hotel is involved;
the hotels the player wishes to buy, if any.
If the player cannot place a tile, it omits the Place part of the
response. The meaning of such an action is that the game has reached an
unlikely (but not impossible) situation. Since we do not know yet how to
resolve such a situation, the player signals the problem—