A. Treasure Hunter is a simple game in which the player controls a character, who walks around a field of grass and rocks trying to find randomly-placed treasure.
B.
- As the player, we are able to use the arrow keys in order to move around the field.
- As the player, I can collect all of the treasures to win the game.
C. The game successfully runs. When the game is loaded, the player is immediately thrown into the field of treasure. There are no errors thrown (i.e. something that crashes the game) when playing the game, however the “Treasure Found” pop-up lingers for too long (does not seem to be deliberate since it makes it feel broken), the keyboard-input detection is poor, and the character is able to walk through rocks while the “Treasure Found” message is on screen.
D.
- As a player, I should be able to press buttons on a menu screen to start the game (or go into the settings or view a list of the controls).
- As a player, I should be able to press a button to trigger a pause screen.
- If we add enemies (snakes for example): as a snake, I should be able to track a player and trigger a losing-condition upon contact.
E. The current README is detailed and informative. There is information about the game and each Java class that makes up the game. The image links are broken, so fixing those images may help future users visualize what is going on. The final remarks also give suggestions about what future generations can work on to make the game better. In general, we think having a formal version history can help future generations understand what was done in each version of the game, and this can help future generations understand why some decisions were made.
F. The build.xml file works, and everything is readable. All targets have descriptions, so the build.xml file is of good quality.
G. There are many issues in the game ranging from needing a main menu and a timer to improving game mechanics (e.g. movement). In addition, we can change the code to use the libGDX library, improve the Javadoc, and fix collision-detection bugs. Overall, there are enough issues that we can earn 1000 points. The issues clearly show what is expected.
H.
I.
-
Every object/element in the game has its own class. Each object (player, rock, game message) has its behavior and aspects defined in their respective class. The GUI code incorporates each of these classes and handles how each class interacts with each other. Each class’ purpose and their behavior is clear: the code is readable and there is good documentation about what each method does. It is easy to see how these different classes interact with each other.
-
The GameComponent object creates the field for the game by drawing the different tiles (grass, bush, rock), as dictated by a text file, and randomly placing the treasures. This class also checks the player’s movements to see if the player is allowed to move in the direction indicated by the user and then animates the movement if it is allowed. Moreover, GameComponent also checks if a treasure is found and prompts the message that pops up after a treasure is found. It also checks for the win-condition (all treasures being found) to indicate when the game is over. The GameComponent is contained within the GameGUI class, which takes care of the actions that are performed when user input is detected, and makes sure that no errors (such as going out of bounds of the screen) occurs.
J.
-
There are several JUnit tests, but the general test coverage is poor. The only things that are tested are basic elements of the game (player construction, testing the still frame of the player, setting tiles, getting x- and y-positions). However, this is due to the fact that it is much easier to test edge cases by actually running the game and trying different things out (and trying to recreate bugs if they occur).
-
There is ample opportunity for expanding the tests. For example, we can test collision-detection or game message handling. We can go about these tests by writing a test that simulates player inputs (e.g. purposely walking into rocks, or at the edge of the board) and see how the game responds, and where the player ends up after these movements.