CPS 108: Adventure Change Cases
Spring 1999
As has been stated many times in class, but perhaps not formally written
down, your Adventure design must be flexible enough to handle a variety
of game options besides those your group specifically chooses to implement.
In order to clarify those options and give your group enough information
to determine what to implement in the remaining time, we are offering the
following list of options. These options are taken from the initial
handout, addendum, or news posts, though they may be specified further
or enhanced slightly.
Your group should treat these as "change cases". In other words, before
you hand in your final project you should think about (and perhaps even
write down) how you would need to change your code in order to incorporate
each option. The simpler the necessary changes to your code to implement
each option, the better your project grade will be. Note, your
final project does not have to implement any of these options, but you
must be able to explain how you would implement it (or why you cannot).
Maze
-
Allow locked connections
For example, players must have a key (or boat, money, etc.) to cross
into the connected area
-
Allow one-way connections
For example, a trap door that slides players to a pit from which they
cannot climb out, or a freezer door that has no handle from the inside
and closes when a player enters
-
Allow connections in three dimensions
For example, in addition to the four compass directions, make connection
to areas above and below as well (you may also want to think about to display
this sort of a maze to the user (i.e., how do you show the extra connections))
-
Allow mazes to be saved and restored, either from a file or URL
Items
-
Allow "casper" items that allow players to use impassable connections
For example, having this item allows a player to walk through walls
(or locked doors, mountains, water, etc.)
-
Allow items or rooms that are represented by something other than an image
file
For example, animations or perhaps a puzzle that has buttons or other
user interface controls
Players
-
Allow players to work alone or together in groups
For example, when joining the game a user may be asked to join a group
or work alone. A group of players moves together whenever the leader
(the first player in the group) moves, but may act individually within
a room
-
Allow a special administrator player
For example, someone could join to fix a game that has become unplayable
somehow, or make it easier or harder to match the level of the people playing
it.
Goal
-
Allow the user to start the game to choose the theme (but the goal remains
the same)
For example, instead of people collecting beer or drugs in crack houses
or cities, give the user the choice of being bunnies collecting flowers
or seashells from meadows or beaches. Note, this should basically
change just the names (or images) used in your game, but not the rules,
interactions, or goal.
-
Allow the user to start the game with a different goal (and storyline)
For example, instead of the specific features your group chose, the
user should be able to play a game in which the goal is to find seeds from
a rare tree (hidden somewhere in the forest) and plant them to grow more
trees until the forest is re-filled. Along the way, the player must
find fertilizer or chemicals to make the soil in specific areas of the
forest able to grow trees because nasty company people have ruined the
soil. Different areas of soil may require different amounts of chemicals
and fertilizer; the player should have some way of testing that the soil
is safe before planting the precious seeds. Finally, the forest to
be is threatened by rain (which washes away your seeds) and fire (which
burns your new trees). Rain moves through parts of the forest at
random times, but always in a straight line. You can protect your
seeds by covering them with tarps (of which you have only a limited number).
Fire starts spontaneously and spreads at random speeds in every direction.
A player can stop the fire by throwing dirt or water on it.