Challenge: Interactive Fiction
Interactive fiction (IF) games, also known as text adventures, are computer games in which you must rely on your imagination to provide the visuals. They represent one of the longest-lived forms of computer entertainment. Originating in the 1970s, they reached their zenith in the 1980s, with classic Infocom games such as Zork and The Hitchiker’s Guide to the Galaxy. At their best, interactive fiction games offer rich interaction, engrossing storylines, and phenomenal writing. While most gamers have moved on to more graphically rich games, there remains a strong community of interactive fiction writers and players to this day.
I’ve always loved interactive fiction. Like most people who got into programming young, as a teenager I first taught myself to program in order to write my own games. The very first program I ever wrote was a tiny text adventure game, written in the REXX programming language.
While I’ve since moved on to writing other kinds of software, I still think writing interactive fiction engines is a great way to get a feel for a new language. Unlike many canned programming challenges which primarily test your knowledge of pure computer science concepts, writing a text adventure game exercises many skills which translate directly to typical real-world applications.
In order to write a successful IF engine, you must deal with challenges such as:
- Modeling the interactions of real-world objects (such as rooms, items, and players) in software.
- Interpreting a Domain-Specific Language (DSL) in order to load games.
- Dealing with unpredictable user input.
Writing an IF engine is a fun way to learn how to tackle these problems in a new language, and the skills you come away with can be applied directly to a wide array of applications.
In this challenge, you’ll implement an interactive fiction game which mimics the first few rooms of the grandaddy of all text adventures, Collossal Cave. In order to succeed, your program will need to read in a “story” in the form of a simple DSL, interpret user commands, and track the player’s progress and inventory. If you get all that working without too much trouble, I’ve also included an “extra credit” challenge to implement basic “puzzle” functionality in the game.
Here’s a sample interaction with a finished implementation of the challenge:
$ bin/play.rb data/petite_cave.if You are standing at the end of a road before a small brick building. Around you is a forest. A small stream flows out of the building and down a gully. > north There is no way to go in that direction. > east You are inside a building, a well house for a large spring. There are some keys on the ground here. There is food here. There is a shiny brass lamp nearby. There is a bottle of water here. > get keys OK > get food OK > get lantern OK > get water OK > inventory You are currently holding the following: Set of keys Tasty food Brass lantern Small bottle > west You're at end of road again. > s You are in a valley in the forest beside a stream tumbling along a rocky bed. > s At your feet all the water of the stream splashes into a 2-inch slit in the rock. Downstream the str eambed is bare rock. > s You are in a 20-foot depression floored with bare dirt. Set into the dirt is a strong steel grate mo unted in concrete. A dry streambed leads into the depression. > unlock grate The grate is now unlocked > enter You are in a small chamber beneath a 3x3 steel grate to the surface. A low crawl over cobbles leads inward to the west.
Here’s a sample of the story DSL which defines the adventure:
Room @end_of_road: Title: at end of road again Description: You are standing at the end of a road before a small brick building. Around you is a forest. A small stream flows out of the building and down a gully. Exits: east to @building enter to @building south to @valley Room @building: Title: inside building Description: You are inside a building, a well house for a large spring. Exits: west to @end_of_road exit to @end_of_road Objects: $keys $lamp $food $water_bottle
Object $keys: Terms: Set of keys, keys Description: There are some keys on the ground here. Object $lamp: Terms: Brass lantern, brass lamp, lamp, lantern Description: There is a shiny brass lamp nearby.
The full story file can be found at
data/petite_cave.if. This format is
one I’ve invented for this challenge. There is no formal specification for
it. Your program is only required to be able to parse the provided file
petite_cave.if in order to satisfy the challlenge.
Here are steps for getting started on your entry:
- Clone the Github project avdi/rpcfn-interactive-fiction:
git clone git://github.com/avdi/rpcfn-interactive-fiction.git
- Install Cucumber, if you don’t have it already:
gem install cucumber
- Run the acceptance tests by running Rake:
cd rpcfn-interactive-fiction; rake
You should see failure messages. That’s because the implementation hasn’t been written yet! Making the tests pass is up to you.
- I’ve provided a skeleton
bin/play/rbto start you off. Edit that file to implement your interactive fiction engine.
- Drive your development by running
rakeperiodically to see what’s left to implement.
- Make sure to manually test your implementation by running it standalone:
ruby bin/play.rb data/petite_cave.if
If you want an extra challenge, run
and write code to make those tests pass as well. In order to make the extra credit features work, your engine will have to evaluate arbitrary scripts from the story file in order to implement guard conditions and custom actions.
The code executed by the guard/action part of the story file expects a simple API to be made available by your implementation:
#blackboardshould return a hash. The blackboard is a place for story scripts to stow arbitrary story-specific values.
#player_in?(room_id)should return whether the player is in the specified room.
#player_has?(object_id)should return whether the player has the specified item in their inventory.
- Exit guard clauses return an
Arrayof [ALLOW, MESSAGE]. ALLOW is a boolean indicating whether the player’s attempt to exit the room was allowed. MESSAGE must be shown to the user if provided.
- Action scripts return an
Arrayof [MESSAGE, BLACKBOARD]. Message must be shown to the user if non-nil. The values in BLACKBOARD should be merged into the
You may find it helpful to define these methods in the class
Game and then
execute the story scripts in the context of your Game object using
The reason story scripts do not directly set values in the blackboard is so
that it is possible to implement story script execution inside of $SAFE
jails. For extra, extra credit, write your implementation so that all story
scripts are executed under
$SAFE level 4.
- You must use only Ruby standard libraries in your implementation.
- Your entry must at minimum pass the tests in
- Your entry must be capable of running as a standalone executable. It must
accept a single argument, the path of the story file. E.g.:
ruby bin/play.rb data/petite_cave.if
- Your entry must run under Ruby 1.8.7. If it runs under 1.9 as well, all the better.
There are a number of potential ways to go about parsing the story DSL:
- You could write a basic recursive-descent parser.
- You could use regular expression methods, like =String#scan=
- You could use Ruby’s standard StringScanner library
- You could use regular expression substitutions to convert the text into valid Ruby code, and then =#eval()= the story definition.
Feel free to contact me if something about the challenge is unclear. Good Luck, and happy hacking!