In this assignment, you will implement an ADT for a hexagonal coordinate system for creating games that operate on hexagon-tile boards. You will also implement a simple “enumerated class” for various kinds of terrains.
For this homework, you are creating an immutable data type to represent hexagon coordinates. Each coordinate represents the center of a hexagon in a tiling of the plane:
Each hexagon has three coordinates: the first increases as you go to the right (and down), the second as you go down, the third as you go right (and up). In the electronic version of this document, you can see that a band of hexagons with first coordinate equal to two have been highlighted in yellow. If you have a paper copy of this document, we recommend that you highlight in three contrasting colors bands of hexagons with the same coordinate equal to two. (There are a number of different hexagonal grids used in practice; I found several on the web. You may use code or ideas from the web, but you must give credit, including a URL, in your homework, and should be careful that the code will actually work.)
The third coordinate can always be computed from the other two1 (how?) and so we often use just the first two numbers to create a coordinate. Two hexagonal coordinates are equal exactly when they have the same numbers in the same order.
The “distance” from one hex coordinate is the minimum number of moves to adjacent hexagons needed to get from one to another. Thus the distance from to is two, and the distance from to is three. The distance from any hex coordinate to itself is zero. As it happens, the shortest path only requires travel along two of the three “dimensions”, and thus you can compute the minimum distance by testing each possible pair of dimensions and choosing the shortest. For example, assuming we use “a”, “b”, and “c” for our three coordinates, then to compute the shortest path from to , we can try all three pairs of dimensions to travel on:
In order to render a hexagon in a Java graphics context, we have to decide how big the hexagons are going to be. This might change and so we use a “width” parameter. For those of you who don't recall your hexagonal geometry, here's a helpful diagram (not quite to scale) of a hexagon with “width” = :
Once you figure out how to create the Polygon for the hexagon at the hex coordinate , you need to see how much the points should shift for other coordinate. The first coordinate is easy; it shifts the hexagon right (increasing ) by . The second is trickier since it shifts the hexagon down (increasing ) by and back to the left (decreasing ) by .
In all, you must implement the following methods:
The following methods do not have stubs in the skeleton; you will need to write them from scratch:
Note: AWT Point and Polygon objects use integers, not floats. The supplied test files require that calculated values be clamped to the nearest integer so that the value 3.4 becomes 3, and the value -2.6 becomes -3. If many of your test cases initially fail with many values off by one, this may be the reason.
Java has “enumeated types.” Please consult the Oracle documentation for information on how to declare an enumerated type.
Implement a terrain enumerated type where each terrain is associated with a color:
getColoraccessor to get the associated color for a terrain.
In the code that you write for CS 351, you must follow some guidelines:
clone()) should be annotated
We provide two JUnit test suites TestHexCoordinate.java and TestTerrain as well as a sample driver program Main.java. Do not modify them. Ensure that your project passes all tests and that the driver program displays something reasonable before submission.
We use “git” to access and turn in programs. Follow the instructions given in the lab to clone your homework repository onto your own or lab computer. Make sure you always push changes back (commit is insufficient) before switching computers and before the deadline.
Your task is to write the following files:
About this document