Zorkington

zork west of house

Zork was not the first text adventure game, but it was the first to achieve commercial success.

In this project, you will create a version of Zork born from your own beautiful mind. In our example case, it's one that takes place in the faraway kingdom of Burlington, Vermont. Feel free to use it as well :)

Links

Goals

  • utilizing functions, methods, and objects for a deeper understanding of encapsulation.
  • understand state and state transitions, which are useful in many areas, e.g.
    • photo carousel
    • buttons, menus, other widgets
    • parsers
    • network protocols

Design

Your code will need to represent (or reify) several distinct states, including:

  • current room
    • room descriptions (immutable)
    • room connections (immutable)
    • room inventory (mutable)
  • current player
    • player inventory (mutable)
    • player status (mutable) (hungry, tired, etc.)

Think about appropriate data structures for each of these. Note that you do not need to write code for these until you are actually implementing a story that requires them, but it is good to make a rough plan early on, to anticipate pitfalls and estimate how difficult upcoming stories will be.

Remember to refactor. Sometimes a data structure that works well for the simple case will need to be altered to work for the general case. In this project, the app will grow (more rooms, more commands) from story to story and your data structures should change to accomodate.

If you are not comfortable using classes, constructors, and objects you may save state in global variables like this:

let currentRoom = null;

function moveToRoom(newRoom) {
  if (canMoveToRoom(newRoom)) {
    currentRoom = newRoom;
  }
}

Note: Using functions, global variables, and logical statements may work for a simple version of this game, however it will be much, much harder to scale up than if you use objects.

You may want to create a State Machine to represent potential room transitions.

And Don't Forget to Demo!

After implementing a story, before starting work on the next story...

  • Ask a teacher or fellow student if they have time to "play client" for a demo
  • Launch the program and let the client use it
  • The client should try to prove that the program does what the story says it's supposed to do
  • If the client rejects your story, keep coding until it works right, then do another demo

And during the day, take breaks, find other student teams and play each others' games!

Stories

Note: These stories build off of the Design section above. While the stories provided are meant to implement those concepts, artistic liberty in how these stories manifest is ultimately yours. If you're unsure if an idea or mechanic will fulfill a certain story, ask your instructor.

One Room

When the user launches the program

Then the console displays introductory text

182 Main St.
You are standing on Main Street between Church and South Winooski.
There is a door here. A keypad sits on the handle.
On the door is a handwritten sign.
>_

(The chevron-and-underscore represents a prompt; the user should be able to type into it.)

And waits for input

And if the user types an unknown command

Then the game should output "I don't know how to ____" (or something similar)

>_gargle
Sorry, I don't know how to gargle.

Hint
Since you're going to want to display the prompt over and over again it might make sense to put it inside a loop

while(answer !== 'exit') {
  answer = await ask('>_ ')
}

Read the sign

Given the player has been given introductory text

When the player enters a valid interactive command

Then the game should output accordingly

>_ read sign
The sign says "Welcome to Burlington Code Academy!
Come on up to the third floor.
If the door is locked, use the code 12345."

And puts the player in the starting room

And returns to the prompt

Hint
You could do this with nested logic statements, however that will get complicated fast. Instead you may want to make your items objects with properties and methods.

let sign = {
  description: "Welcome to Burlington Code Academy! Come on up to the third floor.\nIf the door is locked, use the code 12345."
  read: () => {
    return this.description
  }
}

Don't take the sign

Given the player is in the starting room

When the player attempts to take something

Then the game denies the player

>_take sign
That would be selfish. How will other students find their way?

(assume " And returns to the prompt" after this and all future stories)

Blocked

Given the player is in the starting room

When the player attempts to enter a new room

Then the game denies the player

>_open door
The door is locked. There is a keypad on the door handle.

Speak friend and enter

Given the player is in the starting room

When the player enters a correct password

Then the game allows the player to enter

>_enter code 12345
Success! The door opens.
You enter the foyer and the door shuts behind you.

And the player enters a new room

Unauthorized Access

Given the player is in the starting room

When the player enters an incorrect password

Then the game denies the player to enter

>_enter code 00000
Bzzzzt! The door is still locked.

And the player remains in the starting room

Foyer

Given the player is in the next room

Then the game displays a description, with at least one item in said description

You are in a foyer. Or maybe it's an antechamber. 
Or a vestibule. 
Or an entryway. 
Or an atrium. 
Or a narthex. 
But let's forget all that fancy flatlander vocabulary, and just call it a foyer.
In Vermont, this is pronounced "FO-ee-yurr". 
Anyways, it's definitely not a mudroom. 
A copy of Seven Days lies in a corner.

Inventory

Given the player is in the next room

And the player has not yet picked up the described item

When the player enters a command to pick it up

Then the game allows the player to do so

>_take paper
You pick up the paper and leaf through it looking for comics 
and ignoring the articles, just like everybody else does.

And the paper is added to the player's inventory

Display Inventory

Given an item is in the player's 'inventory'

When the player types i or inventory or take inventory

Then the game displays the player's inventory You are carrying: A copy of Seven Days, Vermont's Alt-Weekly

Drop Inventory

Given an item is in the player's inventory

When the player types drop <ITEM>

Then that item is removed from the player's inventory

>_drop paper
You drop the paper

And that item is added to the current room's inventory

More rooms and more stories, e.g.

  • when you unlock a room it should stay unlocked

  • additional interactive commands

    • read seven days
    • go upstairs
    • look outside
    • etc.
  • Additional inventory-based events

    Examples:

    • Bob speaks gibberish until you get him a cup of tea from Muddy's. then you can attend lecture or sit down or some other command to attend class
    • You get hungry (status) which makes your stomach growl before every prompt. Buying and eating a slice of pizza at Mr. Mike's removes the status
    • You need to grab the bathroom key from the classroom and use it on the locked bathroom door.
    • Cheat code! xyzzy

Please write stories for each of these features before implementing them.

Icebox

  • Status line (showing room name)
  • Web User Interface for the game
  • write a word wrapping function and use it to format all output