Homework #5
You "game" it

Objective: Show me what you have learned so far this semester.

Due: Multiple Deadlines.  See Below.

 .

An introduction

This programming assignment is unlike any you have done this semester.  In this assignment I will give you almost no hard fast guidelines over what you should program or how it should be programmed.  Instead, I will give you some general ideas, and encourage you to explore and create, teach yourself something new, and invite you to show me what you have learned so far both at the content level and at the style/design level.

Furthermore, you are not only allowed, but encouraged to work with a partner.  It is helpful if you put some careful thought into picking this partner.  You will need to find several hours a week outside of class where the two of you can get together to work on the assignment.  If you think it will be difficult for you to meet with a partner on a regular basis, than you should work on your own.

Finally, the actual code for this assignment will not be due for two weeks (instead of the normal one week).  However, there are several small deliverables in addition to the major code deliverable.  Please keep on top of this assignment and all of the pieces. 

Build a Game!

For this programming assignment I would like to have you build your own text base adventure game.

To begin, think about a game scenario that has as its base structure a player moving through different locations.  For example:

For the most part, you have total freedom to make any game that you like as long as I would not consider it to be a scenario that is inappropriate (sex, drugs, consuming large quantities of alcohol) etc.

As you are thinking about your game, dream beyond the basic "room" setup that is developed in the Zuul game.  Think ahead to things such as objects that will be in the game.  What the goal of the game will be and how you will test if it has been met.  What additional commands would you like to include.  DREAM! 

While you may use the code you developed for HW#4 as a starting point (If you have questions about YOUR version of the assignment, please see me and we can get any loose ends fixed up) you should not limit yourself to this design.  In fact, I STRONGLY encourage you to ditch the game layout that is there, and come up with your own design.

Again, my whole purpose of this assignment is to let you do whatever interests you, as long as you meet a few basic requirements.  Your final project can have as many classes as you deem necessary to get the project done.  These classes can, for the most part, have any numbers of instance variables and methods with any names and parameters that you see fit.  Now part of your grade for this project will be have you followed good design principles, but as long as you have, then you have a fair amount of freedom.

The Basic Requirements

If you would like to earn a C on the code portion of this project, your code must compile and meet the following minimum requirements.

  1. While your final design is almost completely up to you, I must be able to start your game in the same manner that I started the zuul game.  That is, your project must include a class called Game which is the main controller for the project.  This class must contain a default constructor to initialize the Game object (I shouldn't have to provide parameters to construct an instance of the Game class).  Finally, the class should contain a void method called play() (again, no parameters).  If everyone conforms to this design, it will make it much easier for me to play your games.
  2. Your game must have a goal, and achieving this goal must cause the game to announce that the player has won and cause the code to stop executing.
  3. You must add an "instructions" command to your game.  Typing this command at any time while playing the game will cause the game to print a brief set of instructions including what the goal is for the game.
  4. Add an Item class to your project.  An item object should, at a minimum, store its name and one additional attribute such as weight or cost.  You don't have to restrict it to these ideas, nor limit it to one attribute. You decide what makes sense in your game.
  5. Adapt the code in your project so that rooms can contain any number of items.  You will want to think carefully about how you design both the Item and the Room class to handle things. 
  6. Add a Player class to your project. A player object should store at least the current room of the player as well as any objects in the player's possession, but you may include any additional information that you like (for example, you might ask the user his/her name at the start of the game, and refer to this from time to time while playing the game).
  7. Implement take and drop commands that allow the player to carry any number of items.
  8. Add some sort of restriction that limits how many items a player can carry based on some attribute of the item.  For example, weight, cost, color, ingredients that won't combine to mysteriously trigger a spontaneous nuclear meltdown... 
  9. Implement an items command that prints out all items currently carried and whatever additional information the player needs to know if they can carry more (for example, you might print total weight, or how much money you have left, etc)

 

Earn More For Doing More

 In addition to everything you have to do to get a C, I encourage you to add one or more additional features that seem appropriate to your game and/or your abilities.  You will earn UP TO an additional 4 points (up to 12 total points) for each of the additional features you incorporate in your game.  Adding more than three of these features will not give you any additional points, but will get marked in my gradebook for final grade decisions.

  1. Implement a back command. This command does not have a second word. Entering the back command takes the player into the last room he/she has been in.
  2. Implement the back command so that using it repeatedly takes you back several rooms, all the way to the beginning of the game if used enough.
  3. Add some sort of "Easter Egg" to the game.  Finding this item increases the number of items the user can carry.
  4. Add some form of time limit to your game.  For example, if the player doesn't meet the goal within a certain number of moves, the game is over and they lose.
  5. Implement a trapdoor somewhere (a door that you can only cross one way so you have to go the long way around to get back where you were).
  6. Add a beamer to the game.  A beamer is a device that can be charged and fired.  When you charge a beamer it memorizes the current room.  When you fire a beamer it transports you back to the room (Can I set it up for an easy way to get from my office to the campus pub after a long day of listening to students complaining?).  The beamer can be standard equipment, or something that is found in the playing of the game.
  7. Add locked doors to the game.  The player needs to find a key or code or something to open a door.
  8. Add a transporter room.  Wondering into this room moves you to a random room in the game.
  9. Refactor the processCommand method so it doesn't have that ugly long collection of if statements.
  10. Add non-player characters to the game.  Characters are similar to items, but they can talk and help you.
  11. Add moving characters to the game.
  12. Some additional feature that you have approved by me prior to the due date.  If I don't approve it in advance, it doesn't count for extra points.

Deliverables and Timeline

Since this assignment is assigned over slightly more than a two week period, it is worth 50 points (although you can actually earn 52 points), divided between the following deliverables.

Initial Design

By Monday, October 12th, 4:00 PM (although I encourage you to turn it in during class), you should turn in your initial design for this project.  Your design will be worth 10 points

For this deliverable, I would like you to submit a 2-3 page "design" document.  This should include:

I am requiring that you do this not to create a contract, but so that you and your partner have an excuse to sit down and plan for this project.  It is perfectly acceptable to change your mind about things as you go along, but it helps if you both know the starting expectations.

Reality Check

By Monday, October 19th, 11:00 AM you should upload whatever code you have completed so far.  The code you submit for this reality check will earn up to 5 PA points.

It would be a good idea for you to have a goal for this reality check.  For example, you might decide to be through part 6 of the Basic Requirements.  I will not be spending much time checking your code since I realize this is a work in progress.  However, I will look to see if you are, in fact, making some legitimate progress on this program.  Teams who have hardly started will earn fewer points than those who are making progress (even if the code doesn't work yet).

The code should be uploaded to the account of partner A.

Final Code

By Monday, October 26th, 11:00 AM, you should upload your final project.  This code will be worth 20 points for completing the Basic Requirements and 4 points each for up to 3 additional features.  These points will be assigned both on the overall functionality of your code, but also for the design of the code.  zuul-bad and zuul-better both achieved the same functionality, but zuul-better was much better code.

This code should be uploaded to the account of partner A.

Once you are ready, use the homework submission system (http://math-cs.cns.uni.edu/~schafer/submit/which_course.cgi) to upload all of your code.

 

Project report

By Monday, October 26th, 4:00 PM, you should submit your packet of documentation for this project.  This will be worth 5 points.

Your project report should include: