Design and implement the following automatic players:

• Random, which enumerates all possible tile and meeple placements and then picks one randomly.
• Single Move, which enumerates all possible tile and meeple placements and picks the one that would yield the highest score on this turn, without considering the end-game scoring. If there are multiple such moves, it picks the one that places a meeple on the largest available city, road, or cloister (but not field).
• End Game, which enumerates all possible tile and meeple placements and picks the one that has the highest score, if the game were over right now, not considering any scores from the past. If there are multiple such moves, it picks the one that places a meeple on the largest available field.

Run a tournament to find out how these strategies perform. Which one is the best?

Build a stress test for your rules infrastructure that registers random players and plays games with them. Do this over and over (all night long, say) and check for errors (in the morning). Hint: print out the random seed before each run so you can reproduce any bugs that you find. And, of course, when you find a bug, turn it into a test case first, before fixing it.

---

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 only testing your player -- if you find mistakes in your board or move checking logic, add a test case there.
• To build a test case, construct a board and pick a tile that you know should make the player behave in a certain manner. Then, call the players doMove 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; that does not make it easier to read.)