Java

Project 2: A Much, Much Better Zuul Modified from an assignment by the authors

Due: Wednesday, March 26 at 11:59 pm.

Your assignment is to create a game based on Zuul, the game described in chapter 6. I would suggest you start with zuul-better.

First, you should decide what the goal of your game is. It should be something along the lines of: You have to find some items and take them to a certain room (or a certain person?). Then you can get another item. If you take that to another room, you win. For example: You are at Xavier University. You have to find out where your lab class is. To find this, you have to find the registrar and ask. At the end, you need to find the exam room. If you get there on time, and you have found your textbook somewhere along the way, and you have also been to lecture class, then you win. And if you’ve been to Ryan’s Pub more than five times during the game, your exam score is halved. Or: You are lost in a dungeon. You meet a dragon. If you find something to eat that you can give to the dragon, then the dragon tells you where to find a magic wand. If you use the magic wand in the big cave, the exit opens, you get out and win. It can be anything, really. Think about the scenery you want to use (a dungeon, a city, a building, etc) and decide what your locations (rooms) are. Make it interesting, but don’t make it too complicated. (I would suggest no more than 8-10 rooms.) Put objects in the scenery, maybe people, monsters, etc. Decide what task the player has to master.

It is important to start early and ask questions often. And remember that, unlike the homework, this is individual work at the code level. From the syllabus: You are permitted to discuss general concepts with other students but cannot share code or algorithmic solutions. Violation of this could result in a 0 on the project for you and your collaborator. You are encouraged to ask questions of the instructor in class or out of class about the project.

You should complete the code in order from D-level to A-level. You cannot get credit for A-level work unless the earlier levels are working. See project 1 for a guide as to how I will grade projects. Like project 1, you will need to create a log for this project. You must also include a brief description of the game, including a room map and a command sequence that will win the game. You also need to tell me what you have implemented in each level of the game when the requirements are variable (so, for example, list the four new commands that you implemented in C-level).

D-level functionality

At this level, you have to implement your scenario with the following functionality:

• The game has several locations/rooms. • At minimum, rooms can have up to 4 exits (east, west, south, north). • The player can walk through the locations. (This was already implemented in the

code you were given.) • There are items in some rooms. Every room can hold any number of items. Some

items can be picked up and some cannot.

C-level functionality (note that you must have received the majority of the D-level points to be eligible for C-level points)

D-level with the following modifications:

• The player can carry some items. Every item has a weight. The player can carry items only up to a certain total weight.

• The player can win. There has to be some situation (of reasonable complexity) that is recognized as the end of the game where the player is informed that he/she has won.

• Implement a command “back” that takes you back to the last room you’ve been in.

• Add at least four new commands (in addition to those that were present in the code in zuul-better and in addition to “back”).

B-level functionality (note that you must have received the majority of the C-level points to be eligible for B-level points))

C-level plus three of the following:

• Add a time limit (exercise 6.41) • Add a trap door (exercise 6.42) • Add a beamer (exercise 6.43). • Add a locked door (exercise 6.44) • Add a magic transporter room -- every time you enter it you are transported to a

random room in your game (exercise 6.45).

A-level functionality (note that you must have received the majority of the B-level points to be eligible for A-level points)

To the B-level functionality, add at least two additional features. The features should be non-trivial and should indicate some effort. If you have an idea and are not sure, clear it with me first. Ideas include:

• Add characters to your game. Characters are people or animals or monsters -- anything that moves, really. Characters are also in rooms (like the player and the items). Unlike items, characters can move around by themselves (and should).

The characters should interact with the player in some way, even if it is just speaking to the player when the room is entered.

• Extend the parser to recognize three-word commands. You could, for example, have a command give bread dog

           to give some bread (which you are carrying) to the dog. You need to include at least 3 new three-word commands. • Make the game multi-player where players take turns moving. • (Note that this option is sufficient for A-level by itself) Read the initial game

setup from a file. As each line is read, the correct method is called to set up the appropriate initial game state. You need to include error checking for the input (for example: does the room already exist?) with some output to the player if there is a problem. Hint: Consider using a HashMap to store the rooms in the game by their names. The file contains lines of three types:

1. room name description – where name is a one-word unique name for the room and description is a string that describes the room

2. exit room1 direction room2 - where room1 is the name of a room, direction is a one-word direction, and room2 is the name of the room that is connected by that exit from room1

3. item name weight location – where name is a one-word item name, weight is the item weight and location is the name of the room where the item is initially located

Creativity and cleverness will also be considered when deciding whether the A level has been reached.

Notes on Style See the style guide posted on our book site. Approximately 25 percent of your project grade will be based on coding style, including documentation. Generally I will divide this into an assessment of

• documentation -- the comments and specifications for your code. • naming -- quality names that make your code more self-documenting. If any of

the names are specified in the project description, you must use those names! • code structure -- the structuring of the code itself: line and method lengths,

indentation, whitespace, clarity of code, efficiency of code. (Efficiency is not a big concern early on.)

Deliverables -- what should you hand in? • Each time you work, please make a note in a programming log. The log is

intended to help you and I analyze your behavior over time -- noticing where you spend time or have problems, and to help me give you advice on your process as well. You will not lose points for what may seem to be questionable practices, but

you will lose points for not providing the log. Your entry each time should include date, how long you worked, what you worked on, what problems you encountered, how you got around the problem, why you stopped working. You don’t need to be too wordy but include enough detail so I can understand your process. Turn in this programming log with your code. A Word doc is fine for this.

• Your documented code. Include all .java files from the project. • A document describing your game including implemented features at each

level, a map of your rooms, and a command sequence that will allow someone to win the game.

Everything should be zipped into one file and submitted on Canvas by March 26 at 11:59 pm. Start early – there is a reason I am giving you almost two weeks to do this project!