CIS 490 Assignment 3 miscellaneous helpful hints (I will probably continue to build on this file and resend it every so often, so if you keep the last received version and compare it to a newly received version, you'll quickly see what's been added.) Hope this helps. Kirk R. Goodell KGOODELL@FORD.COM KOODLZ@AMERITECH.NET ---------------------------------------------------------------------- The Beginning Writer's Guide (ifbguide.zip): GOOD NEWS AND BAD NEWS: The good news is that it's only about 30 pages, and is a better place to start than reading the 300-page Designer's Manual. The bad news is that it's unfinished! The author gave up about half- way through. He didn't get to Routine Comparisons and Loops, Embedded Routines, Grammar, Verbs, or The Parser. But from what I've read of it so far, it will still save many hours of studying the 300-page manual! Unzip this file into its own directory. You will end up with several HTMLs, GIFs, and BMPs. Double-click on CONTENTS.HTM to start up the Beginning Writer's Guide in your browser. All sections are hyperlinked from this table of contents (except for the last few sections, which are missing!) This is preferable to printing all the sections, because you can jump around and search for stuff. I recommend creating a shortcut to CONTENTS.HTM on your desktop. (DON'T drag the actual file to your desktop; it won't be able to hyperlink to the rest of itself, since it's not all on the desktop!) ---------------------------------------------------------------------- Inform Designer's Manual (various file names): You can download various formats: HTML ASCII text TeX (UNIX) various PostScript formats etc. BUT, since the manual is approximately 300 pages, I recommend using the online version of the manual that installs with the Inform Compiler/Interpreter: After the installation is done, go to C:\\hlp (default is C:\Program Files\InformInstall\hlp). Double-click on INFORM.HLP and a Windows Help version of the manual will come up. I recommend creating a shortcut to INFORM.HLP on your desktop. I also recommend setting Options->Font->Large! Warning: You may also want to download the text version for searches, since the "search" capability in the Windows Help version leaves a LOT to be desired! ---------------------------------------------------------------------- Getting Started: The easiest way to use the Inform Compiler/Interpreter is by putting all necessary files into the same directory and not having to rely on any environment or path settings. Here's how: After installing the Inform Compiler/Interpreter, go to its base directory (the one containing the BIN, HLP, LIB, and SAMPLES directories) and create a directory of your own, say MYGAMEDIR. Into MYGAMEDIR, copy all files from the BIN and LIB directories. Create your .INF file, say MYGAME.INF, in the MYGAMEDIR directory. To compile, do "INFRMW32 MYGAME" (.INF is implied). This creates the file MYGAME.Z5. To execute, do "WINFROTZ MYGAME.Z5" (The .Z5 extension is REQUIRED.) You can set up Windows to launch WINFROTZ upon double-clicking a .Z5 file, but I find working from a command prompt in my game directory to be easier. ---------------------------------------------------------------------- Inform tutorial "Alice Through the Looking Glass" (tutorial.htm): This is a fairly quick and straightford tutorial (about three hours), IF you read the Beginning Writer's Guide first, AND if you give it your undivided attention, AND if you refer to the notes below when you get confused (it's tricky stuff). I recommend printing ALICE 2.INF and ALICE3.INF to refer to as you go along. Notes on interpreting some "tricky" parts: Note 1: "self" in an "Object" refers to the object itself, Not to the user! For example, if the object is enterable, like the mantelpiece, and the condition "if (player notin self)" is encountered, this doesn't mean you're beside yourself (pun), it means "if the player is not in (on) the mantelpiece". It's a shorthand notation, like "this" in C++. Note 2: "has" for an object can be thought of as "has the following attributes:". Note 3: The "general" attribute had me going for a minute, as well. The author's first couple of examples of using "general" aren't very clear, but I finally figured out that it's just a logical flag attribute. For example, if the chair is moved near the mantel (a necessary prerequisite for getting on the mantel), the chair object is given the "general" attribute , and if the chair is moved away from the mantel, the "general" attribute is taken away from the chair (via "give self ~general" -- "self", in this case, being the chair, and '~' being "NOT", as in C code.) In this way, the chair's "general" attribute can be checked to see if Alice can get onto the mantel from the chair, i.e., only if it's near the mantel! Note 4: I found the following VERY confusing until I figured it out (I suppose I could have looked it up in the Inform Designer's Manual, but that would have been too easy!): In section 5.8 (page 9), the author defines a new action: Verb "roll" "untangle" "wind" * noun -> Untangle * "up" noun -> Untangle * noun "up" -> Untangle; I couldn't make head nor tails of this, even in the context of "Object worsted", which the author shows next. (This is probably one example of why the author states that reading the complete Inform Designer's Manual is a prerequisite to the tutorial (yeah, right!)). I finally figured it out, though: the '*'s (which I at first thought were "comment" or "continuation" markers, are actually "wildcard" markers! So what the new action is really saying is that, if you place any of the verbs in place of the '*'s, and if the resultant string is what the user typed, then execute the "Untanlge" action. For example, taking the last line of the action, if the user typed "roll worsted up" or "wind worsted up", then the engine would execute "Untangle" and say, "You're as quick as can be ... (etc)". There is a correspondig "UntangleSub" near the beginning of the .INF file, which handles input like "roll up cat" by saying, "What curious ideas you have!", but I have no idea (yet) how the engine knows when to execute this action; it's NOT included in "Object worsted". I think somehow it's called by default if the "Untangle:" case fails to arrive at a satisfactory conclusion. Note 5: Section 6. Testing, part 1, 3. (page 10): The author says, "(see the Verb Library for details)". This is pretty vague; I still haven't found a section entitled "Verb Library" any- where in the manual. What the author is trying to say is that the default action for a verb may not be what you want it to say or do. Since the conditions in the mantelpiece object for "Climb" strictly check for conditions PREVENTING climbing, none of them hold true if the chair is close to the mantel, Alice is on the chair, and she is not holding anything. Since none of the explicit conditions are true, the default action for "Climb" is taken, which is to say "I don't think much is to be achieved by that." HINT: look at "A9. Library message numbers" in the online help. Note 6: Section 6. Testing, part 1, 4. (page 10): The author says that the solution for #3 solved this as well. It took some digging to discover that "get on" is interpreted as "Enter", and you can see in the mantelpiece object that "Climb" and "Enter" are handled identically. The clue here was to search "A9. Library message numbers" for the response "But you're already on the" to find out that "Enter" was the action being taken. It said "arm-chair" because that is the object you were on when the default "Enter" action was taken. Note 7: Section 6. Testing, part 1, 6. (pages 11-12): Things get weird in this last part of Section 6. Just keep in mind that user input is usually in the form "verb [noun] [with/to/from/on/etc.] [second]" where "second" is an optional second noun. First, if there is no noun, go to the object of the "enterable" thing you are currently in, else go to the object of the noun. Now try to completely process the verb in that object. If not done, proceed to the object's parent object, and try to further process the verb there. This is VERY general, but it should help get you through the tutorial. ---------------------------------------------------------------------- ERRATA: Inform tutorial "Alice Through the Looking Glass" (tutorial.htm): * Section 5.4 The rug: a complex object, paragraph 2 (page 6): Says "Appendix A7 of the Designer's Manual lists all the actions that the library knows...". It should say "Appendix A8..." * Section 6. Testing, part 1, 5. (page 10): If you run this yourself, the first time you say "look under rug" you will get the response "You lift up a corner of the rug and, peering underneath, discover the red queen from the chess set." Every time after that, you will get the response "You find nothing of interest.", just as the author states. The reason for this is quite clear, once you examine the rug object's "general" attribute. * Section 6. Testing, part 1, 6. (page 11): Where the author says "Alice can climb onto the mantelpiece, and..." he starts debugging the mantelpiece sequence: > enter mantelpiece You scramble up onto the mantelpiece. That is what you see if you're running ALICE3.INF, OR if you've applied the fixes to ALICE2.INF that the author proposed in step 3. However, if you're running the original ALICE2.INF, you'll get: > enter mantelpiece (getting off the arm-chair) You get onto the mantelpiece. which is OK anyway, since it allows us to proceed to the next bug. (Although I can't quite figure out where this exact phrase comes from...) Two statements further, the author says you get this sequence: > get on chair But you're already on the mantelpiece. But running the original ALICE2.INF, you'll get: > get on chair (getting off the mantelpiece) You get onto the arm-chair. which seems OK to me, so I couldn't reproduce the error which the author is trying to describe here. (Again, I can't find the source of this exact response terminology, but the point is, the author claims that "get on chair" doesn't work in ALICE2.INF, when in fact it does.(?)) Two statements further, the author says you get this sequence: > get off You are on your own two feet again. But running the original ALICE2.INF, you'll get: > get off You get off the mantelpiece. The end result appears to be the same, so maybe this is just two different random messages for the same event, although I always got the second one every time I ran it. I guess the point the author is trying to make here is that Alice should not be allowed to jump from the mantelpiece all the way to the floor; she must use the chair. ---------------------------------------------------------------------- !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! ! This is my patented Triple-Action Object (TAO) methodology for ! constructing an Inform Engine text adventure without needing to ! learn any obscure or tricky Inform programming constructs. ! ! Almost every location which the player may visit is represented by ! three separate objects, using the following naming convention: ! ! (1) Descriptor ! (2) ! (3) InDescriptor ! ! where is the name of the place that the player may visit, ! such as "Building". The format of each of the three objects is shown ! below, followed by the reasons for their existence. ! ! (Some enterable locations and all non-enterable objects only use one ! or two of these object types, depending on the particular gaming ! characteristics needed by that object.) ! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! ! ! (1) Object Descriptor ParentObject ! has concealed, ! with name "words" "referencing" "location's" "exterior", ! description ! "This is the description that you get if you examine ! this location from outside (from the ParentObject)."; ! ! (2) Object "In " ! with name "obvious" "unimportant" "stuff" "seen" "here", ! description ! "This is the long description given the first time the ! player enters this location, or when the player types ! 'look' while at this location." ! _to ParentObject; ! ! (3) Object InDescriptor ! has concealed, ! with name "words" "referencing" "location's" "interior", ! description ! "This is the description that you get if you examine ! this location from inside (from )."; ! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! ! ! (1) Continuing the terminology of the above templates, this object ! is used to describe a location (or interactive thing) that is ! visible from ParentObject. The player can "examine exterior" (or ! any other word in Descriptor's "name" list) and get ! its description, because Descriptor is a child of ! ParentObject, and therefore visible. Note that if - ! Descriptor was NOT a child of ParentObject, and the player tried ! to "examine exterior", the Inform Engine would say something ! like "You can't see any such thing here" because only children ! objects are visible! ! ! Descriptor has the "concealed" attribute in order to ! suppress the "There is a here" message ! normally concatenated to ParentObject's description, so that ! ParentObject can supply a custom reference to Descrip- ! tor in its description. Alternatively, the designer can omit all ! references to children from the parent's description, omit the ! "has concealed" attribute from each child, and give each child a ! short description, allowing the Inform Engine to concatenate the ! customary mundane children's descriptions to the parent's ! description. ! ! (2) This object is the actual enterable (or otherwise interactive) ! object. Note that the object does NOT have to be given the ! "enterable" attribute using my TAO methodology--and anything ! that can be left out of an Inform script SHOULD be! The ! "_to ParentObject" clause allows the player to leave ! and go back to ParentObject. Remember that Parent- ! Object MUST have the opposite "_to " clause to ! allow the player to get here in the first place! Of course, if ! is not a location at all, but instead is an inter- ! active object, it should be given appropriate descriptions and ! should NOT include a "_to" clause! ! ! The reason a child object is not used as an enterable location, ! able to satisfy the requirements of (1) and (2), is because of ! the way that the Inform Engine dorks up the short description ! (i.e., the "title" or "label") of a child location. If, for ! example, the player was allowed to enter a child called "Forest" ! from a parent called "Airport" (a perfectly reasonable thing to ! do!), the Inform Engine would give the Forest location label as ! "Airport (in Forest)" (a perfectly ridiculous description!). ! !!! IMPORTANT NOTE: the words in the "name" clause of a parent (or ! "room") object are NOT used to refer to the object--they are ! used to refer to unimportant things that are listed in the ! object's description, or things that are just intuitively ! obvious! Here's the reason: if the player is in a parent object ! that is described as "a bright room with a skylight", and these ! things are not interactive objects (just eye-candy), the "name" ! list had BETTER include words such as "sky", "skylight", and ! "light", otherwise when the player typed "examine sky", the ! Inform Engine would respond with something like "You can't see ! any such thing."!!! By placing these words in the name list, the ! Inform Engine will automatically take care of these unimportant ! things for you by responding with something like "You don't need ! to refer to that." (And you had better be thorough; the room ! description might just be "You are in a featureless room", but ! the player might try to examine walls, floor, ceiling, features, ! etc.!) ! ! (3) This final object is used as the descriptor for the interior of ! the location. Without this object, if the player was in ! and tried to examine it, the Inform Engine would ! respond with something like "There's no such thing here"!. ! Including words in the "name" list that describe the location ! wouldn't help; this list is for the Inform Engine's "You don't ! need to refer to that" response! ! Note that InDescriptor is a child of , NOT ! of ParentObject! ! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! ! ! Final note: The programming constructs of the Inform Engine will ! actually allow the designer to handle all of the above ! with custom code inside one object, but the complexity ! factor is overwhelming to all but seasoned Inform game ! designers! ! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! END OF DOCUMENT