Introduction
，。：
Board.javaflood：inside map。inside map，，，inside map。。
Board.javaflood1：inside map。inside map，，，inside map。inside map，。
Board.javafullyFlooded：outside map，
Board.javasuggest：，。
Requirement
Flood It
“Flood It” is a coloring game played on a square board of colored tiles. At each move, the player selects a color (by just clicking on one of the tiles) and the tile in the upper left corner, as well as all connected neighboring tiles of the same color, are changed to the selected color. The objective of the game is end up with all the tiles being the same color while minimizing the number of moves.
If you haven’t played “Flood It” before, please spend some time playing the game so that you can develop an intuition for how it works and formulate strategies for game play before trying to implement anything. There is an online version at (Links to an external site.).
Code Base
Download the following starter code and import it into a new Java Project (named p2) in Eclipse: p2-starter.zip
Here is a summary of the components in the code base. You will implement missing or incomplete methods in Coord and Board, and create a unit test in Testing. The methods in Coord and Board that you need to work on are marked with TODO comments. You should definitely read through all the classes to understand how things fit together. Notice that the support classes provide a main() method for simple testing. Feel free to add your own experiments as you work to understand the code.
WaterColor [read-only] is an enumerated type representing the subset of colors that are used in the game.
Constants [read-only] is an interface containing various project constants.
Tile [read-only] is a class that represents one of the tiles on the game board. Each tile has a position and a color. A tile is the neighbor of another tile if it to the north, south, east, or west of that tile. (An interesting variation of the game could also include the neighbors along the diagonals, but that would be a different game.) The neighbor relationship is constrained to tiles on a finite board. Thus, tiles along the left edge do not have neighbors to the west.
Coord is a class that represents a position as an (x, y)-coordinate. A coordinate knows how to retrieve its neighboring coordinates on a board. Because we wish to use Coord objects as keys in a HashMap, it’s important for this class to override hashCode() with something that makes sense for coordinates.
Board is a class that holds the state of a game. Most of the work you need to do is in this class.
Game [read-only] is the main controller for the project. It can run an interactive game, or it can run a large number of game simulations, collecting timing statistics as it goes, and displaying the results in a graph. Run this class as an application and a game board will be displayed in a window. The player’s moves are ineffective until you implement the missing Board.flood() method.
GUI [read-only] is used by the game to present a view of the interactive game to the user.
TimingGraph [read-only] is used by the game to display the runtime statistics of the game simulations.
Testing is a minimal JUnit class that you can use as a starting point for building your unit test for this project. You are to create a comprehensive battery of tests for each of the TODO methods you implement for this project. Please take this part of the project seriously and create quality tests. Don’t wait until the last minute to do this. Write your tests early so that you can use them as you debug. (Don’t forget to add JUnit 4 to the build path: Select File > Properties. On the Libraries tab, press Add Library, and then select JUnit.)
Current Flooded Region
The main data structure that the methods in a Board manipulate is the current flooded region. This is the region of the board that starts from the upper left corner and recursively includes all neighbors of the same color. In the Board class, the current flooded region is represented by a java.util.HashMap and stored in the data member named inside. We instantiate the generic HashMap to specify that the keys are of type Coord and the values are of type Tile.
In more detail, the methods in Board that you are to implement are:
flood() takes a new color for the upper left tile. All the tiles in the current flooded region are updated with the new color. Additionally, all adjacent regions of the same color are absorbed into the current flooded region. It is important that this method be fast so that there is no perceptible delay in updating the game board for the player. Consider developing several variations of this method, naming the variations flood1(), flood2(), and so on. The game will run time trials of all your flood variations and plot the results together on the graph. This will help you to select the best approach for flood().
suggest() takes no arguments and returns the “best” color for the next move in the game. Replace the currently implemented strategy for calculating the best move with something more intelligent. Be sure to provide a clear high-level description of your strategy in this method’s comment and argue why it is the best strategy for playing the game.
Analysis
After implementing and debugging your flood() function, edit Game.main() to uncomment the statement to run a batchTest(). This produces a graph of the execution time (along the y-axis) versus the size of the board (along the x-axis).
To the left is an example graph. The red “curve” shows the timings of 30 games (played on boards of sizes 1 through 30, inclusive), where the game logic uses Board.flood() to process each move. The two gray curves show the results of running games that call Board.flood1() and Board.flood2() instead. These empirical results suggest that I’d probably be better off swapping Board.flood() with the version corresponding to the lower gray curve, so that’s what I’ve done.
Look at your graph and speculate as what function (roughly) fits the curve. Possibilities to think about include f(n) = n, f(n) = n2, and f(n) = n log n. If your curve is very steep, then your game will be too unresponsive for the player to tolerate, so keep working until you figure out a fast flood function.
If your code is so slow that no graph is produced when running batchTests(), try temporarily reducing the value of Constants.MAX_BOARD_SIZE_FOR_AUTOPLAY. For each board size, the game is repeated 5 times to reduce the effect of noise. Turning down the Constants.NUM_GAMES_TO_AUTOPLAY parameter may save you time during development.
In addition to displaying the graph in a window, batchTests() saves it as an image to the file results.png.