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:
- You are a white blood cell traveling through the body in search of a virus
to attack...
- You are lost in a shopping mall and must find the exit.
- You are from the bomb squad and must find and defuse a bomb before it goes
off...
- You are Indiana Jones searching through a hidden temple of monsters and
other characters
- You are a student looking for a stapler so you can hand in your assignment
in my class...
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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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).
- Implement take and drop commands that allow
the player to carry any number of items.
- 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...
- 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.
- 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.
- 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.
- Add some sort of "Easter Egg" to the game. Finding this
item increases the number of items the user can carry.
- 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.
- 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).
- 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.
- Add locked doors to the game. The player needs to find
a key or code or something to open a door.
- Add a transporter room. Wondering into this room moves
you to a random room in the game.
- Refactor the processCommand method so it doesn't have that
ugly long collection of if statements.
- Add non-player characters to the game. Characters are similar to
items, but they can talk and help you.
- Add moving characters to the game.
- 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:
- assignment of who will be partner A and who will be partner B.
- a general description of the world that you plan on building
- a specific description of the rooms and items that will be in your world
(a map might not hurt)
- a UML class diagram for each class (including what it knows about itself and the
methods that it will respond to). This will be best created by using the
responsibility-driven design process discussed this semester. [Figure 2.14c]
- a UML navigability diagram [Figures 2.16 and 2.17]
- a rough schedule of when you will get together to work, and what parts you
hope to have accomplished by when.
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:
- Cover Page/Self Assessment
- Printouts of each of the classes submitted with your final code.
- A "work log" which documents every time someone worked on your project
including
- the date and length of time the work was done
- who worked on the project (normally this should be both of you)
- what you were working on.
- A "reflections" paper from each individual team member.
- For EACH of the basic features (features 2-8) and your advanced features
(A-L) this should include
- a paragraph or two describing the changes you made to your code and
the reasons you chose to code the feature that way.
- a description of how you would test the change for that feature while
playing the game
- a paragraph or two concerning what you learned in this process
- a paragraph or two about what you would do differently if you were
starting this project over from scratch
- (if working on a team) a paragraph or two about how well you and you partner worked together as
a team
- [Added after original assignment but sent via email] - A "cheat sheet"
Give me a step by step set of instructions for how to move through your game
and "win" If you have random number generators in your code you should
either have a way to turn them on/off OR use the Random class which allows you
to use a pre-determined seed which means the same random numbers are produced
in the same order every time you run the game.