Written Exercise 1: Imagine you would like to allow rooms to have a new type of exit (e.g. "up"). Identify each class and method that you would have to change in order to allow for this type of exit. Briefly describe the changes you would make in each class and method that you identified. NOTE: Do not actually make these changes yet!
Several methods in the Game class contain repeated functionality. Specifically, the printWelcome method and the goRoom methods both print a description of the current room and a list of the exits. As we have learned, having the same functionality implemented in multiple locations can lead to the introduction of errors when software is modified. Correct this problem by factoring the common functionality out of these methods into a method of its own. Then call this new method each place the description and exits are to be displayed.
Currently the code that generates and displays the list of exits from a room is contained in the Game class. This is not a particularly good design. Each room in the game is represented by a Room object. The Room object contains fields that store the information about that room's exits. Therefore, it should seem like this program would be better if the code to generate a list of the exits for a room would be contained in the Room class. Make this improvement by adding a method named getExitString to the Room class. This method should return a String listing the exits from the room. For example, if the room has exits to the north and west, this method should return a String containing: "north west".
Now that each Room is capable of generating a list of its own exits. Refactor the code in the Game class to take advantage of this functionality. I.e. anywhere the Game class generates a list of the exits from the current room, change it to use your getExitString method.
Written Exercise 2: After making the above improvements to the code, imagine again that you would like to allow rooms to have a new type of exit (e.g. "up"). Now identify each class and method that you would have to change in order to add the new type of exit. Has the design improved? Why or why not? NOTE: Do not actually make these changes at this stage!
Currently, the Game class generates the full description of the current room (including information about exits) and displays it. This is dealing with data of the Room class, so the Room class should be responsible for generating this description. Add a method called getLongDescription to the Room class that returns a String containing the description and exits of a room, and refactor the Game class to use it whenever the Game needs to print information about a Room.
Design your own text-based adventure game, using the given zuul game as a starting point. Some possible game scenarios are described in Exercise 6.3 of the text and you will have others from your brainstorming activity. If you find it difficult to visualize this sort of game scenario, try modeling your game on some familiar real-world location. If you need additional inspiration, you can try playing the original Colossal Cave Adventure game.
Some additional specifications:
Written Exercise 3: Write a brief description of your game, including the setting for the game, the items in the game, and how a player wins. Save this in a Word doc to be submitted with your assignment.
Written Exercise 4: Draw a map for your game scenario. Label the rooms and the exits (connections between rooms), and specify the locations of the items. The map can be hand-drawn - you do not need to use a drawing program. This map must also be placed in the Word doc.
Update the comments at the beginning of the Game class and the message displayed by the printWelcome method so that they describe your game.
Change the createRoomsAndPlayer method in the Game class so that it creates the rooms and exits that you invented for your game. You do not need to add any items to your game yet. You will add items later.
Update the test methods in the GameTest class as necessary to account for your changes to the Game class. You can directly edit the code in the test class, or delete any test methods that do not pass and re-record them. Play the game for a bit - enjoy the fruits of your hard work!
In many games (perhaps even in yours) there may be a very large number of different types of exits (e.g. "up", "down", "window", "slide", "stairway", "trapdoor", "trampoline", "fire-pole" etc...) One way to support such exits would be to make the changes that you identified in Written Exercise 2 for each imaginable type of exit. This is clearly better than it would have been before you completed Part II, but it is still not ideal. It would be better if it were possible for an exit to have any arbitrary name and that when given the name of an exit we could find the associated Room that lies beyond. This should sound like a good job for a HashMap where the name of an exit is the key and the Room lying beyond the exit is the value. Improve the design of the Room class by refactoring it so that it uses a HashMap to store the exits instead of an individual field for each exit.
Play the game to check that it still works - take a deep breath and relax a bit!
Your game scenario requires that there be items positioned throughout the world that the player can pick up and possibly use. An item sounds like something that should be represented by an object! So, create an Item class to represent the items in your game. You will need to decide what fields your Item class needs to have, what parameters the constructor will require and what methods the class will have. At a minimum, items will have a name and a description. However, items may have any other attributes that make sense for your game (e.g. weight, colour, value, destructive power ..)
Now that there is a class for representing Items we need a way to allow the rooms to contain an item. Modify the Room class so that one item can be added to or removed from the room. You will need to think about what fields and methods to add to the Room class. Also think about what the methods that you add should do when an attempt is made to add an item to a room that already contains an item, or an attempt is made to remove an item from a room that does not contain an item.
Now that a room can contain an item, when the player enters a room he/she should be told about the item in that room (if there is one). Modify the appropriate code so that if the player enters a room containing an item, the name and description of the item are displayed along with the description of the room and the list of exits.
Edit the code in the Game class so that the items for your game are created and added to the appropriate rooms at the start of the game. Recall that your game must include at least four items. Be sure to test any methods that you add or modify.
Play the game to ensure that your items are appearing in the rooms - enjoy the coolness of what you are creating!
Now that rooms can contain items and a player will know when they enter a room with an item, it would be nice if the player could pick up and carry items. Add functionality to the Player class that will allow the player to pick up and drop items. The player should be able to carry any number (i.e. a collection) of items.
Update your tests for the Player class to test the addition and removal of items.
Modify the Game class so that it will recognize the command take. When the user enters the "take" command, the item in the current room, if there is one, should be added to the items that the player is carrying and a message should be printed indicating that the player has taken the item. If there is no item in the current room the take command should print an error message. Be sure to test any methods that you add or modify. (Hint: Remember that one task of the Game constructor is to "teach" the CommandReader what words are valid commands. Thus, you will need to make a change in Game's constructor if you want to introduce a new command.)
Play the game to be sure the take command works!
Modify the Game class so that it will recognize the command inventory. When the user types "inventory" the game prints the names of the items that the player is currently carrying. You should think carefully about where the list of item names should be generated. (Consider the fact that the player is carrying the items, and think about how the list of exits for a room is generated and displayed.)
Play the game to be sure the inventory command works!
Add support to the game for a drop command so that the player can drop an item by name (e.g. "drop book"). The dropped item should appear in the current room. If the current room already contains an item, the drop command should print an error message indicating that the room is full and the player should continue to carry the item.
Play the game to be sure the drop command works!
Notice that when you use the help command take, inventory and drop do not appear as command words. Modify the printHelp method of the Game class so that it automatically displays any new command words that are added to the game. Hint: there is a helpful method in the CommandReader class.
Play the game to be sure the modified help command works - celebrate!