CPSC 240 — OOA&D — Spring 2024
Due: Monday, April 8, midnight
Your team's mission is to complete a text-based game engine capable of leading a user through a thrilling adventure. It will use the Zork design from the first half of the semester as a foundation, and expand upon it by allowing the adventurer to meaningfully interact with the game state, solve puzzles, accumulate a score, potentially win the game, heal/suffer and possibly die.
There are three phases to this project:
There are two halves to your mission: standard features, and supplemental features, each equally weighted in each of the phases.
Your Zork++ game engine must support the following two additional commands: "score", and "health".
If the player types "score", their numerical score, on a scale of your choosing, will be displayed, along with a text "rank":
I place no constraints on how many points the player may be allowed to earn, or what ranks you assign, other than that when a dungeon is started from scratch, the player's score must initially be zero.
A player's score must of course be persisted and hydrated in the .sav file in some way (your choice).
The "health" command will display a "fuzzy" (i.e., non-numeric) message measuring the shape of the player's physical condition:
I place no constraints on what kinds of messages you're capable of printing (be creative) or what events cause health increases/decreases, other than that when a dungeon is started from scratch, the player must initially be in good health.
A player's health of course must be persisted and hydrated in the .sav file in some way (your choice).
An event is anything that can occur that changes the game state in some way. One possible way (but certainly not the only possible way) of enabling such events is to attach them to item-specific commands, so that when an item is used in a certain way, an event is triggered.
Zork++ standard events will appear in the .zork file in [] syntax, as in the examples below:
As you can see, some item-specific commands are associated with one or more events, which appear in a comma-separated list inside the brackets. This gives a crude mechanism for interacting with the game state, although you will shortly realize its limitations and want to expand the way this works in more flexible ways.
Standard Zork++ events must include the following:
When triggered, adds the number of points to the user's score.
When triggered, the user's health will decrease by the number of points in parentheses. (If this is a negative number, this effectively doubles as a "Heal" event.) Reminder: although the game internally keeps track of a player's health numerically, the "health" command's messages do not print numbers, but fuzzy messages.
When triggered, the game is over, and the player loses.
When triggered, the game is over, and the player wins.
When triggered, the item will be dropped into the current room, just as if the user had explicitly typed a drop command.
When triggered, the item will simply cease to exist, disappearing from the room, inventory, and dungeon.
When triggered, the item will disappear and be replaced by another item whose primary name is in parentheses. (Normally the new item will not have existed previously; i.e., although it appears in the "Items:" section of the .zork file, it will not have been named in the "Rooms:" section and therefore not really exist at all when the dungeon is originally started.)
When triggered, the adventurer will be randomly teleported to some other room in the dungeon. This may or may not be a room that they have already visited (or one that is even reachable in any other way.)
Knock yourself out.
Below are listed some example ideas of features with varying degrees of difficulty, to get your creative juices flowing. Note: to get full-credit for the assignment, you must design and implement at least 50 points worth of supplemental features.
Verbose mode (about 10 pts). Add commands "verbose on" and "verbose off" which will toggle the exit text that currently always appears. (Having the exits listed at the end of each room description makes it faster to go through the dungeon, but a real adventure program would probably make the user infer what exits exist from the room description.)
Hunger (about 15 pts). The adventurer's health diminishes by (say) 1 point per turn, and is only replenished by food, enough of which must be available somewhere and somehow in the dungeon.
External clock (about 15 pts). Some passage of time exists in a way the adventurer can experience. A simple example of this is time of day: as the user plays the dungeon, time will cycle from day to night and back again at an appropriate pace. Randomized weather events would be another colorful choice. Fun fact: the real-life Zork III was famous for an earthquake that took place after a certain number of moves, which permanently closed certain underground passages but opened others.
Light (about 30 pts). Some rooms, not all, will be completely dark to the adventurer unless he/she has a light source (torch, spylaser, lightsaber, whatever) available and turned on. Light sources are items that are discoverable in the dungeon and which "defuel" over time; i.e. there is a finite length to how long they last before burning out. It's your option as to whether light sources can be replenishable. It's also your option whether or not to include a grue.
Crafting (about 40 pts). Some items can only be assembled from others. (You have to sprinkle the magicDust on the sword to make a magicSword capable of defeating a dragon; you have to mix the flour and the eggs to yield pancakeBatter which can then be cooked and eaten to survive; etc..) This requires the player to think outside the box and figure out which combinations of existing items might yield others and what command(s) would be required to trigger that occurrence.
Closable exits (about 25 pts). Some exits can be in a closed state, and require users to type a certain command in order to open them.
Lockable exits (about 40 pts). Some exits can be in a locked state, and require a certain item (or "key") to be present and/or activated in order to unlock them.
NPCs (non-player characters) (about 40 pts). There are other creatures in the dungeon besides just the adventurer. These creatures have their own position, state, inventory, health, and possibly other attributes, and the player can only interact with them when they encounter each other. Having NPCs move around between rooms independently of the player is super cool. Implementing some sort of dialogue — asking, convincing, threatening, trading items, etc. — is even more of a bonus.
Combat (about 30 pts). A combat system enables NPCs to engage the adventurer (and each other?) in battle. You're going to need weapons and rules of engagement to implement this. Bonus points for assessing armament, shields, magic weapons and items, terrain, strength and dexterity of characters, the influence of fighting in groups, and/or anything else you might think of.
These are all only examples. There are lots and lots and lots of other things you could do instead. If you have another idea for a supplemental feature, come describe it to me and I'll tell you how many supplemental feature points I think it's worth.
For phase 1 of your project (due Apr 8), your team will be turning in the following deliverables:
To be crystal clear: your team will be turning in one submission for this group activity.
To turn in this assignment, print all the pages for the above items on physical paper, add a cover page with everybody's name and your cool team name on it, staple the packet together with a stapler, and stick it in the "240" manilla folder hanging outside my office door before the deadline. The packet should be clean and readable, with section headings, titles, and/or whatever else is necessary to make it absolutely crystal clear what each page represents. It should also be a pleasure to read. I should actually feel pleasure when reading it.
Send email with subject line "CPSC 240 Zork++ HELP!!!" and be sure to Cc: both your teammates!