Zuul

Part 1.5-related stuff

Updated files from the Zuul project that make testing your world easier. All you have to do is put commands one per line in a file and this will run them all and give the output.

See the list of files to the left under the Zuul heading that you will need. Do the following to update your code:

• Replace your versions of Command.java with the one here.
• Replace your versions of Parser.java with the one here.
• Do not overwrite your Game.java since is certainly has code that you will need! Instead,
  • Copy autoPlay (new method) into your Game.java.
  • Replace your versions of play with the one from here.
  • Replace your version of printWelcome with the one from here (It just addes a dashed line at the top so you can more easily tell when you are starting over).
• Create a file commands.txt that has commands, one per line, followed by the pound sign (#), followed by comments about what should happen. For instance, here is a short script that I used to test my locked doors and missing exits.

  go west # Should take us to pub.
  back # We should be back in outside
  go south # Should tell us it is locked
  go north # should tell us that it is invalid
  take key # key should be picked up
  unlock north # should tell us there is no exit
  unlock east # should tell us it isn't locked
  unlock south # it should unlock the door
  go south # should take us to lab
  take zebra # It should say you can't carry the zebra
  quit # It should quit.
  

  Your list of commands should be longer than this!

Previous feedback on Part 1

Here are comments I have given to students on part one in the past. It should give you an idea of things to avoid and things to do. The details of method names and stuff may not apply to your code exactly since these comments were about specific choices previous studentd made.

• Printing should only be done in Game. Methods in Player, Room, and Item should return String results instead of printing.
• Item.describeItem and Player.displayItems should return String descriptions.
• Player.back, takeItem, dropItem, eat, goRoom, and goBack should handle the necessary details within Player and return results to Game.
• Only Player should hold currentRoom and previousRoom. Remove redundant fields from Game.
• Room should not expose its internal HashMap of items. Instead, use methods like getItem(String name) and putItem(Item item) to manage items.
• Avoid returning internal data structures directly, such as HashMap or ArrayList of items in Room and Player. Return a String summary or specific Item when needed.
• Refactor methods in Game that take Command objects to pass only the second word as a String argument where appropriate.
• Rename confusing variable names, such as allRooms in Player, which could imply it contains all game rooms.
• Simplify data structures: Use HashMap<String, Item> instead of ArrayList for items in Room and Player to make lookups more efficient.
• Implement a back method in Player that handles the logic for returning to previousRoom, updating only when the room changes.
• Remove unnecessary or redundant fields, such as carryingCapacity in Game and hasWeight in Room.
• Ensure Player checks for an item's presence in currentRoom before picking it up, and similarly, verifies the item is in the inventory before dropping it.
• Avoid redundant checks, such as using "==true" in conditionals.
• Consider storing totalWeight within Player and updating as necessary to avoid recalculating it each time you ask for it.
• Unused fields or methods should be removed if unreferenced (e.g., previousRoom in Game).
• Use meaningful and clear names for methods. For example, dropItem in Room would be confusing. addItem might be clearer.
• The goRoom method in Game should delegate room navigation to Player, with methods like goDirection(String direction).
• Player.takeItem and dropItem should accept item names as String arguments and check currentRoom for item presence.
• Methods in Player for inventory actions should manage currentWeight incrementally.
• Remove unnecessary method dependencies, such as getPreviousRoom in Player, by handling room history internally.
• When executing commands, verify if a second word is required and handle null checks for arguments within each method.
• Use descriptive error handling in methods like takeItem to indicate success or failure of the action.