CSC 2210, SPA 4:
Wumpus Hunt

Overview

This assignment will give you experience with working in teams to write a larger, object-oriented C++ program involving pointers and inheritance. It is in two parts:

Hunt the Wumpus was an early computer game. The basic goal of the game is to kill a wumpus in a cave without entering the chamber the wumpus is in, using your senses to detect when it is close by. Along the way you can fall into pits, be picked up by bats, and discover objects such as arrows and treasure. Atari had a full version of this that you can play online, but this has far more features than we want you to try to implement. A simpler version that is closer to what you should implement is available here. However, your solution must be character based. For example, your program might look like 

    
 Action: N)orth, S)outh, E)ast, W)est, shoot A)rrow, H)elp, Q)uit: e

 You hear flapping. You smell something bad.
 Action: N)orth, S)outh, E)ast, W)est, shoot A)rrow, H)elp, Q)uit: s

 You find an arrow. You smell something bad.
 Action: N)orth, S)outh, E)ast, W)est, shoot A)rrow, H)elp, Q)uit: n

 You hear flapping. You smell something bad.
 Action: N)orth, S)outh, E)ast, W)est, shoot A)rrow, H)elp, Q)uit: n

 You are in a maze of twisty passages, all alike.
 Action: N)orth, S)outh, E)ast, W)est, shoot A)rrow, H)elp, Q)uit: e

 You feel a breeze. You smell something bad.
 Action: N)orth, S)outh, E)ast, W)est, shoot A)rrow, H)elp, Q)uit: s

 You were eaten by a wumpus!

You will work in groups of 2 or 3 on this assignment. You will design your own version of the game and implement it in C++. One of your early tasks will be to document the rules of your game and to construct a class model. Part of your grade will be based on how unique your solution is; you might hunt moldy food in your fridge, chase Roscoe Raider through the science building, or be hunted by a large cockroach. Be creative with behaviors as well: alternative traps and new ways to move about the caves are also appropriate. Note that just substituting (say) marshmallows for arrows is not an example of creativity.

The Game

  1. You must have a help option describing how to play the game. Ensure this describes all of the rules.
  2. The game must be solvable through logic. Winning cannot depend largely on chance or exploring the whole game space. That is, it must be a puzzle game: give adequate clues to the user that they can use deduction to win. Depending on luck will cost points.
  3. At a minimum, you must have equivalents for the wumpus, the pits, the bats, and the arrows (something to pick up). Since you must use inheritance in the implementation (see below), you will need at least two types of hazards and two types of weapons.
  4. No graphics. All user input and output to your program must be through cin and cout using the standard ASCII character set.
  5. The map must have a reasonable size, at least 25 rooms but no more than 60. Larger maps will not be allowed because they make grading too difficult.
  6. The map must be bounded; you must have edge rooms that allow a player to know when they have explored as far as possible in one direction. The directions must always be east/west/south/north, and if the player enters a room where one of the directions is blocked then you must tell them so.
  7. You must provide clues to the player when they approach the various hazards. Since the gamer cannot see the map contents, they need clues to tell them when they approach hazards and the wumpus. For instance, the original game says "you smell something bad" if the player is in a room adjacent to the wumpus, "you feel a breeze" if the player is in a room adjacent to a pit, and "you hear flapping" if the player is close to a room with a bat. In the original, "adjacent" means either sharing a wall or a corner, and "close to" a bat is up to 2 rooms away. Arrows are not hazards, so there are no clues for those. You will need to define your own rules for clues (that must be documented). The key is that the clues must be strong enough that a player can deduce the location of the target (such as the wumpus) but still requiring logic to work out that location.
  8. You do not have to tell the player what room they are in. In the original game, forming a mental map of the dungeon and navigating that in your head was an important game element. But feel free to identify rooms (in whatever way you think is appropriate - maybe there are colored gems on the walls?) if you want.
  9. Stick to one level. Multi-level dungeons are too hard for instructors to test.
  10. Use e/w/n/s to move in the specified directions. Entering an "e" should move east; do not have the user enter more complex commands such as "m" for move followed by an "e"; the "e" is enough by itself. Uniformity is critical for grading. Upper case commands must be treated the same as lower case commands (case in-sensitive). Do not implement the common "wasd" directions - this game is intended for casual gamers.
  11. The program cannot quit because of an invalid command. Print an error and continue.
  12. Your game must exhibit random behavior. Randomly place items on the map so the user has to solve a different map each time. You can use rand to generate the random numbers. If your room arrangement is random, that must also be randomly generated for each game. There
  13. Along with the e/w/n/s, actions to pick up weapons, etc., have "m" display the full map with hazards and other elements. This will help with debugging and grading. Use the following key for this map: a period for an empty room, an > for a weapon (such as an arrow), + for the player, ! for a bat, @ for a hazard (such as a pit), ? for treasure, and # for the monster. As an example, your map would look like 
    
. . > + .
. ! @ . >
. ? . > !
. @ # . .
@ . . > @
    Follow this notation for your own game. Having uniform notation on this output will help tremendously in grading.
    If useful, you can also create a debug mode that displays the map on each move, but make sure this mode is disabled by default.
  14. While displaying the map is important to verify game play is working, it must be possible to win the game without resorting to viewing the map. This means you must implement clues similar to the "you smell something bad" clue of the classical game. In addition, the monster and other items must not move during game play unless there is a specific rule such as "the wumpus moves when shot at".
  15. Any hints you give the player must be based on being in a neighboring room. For example, feeling a breeze when the player is next to a pit or hearing the wumpus start to move if it is disturbed by shooting an arrow. This is a large part of what makes hunt-the-wumpus a winnable puzzle game. You should be able to find corresponding clues for any variant of the game. Do not make the player purchase hints (say, trading gold or experience points) because this will make the game too hard to grade. The "neighborhood" for a room is something you can determine, but do not allow clues to travel too far or the game will be too hard to play.
  16. Whenever the bat (or its equivalent) moves the player in the dungeon, provide a hint saying the player moved. Note the original game does not say where the player moved to, just that the player was moved.
  17. Whenever the player is killed, say by falling into a trap or being eaten by a monster, say what killed the player so the user can learn to play the game better in the future.
  18. Whenever you create an instance of a class your group writes, or whenever you pass an instance as a parameter, use pointers. This is especially important for inheritance, but it is also necessary to give your team more experience with pointers. Be sure to use delete to return all allocated memory to the heap. This wouldn't be strictly necessary for a small project like this, but it is good practice. There must be exactly one delete executed for each new executed. You will likely want to implement destructors to ensure this happens.

    19. Design Constraints

    Hints

    Part A

    This project is broken into two parts. The first is about specifying the problem, the second about completing the implementation.

    For part A, submit a (single) PDF containing all of the following

    In addition, check in an initial version of the project that builds on all machines. This should print the primary menu, print the help text when the user enters 'h', generate the collection of rooms and print the map of the rooms when the user enters 'm', and exits when the user enters 'q'. Also write preliminary versions of all class definitions (just the interfaces, not the implementations).

    Some students are tempted use use the code generation feature of Enterprise Architect to create the initial code. Do not; it adds a lot of unnecessary artifacts and means you will not get sufficient practice writing C++ code. If it takes more than a couple hours to create an initial version of the project, get help from your instructor. It should be as simple as creating a "hello world" program and editing it to prompt the user until the user enters 'q'.

    Part B

    Part B is finishing and delivering the full solution. This includes the following:

    1. Have a friend play the game and confirm it is winnable with minimal help from you.
    2. Ensure all code meets the published coding standard and has been pushed. All source (.h, .cpp files) must be in a folder called src in the top level of your repository.
      • Remember that the standard mandates lower case filenames.
      • There should not be any subdirectories in src. Multi-folder C++ projects do not make sense for the small projects you create in academics.
      • You must have fewer files than classes to ensure you understand that one file per class is not a requirement in C++.
      • The submitted code must be on the main branch. You are discouraged from using branches for short assignments such as this.
      • The 15-line length limit does not apply in this assignment.
    3. Ensure the project build files have been checked in to your repository.
    4. In the top level of your repository, create a file README.TXT (or README.md, etc.) which gives the names of all people on your team and build directions that indicate the version of C++ you used, the build tool you used, the steps someone goes through to use that tool to build an executable, and where the executable can be found once it is built. Anyone who knows C++ and has your build system installed should be able to reproduce those steps.
      • Document how to enter debug mode in the game.
      • Include any changes to your game (from your stated design) in this document.
      • Use the output of g++ --version to determine the version of the tool used to build the system. It is very helpful to be able to identify this when trying to get a system to build years after it was written.
    5. Double-check that your instructor has access to your repository.
    6. Capture a sample run of your program showing that it works. You do not have to capture every movement, but it should be clear how the player won the game through the moves they made and hints they got. This will likely use debug output to show what is happening. Be sure each screen shot is readable with a minimal amount of additional information. (In particular, you don't want to include code windows or lots of blank space in the screen shots).
    7. In addition to your screenshots, use these directions to create a reverse-engineered (UML) class diagram of your system, export it as a .png, and include that image in sample-run.pdf. Note only one student needs to construct this diagram.
    8. At the top of this PDF, list the assignment name and the names of all group members.
    9. Submit sample-run.pdf to Canvas to signal that you are finished.
    10. See the submission requirements on Canvas. You may need to demonstrate your solution to your instructor, but this depends on how your instructor grades the assignment.

    Common Issues