Design and implement the following strategies as additional players:

• PlayInitialWord [5pts]: this player only plays when there are no tiles on the board. It searches the dictionary for all words that it can form with its tiles and then places the one with the highest value on the initial square. Otherwise, it passes.

• PlayGoodWord [4pts]: the player finds all of the complete words in its tiles. Then, it searches all of the squares in the board to see if any of the words fit on a square. It then plays the word that scores the most points.

  This player can be improved in several ways. For example, it might use the contents of the board to search for words that it could not otherwise form (eg, if there an “a” on the board and only a “c” and a “t” are on the rack, the strategy above would not find “cat”, “act”, “ca”, “at”, or “ta”.)

  These improvements are not necessary.

Some hints on testing:

• Separate out pieces of the player's functionality as library routines and test these individually (ie, computing permutations and finding playable locations for a word).
• Build your tests as you build your players. That is, develop a test for a player. Run it (it fails). Write the code to make that test pass. Re-run the test (and debug until it passes). Repeat.
• To build a test case, construct racks and boards and (small) dictionaries that you know should make the player behave in a certain manner.
• Build many of these, 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, once you have your tests in place.

Run a tournament to find out how these strategies perform. Does going first matter? [1pt]