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.

You should be able to replace your versions of Command.java and Parser.java with these files, but do not overwrite your Game.java since is certainly has code that you will need! Instead, just copy autoPlay (new method) and replace your versions of play and printWelcome (It just addes a dashed line at the top so you can more easily tell when you are starting over).

Your commands.txt (or whatever you want to call it) should have 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 tset 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.

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.