CS 112 - Introduction to Computer Science II Homework #10

NOTE: This work is to be done in groups of 2-3.  This means that each team will perform one submission with all team names and studentIDs listed in the README file after the honor pledge.  Although team members can divide work, each team member should be able to informally present all work of his/her teammate.

Design Project: Interactive Fiction

In the coming weeks, you will design a simplified interactive fiction system.

What is Interactive Fiction?

Interactive fiction (formerly known as text adventures; similar to multi-user dungeons/domains (MUDs)) is a form of entertainment in which a user interacts with and learns about virtual world, usually to achieve a goal.  We will restrict our attention to the genre formerly known as text adventures where all interaction with the world is through a text-based interface.  Browse the following links for a quick introduction to the world of interactive fiction:

• Brass Lantern - Beginner Resources
• Play Infocom Games Online - Try the following commands in Zork I to get started:
• open mailbox
• get leaflet
• read leaflet
• n (north)
• e (east)
• open window
• enter window
• u
• e (Enter this command repeatedly until... Oops! Sorry!)
• quit
• y

• USA mirror of IF archive
• Instructions for access to an IF server
• Emacs also has a built-in text-adventure.  To start it, the command is "M-x dunnet".

Specification:

Your interactive fiction system will feature at least six (eventually) reachable locations, two obstacles (objects which prevent some action, including movement), two items which, when used with the obstacles (or other objects), will allow the player to overcome the obstacles, a goal (explicit or implicit), and an indication when that goal has been reached.  Your interactive fiction system should behave similar to the ones featured above, in that:

• the game is turn-based,
• each turn, the user's environment is described (preferably a brief description unless the user has just arrived for the first time or typed "look" as a command),
• the user can enter simple case-insensitive commands including the minimal subset below:
• (i)nventory (allowed abbreviation in parentheses)
• (n)orth, (s)outh, (e)ast, (w)est, (u)p, (d)own (optionally preceded by the word "go")
• look - describe environment
• examine <object> - give detailed description of an object
• get <object>
• drop <object>
• use <object> with <object>
• restart
• quit

Deliverables:

• Documentation of your entire design process (including meeting times, correspondence).  Be sure to credit the individual contributions of each group member.
• A complete working implementation with a text file demo.txt which has commands which can be fed to standard input to demonstrate your IF system.
• Support of command line option -e (for echo) which causes your program to print the command the user just entered.  This is particularly useful for making sense of transcripts when the input source is a file: cat test.txt | java ____ -e > transcript.txt; more transcript.txt

This previous command feeds the contents of the file to your java program which echoes the input you can't see otherwise.  The output of your program is redirected to an output file transcript.txt.  This is then paged through using the more command.
• Comment your code for Javadoc generation.  Note that C-c C-v j will generate part of the comments for you automatically when your cursor position is at a class/method declaration.  M-q will reformat multi-line comments easily, but be sure to separate with a blank line comments you do not wish to reformat.  M-_ is the undo command (which can be done multiple times in succession to undo substantial changes).
• You should generate javadoc pages as described in Horstmann.  Place the generated documentation in your public_html web space.  Change permissions to make it publicly accessible: chmod -R a+rw ~/public_html  (Be sure to supply the location in your README file.)
• Expect to make a brief (10 minute) presentation of your design work in class on Friday 12/1 with a prototype demo that shows the ability to:
• move different places,
• pick up objects,
• and put down objects.

Rough time line:

• Monday 11/20: read assignment, familiarize yourself with interactive fiction before class next Monday.
• Monday 11/27: choose classes, start javadocs with empty methods, start implementation.
• Wednesday 11/29: make adjustments to design as necessary, continue implementation, plan significant work time(s)  to bring the necessary parts together for demo testing/debugging.
• Friday 12/1: partial project demos in class (see above), should have most of implementation complete at this time.
• Wednesday 12/6: course evaluation in class, implementation should be complete, should only be testing, debugging, refining at this stage.
• Friday 12/8: turn in completed project (double-check deliverables above) with deep satisfaction, demo completed projects.