CPSC 240 — OOA&D — Spring 2024

"Zork++" phase 1 — UML design

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.

Project phases

There are three phases to this project:

  1. Phase 1: UML design (due Apr 8)
  2. Phase 2: Implementation of standard features (due Apr 15)
  3. Phase 3: Implementation of supplemental features (due Apr 27)


There are two halves to your mission: standard features, and supplemental features, each equally weighted in each of the phases.

Standard features


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":

> score You have accumulated 25 points. This gives you a rank of Amateur Adventurer. >

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:

> health You feel fit as a fiddle. ...other commands... > health You're a bit light-headed. ...other commands... > health Each step is a stagger from the pain of your wounds. ...other commands... > health You are about to die.

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:

James Farmer Hall Zork++ === Items: Bomb 95 examine:The bomb is a heavy, glistening black sphere. On the top appears to be some form of detonator. kick[Wound(2)]:Ouch! That hurt your foot. detonate[Die]:An ear-splitting halo of shrapnel kills you and seriously degrades the room's interior. --- DrPepper,can,soda 10 kick[Drop]:The can skitters down the hallway. shake:A liquid fizzes menacingly inside the can. drink[Transform(emptyCan),Wound(-1)]:Gulp, gulp -- that was GOOD! *belch* ---
emptyCan,can,soda 2 kick[Drop]:The empty can skitters down the hallway. drink:Sorry, all gone! stomp[Transform(squishedCan)]:The can crunches down into a thin disk, useful for recycling.
squishedCan,can 2 throw[Drop]:Zing! stomp:Further stomping seems to have no effect. recycle[Score(5),Disappear]:Boom-ya, helped save the environment.
--- magicWand,wand 5 break[Wound(10),Disappear]:The wand snaps in half. Strange magic fills the air; you feel suddenly ill. wave[Score(5),Teleport]:An angelic form briefly appears, smiles, and just as quickly fades away. --- StarWarsToy,Yoda,toy 5 touch[Score(1)]:Yoda says, "Do, or do not! There is no try." break:Luckily, it's made of rugged plastic. --- chainsaw 35 --- WawaTravelMug,mug 10 refill[Win]:You refill the mug with everlasting light roast coffee, and live happily ever after! :) --- donut 7 eat[Disappear,Wound(-2)]:You feel mildly guilt-ridden, but also somewhat nourished. stomp:The donut is now smooshed. --- === ...the rooms section, exactly as in Zork III...

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.)

Supplemental features

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.

Example 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:

  1. A file that describes, in English, what each one of your supplemental features will do. Give a full description, including possible corner cases, but don't feel like you have to write a novel. A short paragraph or two for each supplemental feature will normally suffice.
  2. One or more UML class diagrams, created with a drawing tool. I use PlantUML, and would recommend it. But anything that can draw UML diagrams will do. You can google "free UML design tool" and spend a little time browsing your options.

    No matter what tool you use to draw them, these class diagrams should depict the key classes, methods, attributes, and relationships in your design. It is up to you exactly how much to show on each class diagram(s), and it is also up to you how much of the original Zork design to show on each diagram. You do not need to make a completely exhaustive series of class diagrams that shows every single method of everything, all the way back to Zork I in February. You do need to show whatever is necessary to document and communicate the design decisions you have made in this phase.
  3. Several UML sequence diagrams: These sequence diagrams should be created from a tool such as PlantUML (or websequencediagrams.com is also pretty good) showing the key interactions among objects and paths through the system.
  4. Canonical examples of your .zork and .sav file formats. These do not need to be super long or clever, and you will not be graded on their creativity. Their purpose is simply to document and define what the valid syntax for files will be in your Zork++ program.

To be crystal clear: your team will be turning in one submission for this group activity.

Turning it in

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.

We need help!

Send email with subject line "CPSC 240 Zork++ HELP!!!" and be sure to Cc: both your teammates!