Term Project: Dungeon Adventure Game

Goal

The purpose of the final project is to give you a flavor for what a "real" object-oriented software development project is like. You will experience each step in the process from analysis and design to implementation and testing. 

Background

Dungeon is an interactive game that allows the user to explore a dungeon maze, collecting objects (weapons, tools, and treasures), and fighting monsters.  You play the game by typing simple commands to move; get, put, and use objects, etc.  The dungeon layout is specified by a data file, which you need to be able to read in and write out.  The data file includes descriptors for all rooms, plus wandering monsters and player state.

Assignment

You will design and build the Dungeon game.  The specifications for this game are open-ended, but at a minimum, your game should be able to do the following:

- Load a dungeon from a data file.  This includes the definitions of all the rooms in the dungeon, plus any other state information necessary to initialize a game.  This file should use a textual format so that it can be viewed and edited in a text editor.  When the game first starts, it should read its initial configuration from a configuration file.

- Save a game to a data file.  This file should be in the same format as used for loading so that you can restore a game from a saved file.

- Read and interpret the following commands:

- The dungeon should contain at least the following things:

    - Rooms: This is just a basic room.  Rooms have a description and one or more exits.  Each exit is associated with one or more movement directions.  As a minimum, you should support the four compass points (N, S, E, W), though you may decide to add others (NE, NW, SE, SW, up, down, for instance).  Each exit leads to another room, so that moving in a direction associated with an exit causes you to enter some other room.  It is up to you to determine the number and layout of the rooms in your dungeon.  There should be enough rooms to give the player something interesting to explore.  When the player first moves into a room, you should print a description of the room, including its physical description, any exits, and a list of all items and monsters that are present.

    - Monsters: These are the creatures that inhabit the dungeon.  A room may contain at most one monster.  If you spend any time in a room where a monster is, it will attack you.  Monsters have a description, and defense and attack attributes that determine how likely they are to hit you and how difficult they are for you to hit.  Some rooms have Monsters that live in them.  They will stay there and attack you until you destroy them.  When you are in a room that does not have a Monster, there is a 5% chance on each turn that a wandering monster will enter the room and attack you.

    -Items: There are many items in the dungeon.  Items have a description.  Items may be found in rooms, or in your possession.  If an item is in a room, you can pick it up, causing it to be in your possession.  If it is in your possession, you can drop it, causing it to be in the room where you are.  You have unlimited carrying capacity.

    -Armor and Weapons:  These are two special types of Items.  In addition to Item attributes, Armor has a defense attribute, and Weapons have an attack attribute.  If you pick up a weapon and its Attack attribute is higher than your current weapon, it becomes your current weapon.  If you drop your current weapon, you become unarmed (that is, you must pick up another weapon to make it your current weapon).  You can carry several weapons, but only one is your current weapon.  Similar logic applies to Armor.  Your Attack and Defense attributes are determined by your current weapon and armor.  This is in contrast to a Monster, whose Attack and Defense attributes are fixed.  You can improve yours by finding better stuff in the dungeon.

The outcome of an attack is determined by the following algorithm:

The Attacker (you or the monster) generate a random number between 0 and 127.  If the number is less than or equal to the attacker's Attack attribute, the attack landed.  If the attack lands, the Defender (you or the monster) generate a second random number between 0 and 127.  If that number is greater than or equal to the defender's Defense attribute, the attack does damage.  You and monsters have a Health attribute which is reduced by 1 each time an attack does damage.  If a Monster's Health reaches 0, it is destroyed.  If your health reaches 0, the game is over.  If your Health is less than its full value, it is incremented by 1 every 10th turn.  Monsters' Health does not regenerate.

If you have ever played a game like this, you will certainly be able to think of numerous ways to enhance and extend it.  I will be happy to suggest some if you are interested.  If you have the time and inclination, feel free to make whatever enhancements you think will make the game more playable and fun.

Deliverables

The final project is due on the last session of the term. At that time, you will be required to turn in:

1. A set of UML class diagrams that depict the attributes and operations (methods) of your classes. (Hint: The operations should roughly correspond to the responsibilities identified during the in-class CRC exercise.) These diagrams must also show the relationships among classes such as composition and aggregation, inheritance, and dependencies.
2. A set of UML sequence diagrams that depict key object interactions that occur during the normal operation of the system.
3. A set of UML state diagrams that depicts the states and transitions of key objects as they change during the operation of the system.
4. A two or three page narrative that provides a high-level discussion of the major components in the system and how they work. This document should reference elements of your diagrams and other materials to provide a conceptual overview of how your system works. Also include any simplifying assumptions you made during the course of development and any other information you believe would aid in the understanding of your solution.
5. A map of your dungeon, showing all the rooms and their connections.
6. The C++ implementation of the Dungeon game. Make liberal use of comments throughout the source code! As a minimum, all class definitions and methods should contain a comment section that describes the class or method.

The list above suggests an order in which you should develop your project, but remember that object-oriented development is an iterative process, so expect that you will cycle through this list several times before arriving at a complete solution.

Grading

Grading for the term project will be as follows:

Additional UML Resources

Rational Software maintains a nice collection of UML resources on their Web site. Visit http://www.rational.com/uml/index.jtmpl for references, tutorials, and slides that can be used to supplement the discussion and slides we used in class. Another good (and inexpensive!) resource is Sinan Si Alhir's book, called UML in a Nutshell and published by O'Reilly.