DOC PREVIEW
Stanford CS 106A - Adventure-contest

This preview shows page 1 out of 4 pages.

Save
View full document
View full document
Premium Document
Do you want full access? Go Premium and unlock all 4 pages.
Access to all documents
Download any document
Ad free experience
Premium Document
Do you want full access? Go Premium and unlock all 4 pages.
Access to all documents
Download any document
Ad free experience

Unformatted text preview:

Eric Roberts Handout #58CS 106A February 26, 2010Adventure ContestDue date: Friday, March 12, 5:00P.M.Assignment #6 requires you to build a minimal Adventure program. In terms of features,it has about as little as you can get away with and still have a chance to construct datafiles that allow it to play even mildly interesting games. For the Adventure contest, yourgoal is to extend your Assignment #6 submission to be the most interesting Adventuregame you can create. To create your new game, you will have to change both theprogram and the data files. You are free to incorporate parts of the Crowther cave, butyou will be judged only on the material you add. The most exciting and playablesubmission wins.For the purposes of the contest, it is acceptable to abandon the principle that programs ofthis sort should be entirely data-driven. In Will Crother’s original Adventure game, theFORTRAN program included highly specific code to implement most of the operations.In particular, each of the action verbs was associated with a section of code that explicitlytook care of each possible situation. If the player typed in WAVE, for example, theprogram would explicitly check to see what object was being waved and whether theplayer was standing in a particular room. If the right conditions applied, the programwould take whatever actions were necessary to update the state. For your contest entry,you should feel free to do the same thing.Possible extensionsThe following extensions would make the Adventure program much more powerful andwould allow the construction of more interesting games:• Active objects. The biggest weakness in the current game is that the objects areentirely passive. All you can do with an object is to pick it up or drop it. Moreover,the only way in which the objects enter into the play of the game is in the specificationof locked passages in the room data file: if you’re carrying an object, some passage isopen that would otherwise be closed. It would be wonderful if it were possible to typeWAVE WAND or UNLOCK GRATE and have the appropriate thing happen. Moreover, beingable to READ or EXAMINE an object adds a lot of interest to the game.• Permanent objects. Many objects such as the metal grate are in fixed locations. In theAssignment #6 version of the game, these features are part of the room description andnot part of the object or vocabulary files. This situation leads to silly exchanges likeYou are in a 25-foot depression floored with bare dirt.Set into the dirt is a strong steel grate mounted inconcrete. A dry streambed leads into the depression fromthe north.>TAKE GRATEI don't know the word 'GRATE'.>It would make far more sense if the grate were an object that could not be taken.• Object state. In the original version of Adventure, objects can have different states.For example, the grate at the entrance to the cave can be either locked or unlocked;similarly, the snake in the Hall of the Mountain King can be blocking your path ordriven away. You might add some way to allow the program to keep track of the stateof each object and then make it possible for the motion rules to indicate that a– 2 –particular passage can only be taken if an object is in a certain state: you can gothrough the grate only if it is unlocked.• Containment. In Don Woods’s extension to Adventure, some objects can contain otherobjects. Putting this concept into the game adds dimensionality to puzzle construction,but also requires implementing prepositional phrases in the parser so that the programcan parse such constructions as>PUT NUGGET IN CHEST• Filler words. The current parser limits the player to using commands that consist ofone or two words. Saying>TAKE THE KEYScauses an error because the program doesn’t know the word THE; if the parser ignoredarticles and other filler words, the program would seem more conversational.• Adjectives. A similar extension to the parser is the introduction of adjectives thatallow the player to issue commands like>TAKE BLACK RODIn the classic Adventure game, adjectives are associated uniquely with the noun towhich they refer. In Zork, on the other hand, adjectives were used to differentiatemany different objects of the same time, so that there could be both a black rod and agreen rod in the same game.• Convenient shorthands for “all” and “it”. When you’re in a room with many objects,it is extremely useful to be able to type>TAKE ALLto take all the objects at the location. Similarly, the conversation flows more smoothlyif you can refer to the last mentioned object as IT.• Random passages. There are several rooms in the original adventure game at whichthe motion through a passage is probabilistic. You could implement this sort of featureby specifying a percentage chance on a locked passage rather than an object. Thus, ifthe data for a room specified the connection entriesSOUTH 17/30SOUTH 18moving south would go to room 17 thirty percent of the time and to room 18 the rest.(The program can differentiate this specification syntax from traditional lockedpassages because the percentage chance begins with a digit.)• Lazy evaluation of the rooms database. When the data file for the rooms is large—asit is with the Crowther files, for example—the adventure program can take a long timeto start up. That startup delay is not really necessary, because the rooms moduledoesn’t actually need to read the data all at once. It would work equally well to openthe data file and then to initialize all the rooms to a null object. Whenever the codecalled a function that required the actual data for a room, the AdvRooms class couldprocess the data file (presumably initializing other rooms in the structure along theway) until it got to the desired room. In programming, this strategy is called lazyevaluation.– 3 –• Room names. When writing the data files, it is hard to keep track of the room numbersunder the current design. It would be extremely useful if the data files instead usednames for the rooms, as in the following excerpt from a rooms data file:OutsideBuildingOutside buildingYou are standing at the end of a road before a small brickbuilding. A small stream flows out of the building anddown a gully to the south. A road runs up a small hillto the west.-----WEST EndOfRoadUP EndOfRoadNORTH InsideBuildingIN InsideBuildingEndOfRoadEnd of roadYou are at the end of a road


View Full Document

Stanford CS 106A - Adventure-contest

Download Adventure-contest
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view Adventure-contest and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view Adventure-contest 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?