comp314 2006-spring project 2 last modified: 2006-03-06 dsandler -------------------------------------------------------------------------------- West of the House You are standing in an open field west of a white house, with a boarded front door. There is a mailbox here. > LOOK MAILBOX It's an unremarkable mailbox. The door is closed; you can't see what's inside. > OPEN MAILBOX You open the little door to reveal a small white envelope. > LOOK ENVELOPE You can't see any ENVELOPE here. > TAKE ENVELOPE FROM MAILBOX Taken. Your score has increased by 1 point. > LOOK ENVELOPE It's addressed to "COMP 314 STUDENT." I guess that's you! > OPEN ENVELOPE There's a letter inside. > TAKE LETTER FROM ENVELOPE Taken. Your score has increased by 1 point. > INVENTORY You are carrying: An envelope (opened) A letter A laptop computer A highlighter A can of Mountain Dew You have 0 dollars. > READ LETTER In a flowing script, the letter reads: "Dear COMP314 student, Your next assignment, called ADVENTURE, is modeled after the game of the same name and its descendants (e.g. Zork [1]). You will develop a textual game for a single player which follows the text-based adventure game (or "interactive fiction" [2]) model. This project stresses a well-considered class and object hierarchy, forethought about the kinds of interactions between objects, and in general flexible design. The following document describes the general requirements of your implementation; in many cases, rather than a rigid specification for compatible implementations, you will be given the freedom to develop the solution you feel is most appropriately expressive of the given requirements as well as most adaptible to future requirements. As such, you should expect that additional requirements will be introduced during the course of the project. You should seek to develop a solution that can accommodate these (unknown) additions painlessly, if possible. Try to anticipate features that haven't been requested, but might be useful in developing an interesting and complex game. See the section on GRADING for how this aspect of the project figures into your evaluation. Finally, creativity is highly encouraged in this project. We hope to see clever puzzles, detailed virtual worlds, or engrossing adventures from each team! == 1. BASIC CONCEPTS == The following is a rough catalogue of the essential elements of the game universe you are asked to simulate. * The USER types a command (a single line of text, terminated by a newline) to interact with the game. Each command should result in an action performed by the PLAYER (an in-game entity; see below), or an error message if the command cannot be executed. For this assignment, no graphical user interface is required or expected; commands should be read from System.in and game text should be emitted to System.out. You will need to implement an input parser that is able to extract the important elements from the user's input. See REQUIRED COMMANDS below. * The PLAYER is one of many abstract entities in the game; other entities include ROOMS, EXITS, and other OBJECTS. The player has a name (a short string), a description (a longer string), and an inventory of objects and MONEY. * OBJECTS exist in the game alongside the PLAYER, and may be interacted with. Each object has a name and description. Many objects may be taken (added to the player's inventory, either from the player's location or from another container). Some may also be given to other entities in the game. Some objects may be USEd (see the section on REQUIRED COMMANDS). Some objects may contain other objects. * MONEY is sort of like an object (in that you may find it in the game and can TAKE it, adding it to your inventory), but it can be given and taken in partial quantities. (The particular currency is left to your team's imagination.) For example, you may have (in your player's inventory) six rupees; you might find two rupees on the ground, bringing your total to 8. You may wish to implement other "collective" items like this (such as a flagon of liquid which may be partially emptied or refilled). Money is the only such item required of your game. * ROOMS exist to give each non-room entity a location in the game. A room has a name and description; it also maintains a list of its contents and a list of available EXITS to other rooms. Some or all of this information may be unavailable to the player (e.g. if the room is dark or the player is confused). * EXITS take the player between rooms. Exits can be cardinal directions like "west", but they can also be arbitrarily named: "up", "inside", "window". See also the GO command below. * The CLOCK is an invisible counter that increments each time the player successfully executes a command (syntax errors or "I don't see that thing here" errors don't count). To increment the clock without doing anything in particular, the user may invoke the sleep command, "Z". The clock is important because it allows certain events in the game to be tied to time. For example, a seed might germinate into a flower after some number of ticks, or an NPC (non-player character) might become impatient if the player doesn't do the right thing in a short enough period of time. Every object which relies upon the clock should get a "turn" to perform some action (silently or otherwise) every time the clock advances. * There are a number of POINTS to be scored in your game. The user probably won't know a priori what will earn her points, but they should make sense in context of the "objective" of the game (if there is one). Example: > TALK TO Dan He's wearing his headset, on the phone with some important E-Voting types. You don't dare interrupt him. > EMAIL Dan You take out your Sidekick and shoot off a short email to Dan. Look at those thumbs fly! > Z You have received an email! > READ EMAIL From: Dan Wallach Subject: Meeting OK, I can meet with you this afternoon. Stop by in a few minutes. Thanks for making an appointment! EOF Your score has increased by 1 point. == 2. REQUIRED COMMANDS == As mentioned above, the user interacts with the game by using textual commands to make his player take actions in the game world. All commands should give the user some feedback describing what happened in response to the player's action; for example, LOOK should always show a description, or an explanation of why an object may not be seen; TAKE should always at least say "Taken."; USE should show an informative message about the result of using an object, or should admonish the user that the object cannot be used. Many commands will refer to a ; these commands will search the player's inventory and environs (in that order) to figure out what that refers to. is likely to be a substring match, so that both "CAN" and "PEAS" may refer to "A half-empty can of peas". If there is a can of peas and a can of corn, "CAN" is no longer sufficient to distinguish the objects; a command such as "LOOK AT CAN" will therefore be an error in this case. Example: > LOOK Kitchen It's a drab-looking kitchen with a tiny counter. It makes you want to order carryout. Contents: a can of peas a cantaloupe > OPEN CAN I don't know which 'CAN' you mean. > OPEN CAN OF PEAS Opened, with some difficulty. Some objects and situations might require more specific, context-sensitive commands; for example, you might LIGHT a TORCH (even though LIGHT isn't a command listed below). For the benefit of the user, all commands should be case-insensitive (even though many portions are written in UPPERCASE in this document for emphasis). Some commands might even require an *indirect* object. HIT TROLL might not be specific enough in a given situation; the user might need to type HIT TROLL WITH LAPTOP to move forward in the game. Your player must understand at least the following few basic commands. [Note: text in [brackets] is optional; text in is abstract and will be replaced by something relevant to the command.] LOOK (synonym: L) LOOK [AT] Should result in the 's description being printed. If the is omitted, the implicit target is the location of the player (a room). In some cases (a well-lit room, for example) the object's contents may also be revealed. Illuminated rooms should also reveal their available exits. Example: > LOOK Steam tunnel entrance, Will Rice old dorm <--- this is the name A single incandescent bulb illuminates the <--- the description tunnel's antechamber. The debris you see around you is inconclusive: was it left by other unscrupulous students (such as yourself), or by Facilities staff? You'd hope that the can of Lone Star was left by the former and that the coil of twisted-pair wire by the latter, but it's hard to say. There is a staircase here leading up, and an exit to the east. > LOOK AT CAN It is, apparently, the National Beer of Texas. You didn't go to high school in-state, so you have no idea what this "National" business is. It is empty. Note that the description above includes text describing the objects and exits in the room. You might also choose to explicitly list the contents of each room: > LOOK Steam tunnel entrance, Will Rice old dorm A single incandescent bulb illuminates the tunnel's antechamber. The debris you see around you is inconclusive: was it left by other unscrupulous students (such as yourself), or by Facilities staff? Contents: can of Lone Star coil of wire Exits: up As you can see, this is probably easier to implement, but quite a bit less expressive. Either way, if the contents of the room change (e.g. you pick up the can of Lone Star), the results of LOOKing around should change to match the actual state of the room. SAY Speak a particular phrase to no one in particular. SAY TO Speak a particular phrase to someone in particular. TALK [TO] Say nothing in particular to someone in particular. Z The "sleep" command. The player does nothing, and the clock advances one tick. [GO] Move the player from room to room along the path of an exit in the current room. That's right, this command might not even have the word "GO" prefixed! For example, the user may just type "WEST" and (if there is a westward exit) the player should move to the west. Simple directions must allow single-character abbreviations. Example: "WEST" may be abbreviated "W". The "simple" directions are west, east, north, south, up, down. TAKE (synonym: GET) DROP Move an object from your location to your inventory, or vice versa. Note: not every object needs to be take-able (some things are affixed to the room, or too heavy, or will bite!). GIVE TO TAKE FROM Move from the inventory of to your own inventory, or vice versa, if allowed by the game rules. For example, perhaps you can TAKE a pair of pants from a drawer, but you might not be able to TAKE a pair of pants from a person (!). Remember, might be (an amount of) MONEY. USE USE ON A kind of generic action command. Many objects may simply be used (like a magic wand), but for other objects it doesn't make sense; for example, you really can't USE a closed envelope, but you certainly can OPEN it. As implied by the above optional syntax, the USE command might also take an indirect object . Example: > USE WRENCH Use the Wrench on what? > USE WRENCH ON NUT With the additional leverage provided by the wrench, you successfully loosen the hex nut and the box opens. [One useful feature of many systems is progressive specification of ambiguous commands; for example, after the insufficient "USE WRENCH" command, the user might simply say "NUT" and the correct outcome would occur. This particular feature is optional in your game.] INVENTORY (synonyms: I, INV) List the contents of the player's pockets, satchels, socks, bandolier, pipe, etc. Your current amount of money and points scored should also be reported. Example: > INV You are carrying: composition notebook Pilot G2 gel pen printout of RFC 1951 Maruchan Instant Lunch (Chicken Flavor), unopened plastic spoon You have 15 dollars. You have scored 68 points. == 3. SPECIAL IN-GAME ITEMS == To ensure that your game is sufficiently complex and interesting, it must contain a number of items with pre-determined behavior. These items are listed below. You are not required to implement *exactly* the items we describe, but you must implement some kind of object with the same behavior. We extend this freedom so as to give you maximum freedom in creating a coherent game world. (For example, a MAGIC POTION might not make sense in a realistic simulation of your residential college. But it might make a great deal of sense in a *fantastic* simulation of same.) If you change the name of one of the required objects, tell us which of your objects represents the required one. If you're unsure as to whether your idea for an object meets one of these requirements, ask the course staff. 3a. GENERAL REQUIREMENTS Your game must include objects which exercise all of the commands described above. For example, you must include: - situations which require the use of money - objects which may be used (see USE above) - objects which may be taken from or given to other objects (e.g. this letter) - points which are awarded for "successful" steps along your way to completion of the puzzle(s) or other objectives in the game 3b. THE PANSY OF PERPLEXITY This special flower, when sniffed or smelled, emits a potent puff of pollen that causes the player to become disoriented and unable to walk straight. In particular, any attempt to use any exit will result in a *different* exit being taken instead (at random). The effect wears off after several ticks. (The player might not be informed that this disorientation has taken place until she first attempts to use an exit.) 3c. THE THIEF The original Zork contained a Thief, who wandered around the world and stole items from your inventory if you crossed paths (i.e. were in the same room at the same time). Your game will also have a Thief, a NPC that behaves as follows: - The Thief moves around the game world (randomly, or along a set path, as you choose). - If the Thief enters the room where the player already is (or the player enters the Thief's current location), the Thief may (with some randomness) steal some item(s) from the player's inventory. - There should be a way for the player to recover stolen items. Possibilities: by acquiring them directly from the Thief, i.e. by combat or for a fee; by finding and raiding the Thief's own cache. 3d. THE TIME BOMB There must be some item in the game with a time-based (well, clock-based) element. For example, a bomb with a fuse; a series of rooms full of quicksand; a comp314 project with a deadline. 3e. THE TARDIS There must exist some kind of vehicle or other object which is not a room and yet which must at some point contain the player. 3f. DARKNESS There must be an example of a room which is, or can be made to be, *dark*. When a room is dark, its exits and objects cannot be seen (are not shown when you LOOK). You should include some way to alter the darkness of a room (e.g. a TORCH). 3g. MATCHES A match can be struck, used to light other objects on fire for a limited time, and then burns out. You don't need a match, but you need something with the same properties: it can be used only once (or a small fixed number of times), and once it's used up, it's used up. It might even disappear entirely when this happens! == 4. WORLD DESCRIPTION FILE == The world you create in order to satisfy all of the foregoing requirements will be built up out of instances of classes you implement in Java. For example, you might have a "room" class, of which there will be several instances (Java objects) at runtime. You might also have a "thief" class (see 3c. above) that contains all the necessary logic to represent a single thief in the game. How will these objects be constructed and connected to one another? You might imagine a straightforward approach in which you write a main() function that constructs all the objects necessary for your game, gives them names and descriptions where necessary, and attaches them to one another appropriately. Your project will not work this way. Instead, the particular configuration of the game world will be specified in a "world description file" which your program will consume at startup. Your program is now more of a "game engine" than just a single game. In fact, it should be possible to play multiple games with your program, given multiple different world description files! (You are required to submit only one such file, representing a single world.) The format of this "world description" file is UNSPECIFIED. (You have complete freedom to define it, though it must not simply be Java object serialization, e.g. ObjectOutputStream.) == 5. FINISHED GAME REQUIREMENTS == You must submit: * the Java source to a game of your own invention * a world description file representing your game (for use with your compiled Java game code) * a README, as with other 314 projects. It must include - instructions on how to run the game, as usual - a short (one or two paragraph) synopsis or abstract of the game. What's the story about? You don't have to spoil the "ending" (if your game has one), but we should be able to get an idea of what we're in for. * a WALKTHROUGH: a text file showing a transcript of one complete play-through of the game, including any and all commands sent and responses emitted, that demonstrates all the required features of the game and anything else you want us to see. (You might add a feature to your Java code to make it easy to record such a transcript.) The walkthrough is important: If you implement something you want us to see, but don't include it in the walkthrough, we may not ever discover it (and so you won't receive points for it). We will play your game interactively to test its behavior, and we'll rely on the walkthrough to help us advance through your game and explore your world. The theme and/or style of the game is left entirely open to your imagination. However, woven into your game world must be a kind of story or puzzle that, when completed correctly, results in points awarded to the player. One idea might involve a number of special objects that must be collected in order to "win"; each object would then award a point upon collection. (This is how one won the original Zork game.) There may be more than one independent puzzle; we look favorably upon cleverly tangled storylines. Your game need not have an "end", but from a storytelling standpoint it's probably a good idea. One of the challenges of this project is that you are provided no code to start from. A virtual world lends itself readily to object-oriented design, and an important part of the project is the careful design of a class hierarchy that effectively and efficiently represents your game world. Another great challenge of this project is its scope. It is easy to design a small game which unimaginatively meets all the requirements set out in this document; this will be bad for your score. It is also easy to get carried away, and to design an enormous, intricate, impossibly complex world that requires many person-hours to play and many more to implement; this will be bad for your stress level. (Also, you don't want the labbies to get bored playing your game!) == 6. GRADING == The comp314 grading rubric applies to this project. The requirements, as stated above, must all be present in one form or another for you to receive complete marks for "correctness". Your system design will be scrutinized, so think carefully about your classes and the way they interact. It is appropriate to paraphrase Einstein here: make things as simple as possible, but no simpler. As discussed earlier, additional requirements will be introduced as the project progresses. Failure to complete these additional requirements WILL NOT LOWER YOUR SCORE! Completion of the additions will add "cool points" to your total grade. It will benefit you greatly, then, to anticipate possible additions and to generally build a flexible system. In addition, there may be additional cool points given to "Judges' Choice" awardees on the basis of creativity, cleverness, entertainment value, quality of writing, etc. The awards will be entirely discretionary and will involve a panel of judges including, but not necessarily limited to, the teaching staff. Because of the somewhat "fuzzy" nature of some of these specifications (especially as compared to other COMP314 projects), you should have lots of questions about the behavior of the game. Post these questions to the newsgroup or to IRC and we will answer them publicly for everyone's benefit. Good luck, and happy adventuring. == 7. REFERENCES == 1. Lebling, P.D. and Blank, M.S. "Zork: A Computerized Fantasy Simulation Game." IEEE Computer, April 1979. http://www.csd.uwo.ca/Infocom/Articles/ieee.html 2. Wikipedia (article): Interactive fiction. http://en.wikipedia.org/wiki/Interactive_Fiction Signed, ---The COMP 314 teaching staff" Your score has gone up by 10 points. # vim: sts=4 et tw=78: