You work with the given project zuulStart. This is yet another variant of the game of Zuul that is described in Chapter 6 of the module text book. This variant uses a dierent scenario. You will extend the project towards a more interesting game.
Note the dierence in class structure. There is a split between the classes Game and GameMain. The latter is the textual user interface of the game, the former is the actual game independent of any particular user interface (we could use it for example with a graphical user interface where commands are selected from menus). Note that the classes Game plus Room are not dependent on any other class. Furthermore, commands are structured rather dierently from the book, using inheritance. All knowledge about the command language is in the Parser. Start by familiarising yourself with the source les of the project.
Note that there are dependencies between the tasks given below, but it is possible to do some of them in a dierent order.
The assessment will be marked out of 100 and provisional marks have been associated with the individual components.
Make sure that you do not only write code, but that you also write or update appropriate comments for all classes and methods. Furthermore, you have to keep to the program style guide of the book. After marking out of 100 as indicated below, between 0% and 20% may be subtracted if you violate the style guide. In extreme cases even more than 20% can be subtracted.
Note that you have to submit the assessment before the deadline; there are no grace days.
The aim of the game shall be to reach the throne room. After the player has entered the throne room a congratulatory message shall be printed and the game ends.
All your changes will be in the Game class. You will need a new eld in the class. To implement the new functionality, make changes in the goRoom method.
Playing the game shall have a time limit. Do not use real time but instead count the number of go commands. The initial time limit shall be 12. If the goal has not been reached within the time limit, then the player loses. Losing means that a corresponding message is printed and the game ends.
Note that if in the last time step the player reaches the goal, then the player should win, not lose because time runs out.
Make only changes in the class Game and keep them minimal.
Add the command look to the commands that the game understands. The purpose of look is to print out the description of the room and the exits again (we look around the room). This could be helpful if we have entered a sequence of commands in a room so that the description has scrolled out of view and we cannot remember where the exits of the current room are.
You will have to make a small change in class Game, add a new class Look and modify the class Parser.
Currently directions used by the go command are just strings. Introduce a new enumeration class Direction, so that strings for directions are avoided as far as possible. Modify the Parser so that it translates a direction string into an object of class Direction. Modify all other classes so that they use Direction objects instead of strings.
An item has a description and a weight. In the following we assume that the description always is a single word and the weight a positive integer.
To simplify future extensions, write a new enumeration class Item. This class shall use parameterised values, like the command interface described in Section 6.13.2 of our text book. The class contains the description and weight. Its toString() method shall return the description and a getWeight() method the weight.
Dene three dierent Item objects with weights between 0 and 20. You can chose each item description and weight as you like.
Extend the Room class such that a room may hold any number of items. Add a method to add an item object and a method to remove an item object from a room. If the item is not in the room, then the remove method does not change the room contents but returns false. If the item was in the room, then it returns true.
Whenever a room is being entered, the room description shall include the list of items held in the room. Hence extend the class such that the getLongDescription method also lists all items held in the room.
Finally add at the three existing items to any rooms of your choice in the game.
The player shall be able to carry any number of items whose combined weight does not exceed a threshold of 30.
Add a method to the class Game for the player to take an Item object from the current room. If the current room does not hold the item, then the take method should return an appropriate message. If the item is too heavy for the player to take (considering the items they are already carrying), then the take method should return an appropriate message. If the take method is successful, then it removes the item from the room and returns an appropriate message. So overall the returned message either conrms the action or states why it could not be done.
Subsequently add a take command to the whole game. By entering the command take item the player takes item in the current room. Here item shall be the description of an item.
Similarly to the take command add a drop command to drop an item that the player currently carries in the current room. The implementation is slightly simpler, because the weight of items does not need to be checked.
Avoid any duplication of code amongst the implementations of take and drop.