Zork++ phase 3

For Zork++ phase 3, your team will fully implement (code) and debug your game engine's supplementary features. You'll be code complete. Yay!

I will obviously not post a test .zork file that is compatible with your supplementary features, because this is the point where every team's project is going to diverge from the others — different features will often result in different syntactic elements in the dungeon file.

Deliverables

In addition to working code (duh), there are three files I require, all of which should be put in the "files" directory of your git repo:

A plain-text file called "featureList.txt". This file should list of all your supplemental features, along with idiot-proof instructions for how I can see them in action in your phase 3 dungeon. (Note that you can and should use vim to edit this file, just like you do to edit .java, .zork, and .sav files.)

Here's a sample excerpt from a fictional featureList.txt file, to show you what I'm looking for:

Light -- Some rooms are completely dark to the adventurer unless he/she has a light source 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 number of turns to how long they last before burning out. You can test light in sampleDungeon.zork by grabbing the lavaLamp in the ChillaxinRoom (n,w,w from the entry), then going to the ManCave (e,s,e,e from ChillaxinRoom). The ManCave will be dark upon entry. Type "switch lavaLamp" to turn it on, at which point you will see the ManCave room description. Type "switch lavaLamp" again to go back to darkness. Type "switch lavaLamp" a third time to turn it back on, then waste time by going w,e,w,e,w,e,w,e,... a total of ten times (ten "w,e" pairs). At that point, the lavaLamp will be burned out, and the ManCave will once again be dark. ----------------------------------------------------------------------------- Rotate room -- To test this feature, ...

A file called literally sampleDungeon.zork that contains a complete dungeon that exercises all your supplemental features.

A plain-text file called sampleDungeonWalkthrough.txt, which will be a walk-through description of how to win your sample dungeon. It should explain in sufficient detail which commands to execute in which order to win the game from your dungeon's starting state. This file must be understandable by a child who reads at a 9th grade level.
For example:

sampleDungeon.zork Walkthrough 1. Start in the Entry room 2. Go w to the Kitchen 3. Take the Bread and the Jam 4. Eat the Bread ("eat Bread") 5. Type "score" and "health" to verify that you have earned 5 points and that your health is at maximum 6. Go n to the Torture Chamber 7. Touch the IronMaiden ("touch IronMaiden"). This will trigger a teleport event, sending you to the Garage. 7. Go u to the Attic 8. Spread the jam on the ViolinCase ("spread Jam") 9. This should trigger a win!

Making your game determinstic

Note that your dungeon will contain random components that make each play of the dungeon different. (At the very least, your teleport event(s) will put the adventurer in a random location each time. Also, NPCs may choose to move to different rooms, combat may resolve differently, etc.) You will want to make this deterministic for purposes of testing, so that your walk-through will always "work" in the same way. To accomplish this, your team should do the following in your game engine:

Make sure you only instantiate one java.util.Random object over the entire run of the program. The easiest way to do this is to make an instance variable of type Random in your GameState class, initialize it in the GameState constructor, and in every place where you need to roll a random number, access that Random object and call .nextInt() or .nextBoolean() or whatever to do so.

Immediately after instantiating the Random object, call ".setSeed(13)" on it. (If you don't like the number 13, substitute any other number you do like.)

After doing this, you should discover that your game runs the same way every time you play it.

Turning it in

To turn in this assignment, one team member send an email to cpsc240submissions@gmail.com with subject line "CPSC 240 Zork++ phase 3 turn-in", Cc:'ing the other team members. There should be no attachments, and the body of this email should simply say, "Have at it, Stephen!" I will clone your github repo to read your featureList.txt and sampleDungeonWalkthrough.txt, and to test your latest committed-and-pushed code.

"Zork++" phase 3: supplemental features implementation

Zork++ phase 3

Deliverables

Making your game determinstic

Turning it in

I need help!