Design an interface (using whatever the most suitable construct in your programming language of choice is) that represents players. It should have the following operations:

    get-name       ;; -> string
    ;; Returns the players name

    initialize     ;; color? (listof color?) -> void?
    ;; Called to indicate a game is starting.
    ;; The first argument is the player's color
    ;; and the second is all of the players'
    ;; colors, in the order that the game will be played.

    place-pawn     ;; board? -> pawn-loc?
    ;; Called at the first step in a game; indicates where
    ;; the player wishes to place their pawn. The pawn must
    ;; be placed along the edge in an unoccupied space.

    play-turn      ;; board? (set/c tile?) natural? -> tile?
    ;; Called to ask the player to make a move. The tiles
    ;; are the ones the player has, the number is the
    ;; count of tiles that are not yet handed out to players.
    ;; The result is the tile the player should place,
    ;; suitably rotated.

    end-game       ;; board? (set/c color?) -> void?
    ;; Called to inform the player of the final board
    ;; state and which players won the game.

The board, tile, pawn-loc, and color data definitions are yours to define as you see fit, but they must conform to some guidelines. The board should describe where the tiles are, and what orientation they are in. The board should also describe where each pawn is and what color it is. The pawn location should describe where a pawn is on the board and the possible colors are blue, red, green, orange, sienna, hotpink, darkgreen, and purple. The tile is never a dragon tile; it covers only tiles that can actually be played.

---

Design and implement the following strategies as automatic players that implement the interface above:

• Random: This player picks randomly from all of the legal moves.

• LeastSymmetric: This player sorts the possible moves by how symmetric each tile is (from most symmetric to least symmetric), and picks the first legal one.

• MostSymmetric: This player also sorts the possible moves by how symmetric each tile is but in the opposite order from the LeastSymmetric player. It also picks the first legal move.

The amount of symmetry in a tile is the number of different ways it can be placed. For example, the first tile in the tile list has only one way to be placed (in a given spot), no matter how it is rotated, the pathways are all the same. The last tile, in constrast has four different ways it might be placed, as all four rotations produce different pathways across the tile.

Run a tournament to find out how these strategies perform. Is there a clear winning strategy? Is there a total ordering of the three strategies?

---

Some hints on testing:

• Separate out pieces of the player's functionality as library routines and test these individually.
• Build your tests as you build your players. That is, find some small piece of the player that you can implement. Implement and test that one piece (or, if you prefer, write test cases and then implement them) before moving on to the next one. Of course, that means that you have to have some idea of the overall shape before you begin.
• Keep in mind that you are testing only your player -- if you find mistakes in your board or move checking logic, add a test case there, not in your player.
• To build a test case, construct a board and a set of tiles that you know should make the player behave in a certain manner. Then, call the players play-turn method and see if the moves produced matched what it should have done in that situation.
• Build many such test cases, starting with very simple ones and building up to more and more complex ones, with the goal of covering every different logical aspect of the player’s behavior.
• Automatically test if the player fails. Only use printouts for debugging -- remove them when the tests pass! (In general, don't leave junk like commented out code or printouts in your code.)