CPS 108: Adventure

Spring 1999


Your team should implement an interesting adventure game. Of course, today most people can only think of fast-paced, 3-D, shoot 'em up games where there is no plot, only to stay alive.  But adventure games have a long, varied tradition.  For example, in the beginning, such games were all about fantastic characters killing things and gaining experience points so they could kill bigger things. The main difference between those games and the games people play today is that computers are much faster, so the games tend to be more graphical and fast paced.  Your adventure game will probably harken back to the older style of adventure games which were much more slowly paced -- the player would read a description of the room instead of seeing it in vivid detail, or fight monsters in rounds rather than try to shoot them as fast as possible.

Specification

The plot for your game does not need to be limited to just killing things; it simply needs to incorporate a goal to achieve and a series of tasks for a player to do before acheiving the goal. At a minimum, your program must support the following features.

Goal

There must be a goal to the game. There is no limit on what the goal can be, except that it must be achievable at all points during the game and clearly documented (both within and without the running program) so the player knows what it is. For example:

Maze

The adventure takes place in a maze whose rooms and inhabitants are randomly generated with each new game. There is more to a maze than walls, windows, and doors though, how about:

Objects

The player encounters objects in the maze which can be picked up. These may or may not be useful to the player or part of the player's goal. Possible tricks to play with objects:

Non-Player Characters

As a player may also encounter various other autonomous characters while moving through the maze. These characters must be able to move around the maze of their own accord, and you should allow more than one character to be in any given room. There should be at least two types of non-player characters in the game. Each type should interact differently with players and others, for example one type can be friendly and another aggressive to the player. Of course, the possibilities are endless (see people try to take advantage of the web today):

Player

A player is actually controlled by the user and should have at least one personal characteristic which changes based on interactions that occur during the game.

Implementation

As you can see by the variety of options, there are many possible ways to view an adventure game. Your adventure game must be fairly generic underneath the interface the user sees so that it could be possible to change your game to have a different storyline. A good way to do this is to separate as many of the component pieces into object hierarchies.

Model

At a minimum, you are to implement a graph class to represent your maze and associated iterators that allow users to traverse the graph. Recall that a graph is a generic data structure that represents relationships (edges) between things (vertices) -- for example connections between rooms.  This builds a model for your maze that characters can move through.

Each room (or area in the maze) will also need to manage the characters and items that pass through it during the game. Additionally, the player and automonous characters should be able to carry any some reasonable number of objects as they pick them up (based on their weight, memory, space, etc.). You can use the collections from the JDK or JGL.

Interface

So far, there has been no discussion of the interface that allows the player to interact with your adventure game.  Minimally, you must provide a text-based conversation-style interface.  In this style, each object (room, item, player, character, etc.) has a description.  When you see a specific item, its description is printed to the screen.  You can play the game by issuing simple commands (like north, look, take, etc.).  The more complex the commands the more interesting the interaction with the game.

However, there is limited appeal (especially these days) to reading descriptions of the world around you.  Some people like to show the game in pictures.  You can do this in a variety of ways: build an applet to display images of the objects in the game, build GIFs and use netscape to display them (see here for more information), or show a top-down view of your maze that the player can move through.  You can also combine these views with text -based commands or graphical controls.  Finally, for the truly brave at heart, you can use Java-3D to construct and view your maze.

Testing

One last note: be careful about how you build and test your game. You may want to build certain set configuraions for your game to test each feature (before getting involved with making the game random).  If the game is really hard to play, it will be hard to test as well.

Deliverables

  1. Friday, April 2 in class: The plot or storyline for your game.  A page or two description of how your game will meet the requirements given above.
  2. Friday, April 9: The first prototype of your game.  A player should be able to move through a maze correctly (i.e., without going through walls, etc.).
  3. Wednesday, April 14: The final version of the program.

Resources

Descriptions

Libraries

Examples

Extra Credit

The possibilities for extending this game are boundless. A key point to doing well on this assignment is to show your creativity.