Writing with Inform The complete documentation for Inform 7 presented in a single plain text file. The twenty-one chapters are each divided into sections. The sections refer to Examples, numbered upwards from 1 throughout the book: these Examples are presented in numerical order at the end of the main text. Chapter 1: Welcome to Inform 1.1. Preface 1.2. Acknowledgements 1.3. The facing pages 1.4. The Go! button 1.5. The Replay button 1.6. The Index and Errors panels 1.7. The Skein 1.8. A short Skein tutorial 1.9. Summary of the Skein and Transcript 1.10. The Inspector Chapter 2: The Source Text 2.1. Creating the world 2.2. Making rules 2.3. Punctuation 2.4. Problems 2.5. Headings 2.6. Why using headings is a good idea 2.7. The SHOWME command 2.8. The TEST command 2.9. Material not for release 2.10. Installing extensions 2.11. Including extensions 2.12. Use options 2.13. Limits and the Settings panel 2.14. What to do about a bug 2.15. Does Inform really understand English? 2.16. Review of Chapter 2: The Source Text Chapter 3: Things 3.1. Descriptions 3.2. Rooms and the map 3.3. One-way connections 3.4. Regions and the index map 3.5. Kinds 3.6. Either/or properties 3.7. Properties depend on kind 3.8. Scenery 3.9. Backdrops 3.10. Properties holding text 3.11. Three descriptions of things 3.12. Doors 3.13. Locks and keys 3.14. Devices and descriptions 3.15. Light and darkness 3.16. Vehicles and pushable things 3.17. Men, women and animals 3.18. Articles and proper names 3.19. Carrying capacity 3.20. Possessions and clothing 3.21. The player's holdall 3.22. Food 3.23. Parts of things 3.24. Concealment 3.25. The location of something 3.26. Directions 3.27. Review of Chapter 3: Things Chapter 4: Kinds 4.1. New kinds 4.2. Degrees of certainty 4.3. Plural assertions 4.4. Duplicates 4.5. Assemblies and body parts 4.6. New either/or properties 4.7. New value properties 4.8. Kinds of value 4.9. Using new kinds of value in properties 4.10. Conditions of things 4.11. Values that vary 4.12. Postscript on simulation 4.13. Review of Chapter 4: Kinds Chapter 5: Text 5.1. Text with substitutions 5.2. Text which names things 5.3. Text with numbers 5.4. Text with lists 5.5. Text with variations 5.6. Text with random alternatives 5.7. Line breaks and paragraph breaks 5.8. Text with type styles 5.9. Say 5.10. Making new substitutions 5.11. Accented letters 5.12. Unicode characters 5.13. Displaying quotations 5.14. Review of Chapter 5: Text Chapter 6: Descriptions 6.1. What are descriptions? 6.2. Adjectives and nouns 6.3. Sources of adjectives 6.4. Defining new adjectives 6.5. Which and who 6.6. A word about in 6.7. A word about nothing 6.8. To be able to see and touch 6.9. Adjacent rooms and routes through the map 6.10. All, each and every 6.11. Counting while comparing 6.12. Review of Chapter 6: Descriptions Chapter 7: Basic Actions 7.1. Actions 7.2. Instead rules 7.3. Before rules 7.4. Try and try silently 7.5. After rules 7.6. Reading and talking 7.7. The other four senses 7.8. Rules applying to more than one action 7.9. All actions and exceptional actions 7.10. The noun and the second noun 7.11. In rooms and regions 7.12. In the presence of, and when 7.13. Going from, going to 7.14. Going by, going through, going with 7.15. Kinds of action 7.16. Repeated actions 7.17. Actions on consecutive turns 7.18. Postscript on actions 7.19. Review of Chapter 7: Basic Actions Chapter 8: Change 8.1. Change of values that vary 8.2. Changing the command prompt 8.3. Changing the status line 8.4. Change of either/or properties 8.5. Change of properties with values 8.6. Whose property? 8.7. Moving things 8.8. Moving backdrops 8.9. Moving the player 8.10. Removing things from play 8.11. Now... 8.12. Checking on whereabouts 8.13. More flexible descriptions of whereabouts 8.14. Calling names 8.15. Counting the number of things 8.16. Looking at containment by hand 8.17. Randomness 8.18. Random choices of things 8.19. Review of Chapter 8: Change Chapter 9: Time 9.1. When play begins 9.2. Awarding points 9.3. Introducing tables: rankings 9.4. When play ends 9.5. Every turn 9.6. The time of day 9.7. Telling the time 9.8. Approximate times, lengths of time 9.9. Comparing and shifting times 9.10. Calculating times 9.11. Future events 9.12. Actions as conditions 9.13. The past and perfect tenses 9.14. How many times? 9.15. How many turns? 9.16. Review of Chapter 9: Time Chapter 10: Scenes 10.1. Introduction to scenes 10.2. Creating a scene 10.3. Using the Scene index 10.4. During scenes 10.5. Linking scenes together 10.6. More general linkages 10.7. Multiple beginnings and repeats 10.8. Multiple endings 10.9. Why are scenes designed this way? 10.10. Review of Chapter 10: Scenes Chapter 11: Phrases 11.1. Fitting values into phrases 11.2. The phrasebook 11.3. Pattern matching 11.4. Conditions and questions 11.5. If 11.6. While 11.7. Begin and end 11.8. Otherwise 11.9. Repeat 11.10. Repeat running through 11.11. Next and break 11.12. Stop 11.13. Phrases which use descriptions 11.14. Phrase options 11.15. Let and temporary variables 11.16. New conditions, new adjectives 11.17. Phrases to decide other things 11.18. The value after and the value before 11.19. In what order? 11.20. Ambiguities 11.21. Review of Chapter 11: Phrases Chapter 12: Advanced Actions 12.1. A recap of actions 12.2. How actions are processed 12.3. Giving instructions to other people 12.4. Persuasion 12.5. Unsuccessful attempts 12.6. Spontaneous actions by other people 12.7. New actions 12.8. Irregular English verbs 12.9. Check, carry out, report 12.10. Action variables 12.11. Making actions work for other people 12.12. Check rules for actions by other people 12.13. Report rules for actions by other people 12.14. Actions for any actor 12.15. Out of world actions 12.16. Reaching inside and reaching outside rules 12.17. Visible vs touchable vs carried 12.18. Changing reachability 12.19. Changing visibility 12.20. Stored actions 12.21. Guidelines on how to write rules about actions Chapter 13: Relations 13.1. Sentence verbs 13.2. What sentences are made up from 13.3. What are relations? 13.4. To carry, to wear, to have 13.5. Making new relations 13.6. Making reciprocal relations 13.7. Relations in groups 13.8. The built-in verbs and their meanings 13.9. Defining new assertion verbs 13.10. Defining new prepositions 13.11. Indirect relations 13.12. Relations which express conditions 13.13. Relations involving values 13.14. What are relations for? 13.15. Review of Chapter 13: Relations Chapter 14: Units 14.1. The measure of all things 14.2. Numbers 14.3. Whereabouts on a scale? 14.4. Comparing objects 14.5. Superlatives 14.6. Units 14.7. More on specifications 14.8. Multiple-number specifications 14.9. The parts of a number specification 14.10. Understanding specified numbers 14.11. Limits on the size of numbers 14.12. Arithmetic with units 14.13. Multiplication of units 14.14. Totals 14.15. Making the verb "to weigh" 14.16. Review of Chapter 14: Units Chapter 15: Tables 15.1. Laying out tables 15.2. Looking up entries 15.3. Corresponding entries 15.4. Changing entries 15.5. Choosing rows 15.6. Repeating through tables 15.7. Blank entries 15.8. Blank columns 15.9. Blank rows 15.10. Adding and removing rows 15.11. Sorting 15.12. Listed in... 15.13. Topic columns 15.14. Another scoring example 15.15. Varying which table to look at 15.16. Defining things with tables 15.17. Defining values with tables 15.18. Table continuations 15.19. Table amendments Chapter 16: Understanding 16.1. Understand 16.2. New commands for old grammar 16.3. Overriding existing commands 16.4. Standard tokens of grammar 16.5. The text token 16.6. Actions applying to kinds of value 16.7. Understanding any, understanding rooms 16.8. Understanding names 16.9. Understanding kinds of value 16.10. Commands consisting only of nouns 16.11. Understanding values 16.12. This/that 16.13. New tokens 16.14. Tokens can produce values 16.15. Understanding things by their properties 16.16. Understanding things by their relations 16.17. Context: understanding when 16.18. Does the player mean... 16.19. Understanding mistakes 16.20. Precedence 16.21. Review of Chapter 16: Understanding Chapter 17: Activities 17.1. What are activities? 17.2. How activities work 17.3. Rules applied to activities 17.4. While clauses 17.5. New activities 17.6. Activity variables 17.7. Beginning and ending activities manually 17.8. Introduction to the list of built-in activities 17.9. Deciding the concealed possessions of something 17.10. Printing the name of something 17.11. Printing the plural name of something 17.12. Printing a number of something 17.13. Listing contents of something 17.14. Grouping together something 17.15. Printing room description details of something 17.16. Printing a refusal to act in the dark 17.17. Printing the announcement of darkness 17.18. Printing the announcement of light 17.19. Printing the name of a dark room 17.20. Printing the description of a dark room 17.21. Constructing the status line 17.22. Writing a paragraph about 17.23. Listing nondescript items of something 17.24. Printing the locale description of something 17.25. Choosing notable locale objects for something 17.26. Printing a locale paragraph about 17.27. Deciding the scope of something 17.28. Clarifying the parser's choice of something 17.29. Asking which do you mean 17.30. Supplying a missing noun/second noun 17.31. Reading a command 17.32. Implicitly taking something 17.33. Printing a parser error 17.34. Deciding whether all includes 17.35. Printing the banner text 17.36. Printing the player's obituary 17.37. Amusing a victorious player 17.38. Starting the virtual machine 17.39. Review of Chapter 17: Activities Chapter 18: Rulebooks 18.1. On rules 18.2. Named rules and rulebooks 18.3. New rules 18.4. Listing rules explicitly 18.5. Sorting and indexing of rules 18.6. The preamble of a rule 18.7. New rulebooks 18.8. Action- vs object-based rulebooks 18.9. Rulebook variables 18.10. Success and failure 18.11. Named outcomes 18.12. Outcome values 18.13. Procedural rules 18.14. Phrases concerning rules 18.15. Consider and abide 18.16. Consider is not the same as follow 18.17. Two rulebooks used internally 18.18. The Laws for Sorting Rulebooks 18.19. Review of Chapter 18: Rulebooks Chapter 19: Advanced Text 19.1. Ordinary text and indexed text 19.2. Memory limitations with indexed text 19.3. Characters, words, punctuated words, unpunctuated words, lines, paragraphs 19.4. Upper and lower case letters 19.5. Matching and exactly matching 19.6. Regular expression matching 19.7. Indexed text in variables, properties and tables 19.8. Replacements 19.9. Summary of regular expression notation Chapter 20: Lists 20.1. Lists and entries 20.2. Constant lists 20.3. Saying lists of values 20.4. Testing and iterating over lists 20.5. Building lists 20.6. Lists of objects 20.7. Sorting, reversing and rotating lists 20.8. Accessing entries in a list 20.9. Lengthening or shortening a list 20.10. Variations: arrays, logs, queues, stacks, sets, sieves and rings Chapter 21: Figures, Sounds and Files 21.1. Beyond text 21.2. How IF views pictures 21.3. Virtual machines and story file formats 21.4. Gathering the figures 21.5. Declaring and previewing the figures 21.6. Displaying the figures 21.7. Recorded sounds 21.8. Declaring and playing back sounds 21.9. Some technicalities about figures and sounds 21.10. Files 21.11. Declaring files 21.12. Writing and reading tables to external files 21.13. Writing, reading and appending text to files 21.14. Exchanging files with other programs Chapter 22: Releasing 22.1. The finished product 22.2. Bibliographic data 22.3. Genres 22.4. The Library Card 22.5. The Treaty of Babel and the IFID 22.6. The Release button 22.7. The Joy of Feelies 22.8. The Materials folder 22.9. Cover art 22.10. An introductory booklet 22.11. A website 22.12. Website templates 22.13. Republishing existing works of IF 22.14. Walkthrough solutions 22.15. Releasing the source text 22.16. Improving the index map 22.17. Producing an EPS format map 22.18. Settings in the map-maker 22.19. Table of map-maker settings 22.20. Kinds of value accepted by the map-maker 22.21. Titling and abbreviation 22.22. Rubrics Chapter 23: Publishing 23.1. Finding a readership 23.2. How a novel is published 23.3. How interactive fiction is published 23.4. The IF Archive 23.5. A Website of Its Own 23.6. IFDB: The Interactive Fiction Database 23.7. Competitions 23.8. Making an announcement 23.9. SPAG 23.10. The Gaming Avant-Garde 23.11. The Digital Literature Community 23.12. A short concluding homily Chapter 24: Extensions 24.1. The status of extensions 24.2. The Standard Rules 24.3. Authorship 24.4. A simple example extension 24.5. Version numbering 24.6. Extensions and story file formats 24.7. Extensions can include other extensions 24.8. Extensions can interact with other extensions 24.9. Extensions in the Index 24.10. Extension documentation 24.11. Examples and headings in extension documentation 24.12. Implications 24.13. Using Inform 6 within Inform 7 24.14. Defining phrases in Inform 6 24.15. Phrases to decide in Inform 6 24.16. Handling phrase options 24.17. Types are not kinds of value 24.18. Catalogue of named Inform 7 types 24.19. Making and testing use options 24.20. Longer extracts of Inform 6 code 24.21. Primitive Inform 6 declarations of rules 24.22. Inform 6 objects and classes 24.23. Inform 6 variables, properties and attributes 24.24. The template layer 24.25. Translating the language of play 24.26. Segmented substitutions 24.27. Invocation labels, counters and storage 24.28. To say one of Chapter 25: What's New in Inform? 25.1. Where to find new developments 25.2. What's new in build 5T18 (April 2008) 25.3. What was new in build 5J39 (December 2007) 25.4. What was new in build 5G67 (November 2007) 25.5. What was new in build 4X60 (23 August 2007) 25.6. What was new in build 4W37 (27 July 2007) 25.7. What was new in build 4U65 (27 April 2007) 25.8. What was new in build 4S08 (25 March 2007) Examples Example 1 (*): About the examples Example 2 (*): Verbosity Example 3 (**): Slightly Wrong Example 4 (*): Port Royal 1 Example 5 (**): Up and Up Example 6 (***): Starry Void Example 7 (*): Port Royal 2 Example 8 (*): The Unbuttoned Elevator Affair Example 9 (*): Port Royal 3 Example 10 (*): First Name Basis Example 11 (*): Midsummer Day Example 12 (*): Tamed Example 13 (*): Disenchantment Bay 1 Example 14 (*): Replanting Example 15 (*): Disenchantment Bay 2 Example 16 (*): Disenchantment Bay 3 Example 17 (*): Disenchantment Bay 4 Example 18 (**): Laura Example 19 (*): Disenchantment Bay 5 Example 20 (**): Escape Example 21 (***): Garibaldi 1 Example 22 (*): Disenchantment Bay 6 Example 23 (**): Neighborhood Watch Example 24 (*): Disenchantment Bay 7 Example 25 (**): Down Below Example 26 (*): Peugeot Example 27 (**): Disenchantment Bay 8 Example 28 (***): Hover Example 29 (*): Disenchantment Bay 9 Example 30 (*): Belfry Example 31 (**): Gopher-wood Example 32 (*): Disenchantment Bay 10 Example 33 (*): Disenchantment Bay 11 Example 34 (***): Brown Example 35 (****): Disenchantment Bay 12 Example 36 (***): Search and Seizure Example 37 (**): Van Helsing Example 38 (**): Prisoner's Dilemma Example 39 (**): Vouvray Example 40 (*): Odin Example 41 (*): Something Narsty Example 42 (***): Get Me to the Church on Time Example 43 (***): Early Childhood Example 44 (*): Being Prepared Example 45 (**): Model Shop Example 46 (***): The Night Before Example 47 (***): U-Stor-It Example 48 (**): Change of Basis Example 49 (*): Would you...? Example 50 (**): Straw Boater Example 51 (*): The Undertomb Example 52 (***): The Crane's Leg 1 Example 53 (***): Signs and Portents Example 54 (***): Real Adventurers Need No Help Example 55 (*): Bic Example 56 (***): Ballpark Example 57 (*): Control Center Example 58 (**): Tiny Garden Example 59 (*): When? Example 60 (***): Persephone Example 61 (***): Whence? Example 62 (*): Radio Daze Example 63 (**): Camp Bethel Example 64 (**): Beekeeper's Apprentice Example 65 (*): Garibaldi 2 Example 66 (*): Fifty Ways to Leave Your Larva Example 67 (***): Fifty Times Fifty Ways Example 68 (***): The Über-complète clavier Example 69 (*): Finishing School Example 70 (***): Lean and Hungry Example 71 (*): Mistress of Animals Example 72 (*): All Roads Lead to Mars Example 73 (**): Hotel Stechelberg Example 74 (***): A View of Green Hills Example 75 (****): Revenge of the Fussy Table Example 76 (**): Yolk of Gold Example 77 (*): Grilling Example 78 (*): Bad Hair Day Example 79 (***): Democratic Process Example 80 (****): Sand Example 81 (*): Fine Laid Example 82 (*): Hayseed Example 83 (*): Morning After Example 84 (*): Sybil 1 Example 85 (*): Lucy Example 86 (**): Sybil 2 Example 87 (***): Costa Rican Ornithology Example 88 (***): The Art of Noise Example 89 (*): Waterworld Example 90 (*): Zodiac Example 91 (*): Ming Vase Example 92 (*): Beachfront Example 93 (**): Today Tomorrow Example 94 (*): Veronica Example 95 (**): Hagia Sophia Example 96 (**): A&E Example 97 (***): Polarity Example 98 (***): Bumping into Walls Example 99 (*): Mattress King Example 100 (*): No Relation Example 101 (**): One Short Plank Example 102 (***): Provenance Unknown Example 103 (***): Zorb Example 104 (*): Dearth and the Maiden Example 105 (***): Mimicry Example 106 (*): Y ask Y? Example 107 (****): A Day For Fresh Sushi Example 108 (***): Don Pedro's Revenge Example 109 (*): Politics as Usual Example 110 (***): Centered Example 111 (*): Vitrine Example 112 (*): Thirst Example 113 (*): Thirst 2 Example 114 (**): Meteoric I and II Example 115 (***): Orange Cones Example 116 (***): Terror of the Sierra Madre Example 117 (*): Beverage Service Example 118 (*): Spring Cleaning Example 119 (*): Bee Chambers Example 120 (***): Technological Terror Example 121 (*): Higher Calling Example 122 (*): Do Pass Go Example 123 (*): Lanista 1 Example 124 (*): Weathering Example 125 (***): Uptown Girls Example 126 (*): Candy Example 127 (*): Zork II Example 128 (*): Clueless Example 129 (***): No Place Like Home Example 130 (***): Big Sky Country Example 131 (***): Witnessed 1 Example 132 (****): Text Foosball Example 133 (**): IPA Example 134 (*): Situation Room Example 135 (*): MRE Example 136 (**): Totality Example 137 (**): Empire Example 138 (***): Hour of the Wren Example 139 (*): Night Sky Example 140 (***): Zero Example 141 (*): Tense Boxing Example 142 (**): Bruneseau's Journey Example 143 (*): Infiltration Example 144 (*): Annoyotron Jr Example 145 (*): Pine 1 Example 146 (**): Entrapment Example 147 (*): Age of Steam Example 148 (*): Full Moon Example 149 (**): Space Patrol - Stranded on Jupiter! Example 150 (***): Day One Example 151 (***): Pine 2 Example 152 (*): The Prague Job Example 153 (*): Night and Day Example 154 (***): Pine 3 Example 155 (***): Panache Example 156 (***): Pine 4 Example 157 (***): Cheese-makers Example 158 (*): Ahem Example 159 (**): Ferragamo Again Example 160 (**): Proposal Example 161 (*): Matreshka Example 162 (*): Princess and the Pea Example 163 (*): Numberless Example 164 (*): Wonka's Revenge Example 165 (**): Strictly Ballroom Example 166 (*): Curare Example 167 (**): Equipment List Example 168 (*): M. Melmoth's Duel Example 169 (***): Owen's Law Example 170 (*): Witnessed 2 Example 171 (***): A Haughty Spirit Example 172 (*): Entropy Example 173 (***): The Hang of Thursdays Example 174 (*): Virtue Example 175 (***): Latris Theon Example 176 (*): The Hypnotist of Blois Example 177 (*): Police State Example 178 (**): Generation X Example 179 (*): IQ Test Example 180 (****): Boston Cream Example 181 (*): Red Cross Example 182 (***): Frizz Example 183 (***): 3 AM Example 184 (*): The Dark Ages Revisited Example 185 (*): Waxwork Example 186 (**): Paddington Example 187 (***): Delicious, Delicious Rocks Example 188 (***): Noisemaking Example 189 (*): Removal Example 190 (*): Further Reasons Why All Poets Are Liars Example 191 (*): The Second Oldest Problem Example 192 (**): Puff of Orange Smoke Example 193 (***): Croft Example 194 (**): The Man of Steel Example 195 (***): Trying Taking Manhattan Example 196 (****): Under Contract Example 197 (*): Get Axe Example 198 (***): Barter Barter Example 199 (*): Reporting rules for other characters' behavior Example 200 (***): Fate Steps In Example 201 (*): Spellbreaker Example 202 (***): A point for never saving the game Example 203 (**): Carnivale Example 204 (**): Eddystone Example 205 (*): Magneto's Revenge Example 206 (**): Dinner is Served Example 207 (*): Flashlight Example 208 (*): Bosch Example 209 (*): Cactus Will Outlive Us All Example 210 (**): Actor's Studio Example 211 (**): Anteaters Example 212 (***): Formal syntax of sentences Example 213 (*): Interrogation Example 214 (*): Celadon Example 215 (***): Four Cheeses Example 216 (*): Transmutations Example 217 (***): Otranto Example 218 (*): Unthinkable Alliances Example 219 (***): The Unexamined Life Example 220 (*): The Abolition of Love Example 221 (*): Swerve left? Swerve right? Or think about it and die? Example 222 (*): Beneath the Surface Example 223 (***): Bogart Example 224 (***): The Problem of Edith Example 225 (***): A Humble Wayside Flower Example 226 (*): Meet Market Example 227 (**): Murder on the Orient Express Example 228 (**): What Not To Wear Example 229 (***): Mathematical view of relations Example 230 (***): Graph-theory view of relations Example 231 (*): Only You... Example 232 (*): rBGH Example 233 (**): Wonderland Example 234 (***): Zqlran Era 8 Example 235 (***): Snip Example 236 (***): Alias Example 237 (*): Frozen Assets Example 238 (**): Money for Nothing Example 239 (***): Lemonade Example 240 (***): Savannah Example 241 (*): Depth Example 242 (***): Nickel and Dimed Example 243 (**): Dimensions Example 244 (***): Lead Cuts Paper Example 245 (***): Dubai Example 246 (**): Port Royal 4 Example 247 (*): If It Hadn't Been For... Example 248 (**): Odyssey Example 249 (**): Jokers Wild Example 250 (***): Noisy Cricket Example 251 (*): Merlin Example 252 (***): Questionable Revolutions Example 253 (***): The Queen of Sheba Example 254 (***): Goat-Cheese and Sage Chicken Example 255 (**): Farewell Example 256 (**): Sweeney Example 257 (***): Introduction to Juggling Example 258 (*): Food Network Interactive Example 259 (**): Trieste Example 260 (*): XYZZY Example 261 (*): Indirection Example 262 (**): Xylan Example 263 (*): Anchorite Example 264 (*): Alpaca Farm Example 265 (****): Cloak of Darkness Example 266 (*): The Trouble with Printing Example 267 (**): Lanista 2 Example 268 (*): Shawn's Bad Day Example 269 (***): The Left Hand of Autumn Example 270 (*): Ish. Example 271 (**): Nameless Example 272 (*): Safety Example 273 (*): Tom's Midnight Garden Example 274 (**): Ibid. Example 275 (*): One of Those Mornings Example 276 (**): Actaeon Example 277 (*): Pages Example 278 (***): Straw Into Gold Example 279 (*): Misadventure Example 280 (**): Safari Guide Example 281 (*): Palette Example 282 (***): Baritone, Bass Example 283 (*): Lies Example 284 (*): Aspect Example 285 (*): Hymenaeus Example 286 (**): Terracottissima Example 287 (**): Peers Example 288 (**): Channel 1 Example 289 (***): Terracottissima Maxima Example 290 (***): Tilt 1 Example 291 (***): Channel 2 Example 292 (*): Puncak Jaya Example 293 (*): Cinco Example 294 (**): Claims Adjustment Example 295 (*): Quiz Show Example 296 (**): Bibliophilia Example 297 (*): Masochism Deli Example 298 (*): Query Example 299 (*): The Gorge at George Example 300 (***): Hot Glass Looks Like Cold Glass Example 301 (*): Some Assembly Required Example 302 (***): Lakeside Living Example 303 (**): AARP-Gnosis Example 304 (***): Aftershock Example 305 (***): Crusoe Example 306 (*): Hayes Code Example 307 (*): Shipping Trunk Example 308 (**): Trachypachidae Maturin 1803 Example 309 (****): Chronic Hinting Syndrome Example 310 (**): Hudsucker Industries Example 311 (*): Prolegomena Example 312 (*): Unpeeled Example 313 (*): Rules of Attraction Example 314 (***): Zorn of Zorna Example 315 (**): Hohmann Transfer Example 316 (***): Four Stars Example 317 (*): Ways Out Example 318 (**): Guided Tour Example 319 (*): Reflections Example 320 (**): Emma Example 321 (****): Air Conditioning is Standard Example 322 (*): Rip Example 323 (**): Happy Hour Example 324 (**): The Eye of the Idol Example 325 (*): Priority Lab Example 326 (*): Low Light Example 327 (***): Casino Banale Example 328 (*): Kiwi Example 329 (***): Copper River Example 330 (*): Peeled Example 331 (*): Scope for listening different from scope for seeing Example 332 (**): Ginger Beer Example 333 (**): Rock Garden Example 334 (***): Stately Gardens Example 335 (*): Apples Example 336 (*): Originals Example 337 (***): Walls and Noses Example 338 (*): Latin Lessons Example 339 (*): Minimal Movement Example 340 (*): Fore Example 341 (**): Fragment of a Greek Tragedy Example 342 (**): Cloves Example 343 (***): Complimentary Peanuts Example 344 (***): Lollipop Guild Example 345 (*): WXPQ Example 346 (***): Xot Example 347 (*): Bikini Atoll Example 348 (*): Battle of Ridgefield Example 349 (*): Jamaica 1688 Example 350 (**): Xerxes Example 351 (*): Blankness Example 352 (*): Nine AM Appointment Example 353 (**): Delayed Gratification Example 354 (*): Stone Example 355 (*): The Crane's Leg 2 Example 356 (**): Bribery Example 357 (*): Saint Eligius Example 358 (**): Slouching Example 359 (*): We Example 360 (***): Backus-Naur form for rules Example 361 (***): In Fire or in Flood Example 362 (*): Flotation Example 363 (*): Feline Behavior Example 364 (**): Kyoto Example 365 (*): Being Peter Example 366 (***): Tilt 2 Example 367 (*): Access All Areas Example 368 (*): Uptempo Example 369 (**): Lethal Concentration 1 Example 370 (**): Swigmore U. Example 371 (***): Lethal Concentration 2 Example 372 (***): Solitude Example 373 (****): Patient Zero Example 374 (*): Electrified Example 375 (*): Timeless Example 376 (**): Endurance Example 377 (**): Escape from the Seraglio Example 378 (*): Rocket Man Example 379 (*): Capital City Example 380 (*): About Inform's regular expression support Example 381 (*): Alpha Example 382 (*): Identity Theft Example 383 (*): Mirror, Mirror Example 384 (**): The Cow Exonerated Example 385 (*): Fido Example 386 (*): Igpay Atinlay Example 387 (*): Blackout Example 388 (**): Mr. Burns' Repast Example 389 (**): Northstar Example 390 (***): Cave-troll Example 391 (*): Robo 1 Example 392 (*): What Makes You Tick Example 393 (**): Formicidae Example 394 (***): Robo 2 Example 395 (*): Leopard-skin Example 396 (*): Eyes, Fingers, Toes Example 397 (*): The Fibonacci Sequence Example 398 (*): I Didn't Come All The Way From Great Portland Street Example 399 (*): Lugubrious Pete's Delicatessen Example 400 (*): Sieve of Eratosthenes Example 401 (*): Your Mother Doesn't Work Here Example 402 (*): Circle of Misery Example 403 (*): Alien Invasion Part 23 Example 404 (**): Labyrinth of Ghosts Example 405 (***): Rubies Example 406 (*): The Fourth Body Example 407 (**): The Fifth Body Example 408 (***): Flathead News Network Example 409 (*): Baedeker Example 410 (*): Port Royal 5 Example 411 (*): Bay Leaves and Honey Wine Example 412 (**): Modern Conveniences Example 413 (**): Tilt 3 Example 414 (*): Odins Example 415 (***): Pink or Blue Example 416 (*): Status line with centered text, the hard way Example 417 (*): Chanel Version 1 Example 418 (*): Blink Example 419 (**): Uncommon Ground Chapter 1: Welcome to Inform 1.1. Preface Welcome to Inform, a design system for interactive fiction based on natural language. Interactive fiction is a literary form which involves programming a computer so that it presents a reader with a text which can be explored. Inform aims to make the burden of learning to program such texts as light as possible. It is a tool for writers intrigued by computing, and computer programmers intrigued by writing. Perhaps these are not so very different pursuits, in their rewards and pleasures: The sheer joy of making things... the fascination of fashioning complex puzzle-like objects of interlocking moving parts and watching them work in subtle cycles... the delight of working in such a tractable medium. The programmer, like the poet, works only slightly removed from pure thought-stuff. He builds his castles in the air, from air, creating by exertion of the imagination. (Frederick P. Brooks, "The Mythical Man-Month", 1972) Writing with Inform is one of two interlinked books included with Inform: a concise but complete guide to the system. The other book is The Inform Recipe Book, a comprehensive collection of examples, showing its practical use. If you are reading this within the Inform application, you will see that the Writing with Inform pages are on "white paper", while the Recipe Book is on "yellow paper". These notes are arranged so that the reader can, in principle, write whole works of fiction as early as the end of Chapter 3. Each subsequent chapter then extends the range of techniques available to make livelier and more intriguing situations. For the benefit of partially sighted users, duplicate versions of this book in plain text and lightly-formatted HTML formats can be found at the Inform website. This new release of Inform ("Inform 7", the seventh major version since 1993) is a radical departure from most previous approaches to interactive fiction. In particular, it is very different from Inform 6, which newcomers will not need to know anything about. Inform 6 sits inside Inform 7, and is part of the inner workings, but is not visible from the outside. For information about Inform 6, see www.inform-fiction.org. Programming is best regarded as the process of creating works of literature, which are meant to be read... so we ought to address them to people, not to machines. (Donald Knuth, "Literate Programming", 1981) (See Acknowledgements for a chance to try out the cross-referencing links in Writing with Inform - click on the red asterisk or the name of the destination to go there.) Example 1 (*): About the examples An explanation of the examples in this documentation, and the asterisks attached to them. Click the heading of the example, or the example number, to reveal the text. 1.2. Acknowledgements I should like to dedicate this new edition of Inform to Emily Short and Andrew Plotkin, whose shrewd and sceptical suggestions made a contribution which can hardly be overstated. A long email correspondence with Andrew entirely subverted my original thoughts about natural-language IF, as he convinced me that the "new model" of rule-based IF was a truer foundation; while Emily's wry, witty analysis and how-about-this? cheered me at low moments, besides providing the impetus and often the specifics for a lot of the best ideas. Among those who kindly gave up great swathes of time to test, and think about, the early Inform 7, I must give special thanks to Sonja Kesserich, who was so often patient, and so often right. Her easy-going "pestering" (Sonja's word) led to improvements more or less everywhere, at a time when using Inform 7 was not much fun. I also thank David Cornelson for gathering volunteers; and I thank them, too. From the outset, I have thought of Inform 7 as no longer being a command-line compiler, but a compiler in combination with a radically more humanising user interface: all credit for the reference implementation under Mac OS X belongs to Andrew Hunter. I thank him for his forbearance in the face of much cajolery. How simple the metaphor of an interactive book with facing pages may seem, but the coding was an enormous challenge, and I could not have done it. Though David Kinder's Windows implementation of the user interface does indeed visually follow Andrew's original, the two programs were coded independently, and the programming task taken up by David was formidable indeed. He also uncovered numerous bugs in the compiler which, through one coincidence or another, did not reveal themselves under OS X. Philip Chimento's Gnome-based user interface for Linux became officially part of the project in November 2007, when the first easy-to-install packages for Ubuntu and Fedora were offered. Philip's efforts were particularly generous since the early stages of Inform-for-Linux were so tentative: for many months, we weren't sure how to go about the project, and during that time Philip quietly wrote us a solution. The final months before the Public Beta release of Inform 7 were made more enjoyable, as well as more productive, by fruitful discussions leading to a cross-platform standard for bibliographic data and cover art. I would like to thank L. Ross Raszewski, who wrote frighteningly efficient reference software in frighteningly little time; the librarians of the IF-Archive, Andrew Plotkin, David Kinder and Paul Mazaitis; and my fellow authors of IF design systems - Mike Roberts (of the Text Adventure Development System); Kent Tessman (of Hugo); and Campbell Wild (of ADRIFT). 1.3. The facing pages (Mac OS X only) This Public Beta of Inform 7 runs on Mac OS X through the graphical user interface created by Andrew Hunter. (Windows only) This Public Beta of Inform 7 runs on Windows through the graphical user interface created by David Kinder. (Linux only) This Public Beta of Inform 7 runs on Linux through the text-only interface created by Adam Thornton. (Gnome only) This Public Beta of Inform 7 runs on Linux through the graphical user interface created by P. F. Chimento. (Mac OS X only) The main window is an opened book showing two facing pages, and as we shall see it behaves as if these pages are in dialogue with each other: for the most part we write on the left hand page and see responses appear on the right. But all is controllable. The margin between the two pages can be dragged back and forth like the slide on a trombone: each page can be made smaller that the other may grow larger. Moreover, each page can display one of a number of displays relevant to the current project, called "panels", one of them being the Documentation panel which displays this manual. The vertical strip of choices at the right hand margin of each page allows you to choose between panels. (The same panel can be showing on both pages at the same time, if that's useful.) (Windows only) The main window is an opened book showing two facing pages, and as we shall see it behaves as if these pages are in dialogue with each other: for the most part we write on the left hand page and see responses appear on the right. But all is controllable. The margin between the two pages can be dragged back and forth like the slide on a trombone: each page can be made smaller that the other may grow larger. Moreover, each page can display one of a number of displays relevant to the current project, called "panels", one of them being the Documentation panel which displays this manual. The horizontal strip of choices at the top of each page allows you to choose between panels. (The same panel can be showing on both pages at the same time, if that's useful.) (Linux only) The interface is extremely crude compared to that available on Mac OS X or Windows. The panels that exist are accessible via menu options, and anywhere you see reference to a button, it simply doesn't exist. Go and Release are implemented, as is Compile, which rebuilds the story but does not start it. There is a further settings panel available to you, the IDE settings, which allows you to control which editor you wish to use to edit your project, which browser allows you to view HTML files, which interpreters to use to play your stories, and whether or not these should be run in the background. Users with a graphical desktop are likely to want to choose the background option, while those running only with text terminals will not. To select an option, type the letter indicated on the screen and follow it with the Enter key. (Gnome only) The main window is an opened book showing two facing pages, and as we shall see it behaves as if these pages are in dialogue with each other: for the most part we write on the left hand page and see responses appear on the right. But all is controllable. The margin between the two pages can be dragged back and forth like the slide on a trombone: each page can be made smaller that the other may grow larger. Moreover, each page can display one of a number of displays relevant to the current project, called "panels", one of them being the Documentation panel which displays this manual. The horizontal strip of choices at the top of each page allows you to choose between panels. (The same panel can be showing on both pages at the same time, if that's useful.) At the start the only panels available are a blank space in which to write the first lines of a new interactive fiction - the Source panel - and this one, the Documentation. Clicking on the other choices will do nothing. The exception is the Settings panel, which contains some preference settings for the individual project - not the whole application. This is always available, but it controls settings which can be left alone almost all of the time. 1.4. The Go! button Clicking the Go button translates the text in the Source panel into a computer program which enacts the interactive fiction, and automatically sets it going (in the Game panel, which opens as needed). If the Source is empty of text, Inform will be unable to create anything: it needs at least one name of a location where the drama can unfold. For reasons of tradition, such locations are normally called "rooms", though people have used them to represent anything from grassy fields to states of mind and other metaphorical places. "Midsummer Day" The Gazebo is a room. Clicking Go with this text in the Source panel will result in a short delay, after which the Game panel will appear, from which we can explore this newly created world: an interactive fiction called "Midsummer Day". It will not be very exciting, since Inform has only five words to go on, but we can add more detail to the source at any point and then click Go again to try out the changes. (Note that there is no need to "quit" these explorations in the Game panel. When Go is clicked, any game already in progress is discarded in favour of the new version.) (Mac OS X only) Typing Command-R has the same effect as clicking Go. If Inform is running on Mac OS 10.3.9 or later, clicking on a "text" icon (Image paste.png here) in this documentation copies the example text which follows it into the Source as if you had faithfully typed it out. (This icon is usually provided only for fairly long examples, but note that you can in fact copy and paste any text from this documentation into the source by selecting it with the mouse, typing Command-C, then clicking to a position in the source and typing Command-V.) (Windows only) Typing F5 has the same effect as clicking Go. Clicking on a "text" icon (Image paste.png here) in this documentation copies the example text which follows it into the Source as if you had faithfully typed it out. (This icon is usually provided only for fairly long examples, but note that you can in fact copy and paste any text from this documentation into the source by selecting it with the mouse, typing Ctrl-C, then clicking to a position in the source and typing Ctrl-V.) (Linux only) Typing "G" is the only way you can perform the Go action. (Gnome only) Typing Ctrl-R has the same effect as clicking Go. Clicking on a "text" icon (Image paste.png here) in this documentation copies the example text which follows it into the Source as if you had faithfully typed it out. (This icon is usually provided only for fairly long examples, but note that you can in fact copy and paste any text from this documentation into the source by selecting it with the mouse, typing Ctrl-C, then clicking to a position in the source and typing Ctrl-V.) 1.5. The Replay button Replay works identically to Go, except that it does something further: once the game is created, it automatically plays through the same commands as were typed into the previous version. For instance: suppose we click Go to bring Midsummer Day into being, and find ourselves playing the game. We type "look" and find that there is not much to see. Going back to the source, we add "A white canvas parasol raised up on stakes driven into the grass." so that the source now reads "Midsummer Day" The Gazebo is a room. "A white canvas parasol raised up on stakes driven into the grass." Instead of clicking Go, we click Replay, and can sit back and watch what has changed. In this example, it only saves us the trouble of typing "look", but once games become long and elaborate, Replay is invaluable: and especially when we notice in play that something very minor is wrong - a spelling error, say - and want to fix it immediately, without fuss. (Linux only) Replay is not implemented in the text-mode Linux interface. 1.6. The Index and Errors panels If, when Go! is clicked, the text in the Source panel is not fully understood, then Inform will generate a report of the problems it found, which will open in the "Errors" panel. (Other information is also available in "Errors", but most of it is used for debugging Inform, and can be ignored.) On the other hand, if the text was fully understood then another new panel will become available: the "Index". This is a cross-referenced index of the source, or rather, of the interactive fiction which has been generated. The Index is only an optional convenience, but becomes more and more helpful as the fiction grows larger. Its exact format does not matter for now. The icon (Image Reveal.png here) always denotes a reference to a particular line in the Source text, that is, to something written in the source: clicking it opens the Source panel and jumps to that position. The icon (Image Below.png here) indicates that more detailed information can be read further down the text in the same panel: clicking it jumps down to this more detailed report. Lastly, the icon (Image help.png here) hints that there is a relevant page of this manual: clicking this opens the Documentation panel and switches to it. (Linux only) The Index is accessible by typing "I" at the prompt, if you have set your browser. You can set the browser by typing "S" to get to the settings panel, and then "I" for the IDE panel. From the top-level Index you will be able to access Errors as well as other information. 1.7. The Skein The Replay button demonstrates that Inform must be quietly remembering the commands typed into the last run through the game. In fact it remembers, and automatically organises, every previous run. Inform's approach to testing interactive fiction is to treat it as being like the analysis of other turn-based games, such as chess. It would be prohibitively difficult to work out every possible combination of moves: instead, we analyse those which go somewhere, and look for significant choices. Every Queen's Gambit begins with the same first three moves (1. d4, d5; 2. c4), but then there is a choice, as the next move decides whether we have a Queen's Gambit Accepted (dxc4) or Declined (e6). Books about chess often contain great tables of such openings, which run together for a while but eventually diverge. To learn chess, one must explore all of these variations. Inform's Skein panel is just such a table, built automatically. If we think of the list of typed commands as a thread, then the skein is (as the name suggests) braided together from all these threads. In the display, time begins at the top, with the start knot, and the threads of different games hang downwards from it. Double-clicking on a command translates the source afresh and replays the game from start down to that command, and then stops. We are then free to continue play by typing commands into the Game panel, of course, and these commands will automatically be recorded in the Skein as a new variation of play, diverging from the previous threads. (Linux only) The Skein is not implemented in the Linux version. 1.8. A short Skein tutorial In the following example, we will see how the Skein is woven as different commands are tried. As it happens, the game being played is the example "Witnessed", from Chapter 11, but the details do not matter. When the project has never been played at all, if we switch to the Skein panel (or open it opposite the Game panel) we will only find this: (Image skt1.png here) Suppose we click Go for the first time and type two commands in: TURN ON ALARM and then LOOK. Now the Skein shows: (Image skt2.png here) Only one line of play is known to Inform, and it runs downwards in a thread from the special "- start -" knot, which represents the situation before any command has been tried. The useful thing about having past histories recorded like this is that we can revisit them. Suppose we want to go back to the situation after typing only TURN ON ALARM. We could click Go again and type that first command in once more, but now we have an easier method: we simply double-click on the TURN ON ALARM knot. The game restarts by itself, and commands are automatically keyed in to regain the position of play represented by the knot we clicked on - in this example that only keys a single command in, but it might have been hundreds. The Skein now looks like this: (Image skt3.png here) All knots are displayed either as yellow or green. Yellow knot are the ones in the history of the game currently playing. The LOOK knot is green because it hasn't happened in the current game yet - and in fact, it won't happen in the current game, because instead we play TURN ON METER. Now the Skein changes again: (Image skt4.png here) Inform now knows about two ways to play the current project: one consisting of TURN ON ALARM and the TURN ON METER, the other of TURN ON ALARM and then LOOK. Since these only differ after the first turn, Inform displays them as a thread which divides into two after the first turn. Again, LOOK remains green because it hasn't been played in the current game. Note also that one of the two possible threads here is drawn more thickly (here it is shown with thick dashes rather than thin). Only one thread is ever drawn thickly -- the one currently being shown in the Transcript panel, which we will come to later on. (That often corresponds to the current line of play, as now, because the Transcript follows what we do unless we choose otherwise.) After a little more exploration, we reach the following: (Image skt5.png here) (Mac OS X only) At this point we decide that we want to preserve the thread leading to EXAMINE CHIMES - perhaps it's a sequence we are going to want to test often. The Skein can be edited very easily, in several ways (for instance clicking and holding on a command allows us to edit the text of the command): control-clicking (or right-clicking) on a knot brings up a contextual menu. On Mac OS X, some popular knot controls appear whenever the mouse hovers over the knot, like so: (Windows only) At this point we decide that we want to preserve the thread leading to EXAMINE CHIMES - perhaps it's a sequence we are going to want to test often. The Skein can be edited very easily: right-clicking on a knot brings up a contextual menu. (Mac OS X only) (Image skt6.png here) (Mac OS X only) We click on the padlock button (or choose Lock This Branch from the contextual menu), and this makes the thread through to here "locked". That means the knots can't be deleted (unless we unlock them again) - either by our own mistake, or by Inform trimming back no-longer-needed threads of the Skein to keep it manageable in size. (Windows only) We choose Lock This Thread from the contextual menu, and this makes the thread through to here "locked". That means the knots can't be deleted (unless we unlock them again) - either by our own mistake, or by Inform trimming back no-longer-needed threads of the Skein to keep it manageable in size. (Image skt7.png here) Note that this locked history is now drawn as a solid thread, whereas all the others are unlocked and drawn as dashes. Now we have a securely remembered piece of standard play: it means we can try out the sequence TURN ON ALARM / TURN ON METER / WAIT / EXAMINE CHIMES any time we want to with a double-click on the final knot. This is convenient for testing - but so far it only runs the test: to see whether the test came out well or badly, we have to look through what happened, perhaps by scrolling back in the Game panel to look at the text. And that means that we need to remember what the text should have been like. In fact, though, Inform can remember for us, using the Transcript panel. This is closely joined to the Skein panel, and it's often convenient to flip between the two. Turning to the Transcript now, we find a two-column view of the game currently being played. The left-hand column shows the text which has been displayed on each turn so far; the right-hand column is empty. The bottom of the Transcript looks like so: (Image skt8.png here) The empty right-hand column displays the "blessed" transcript - one which the author has approved as being correct. This can be done for each individual knot, using the Bless button joining the columns, but in this case we will bless the whole transcript of this game, using the Bless All button. Now there's text in both columns, and of course the two columns match. (Note that the blessed transcript is in a brighter colour.) (Image skt9.png here) Back in the Skein, we find that the knots which have transcripts have lit up, and are brighter than the others. If we Go, to start a new game, and then look at the Skein: (Image skt10.png here) we see that the knots for which we have blessed a transcript are in a brighter green (or a brighter yellow, if they're in the current game being played). Now suppose we change the source text for the project, so that we make it behave differently. The details don't matter, but suppose we do something which changes the result of the TURN ON METER command, and then run the test again. Now we find: (Image skt11.png here) The red warning badge on the TURN ON METER knot alerts us that the last time this knot was tried (just now, as it happens), the resulting text didn't agree with its blessed transcript. (Red badges can only be seen on bright-coloured knots which have transcripts - for other knots, there's nothing to compare with.) On the other hand, the rest of the yellow current line of play worked out exactly the same as we expected - so no badges. Clicking on the red badge takes us into the Transcript panel at the right place, where the corresponding turn's transcript has also turned red: (Image skt12.png here) (Mac OS X only) Again, what actually happened is on the left; what should have happened is on the right. The change is shown with underlining - we added the text "quivers, then". If we approve this change, by clicking on the Bless button for the red turn, the amended text will become the correct text to compare against in future runs, and the turn will become green to show that once again all is well. (We can also edit the blessed transcript directly, by clicking in the text and typing.) Clicking on the Show knot button takes us back in the skein, at the right place: where we will see that the red warning badge has disappeared. (Windows only) Again, what actually happened is on the left; what should have happened is on the right. The change is shown with underlining - we added the text "quivers, then". If we approve this change, by clicking on the Bless button for the red turn, the amended text will become the correct text to compare against in future runs, and the turn will become green to show that once again all is well. (We can also edit the blessed transcript directly, by double-clicking in the text and typing.) Clicking on the Show knot button takes us back in the skein, at the right place: where we will see that the red warning badge has disappeared. Some writers of IF like to work backwards from a transcript of the game they want to produce, and for them, the Skein and Transcript combination will be helpful as a running picture of what works so far. Other authors may not use the Skein/Transcript feature at all until right at the end of a project, in testing before publication, when it becomes very important to be able to make small changes in one area without upsetting everything else. Either way, the Skein and Transcript together make a very powerful testing aid. (Mac OS X only) This tutorial has shown only a short line of play, to keep the pictures small, but for a large project the Skein might run to thousands of knots. It then becomes important to be able quickly to find key knots corresponding to plot developments. To help with that, we can annotate certain knots with any label we choose (using one of the mouseover buttons, for instance): (Windows only) This tutorial has shown only a short line of play, to keep the pictures small, but for a large project the Skein might run to thousands of knots. It then becomes important to be able quickly to find key knots corresponding to plot developments. To help with that, we can annotate certain knots with any label we choose (by selecting Add Label from the contextual menu): (Image skt13.png here) And this is where the "Labels" gadget at the top of the Skein comes into its own: (Image skt14.png here) since it offers a menu of all the labels in the Skein, and if selected will jump to the one chosen. (Mac OS X only) The Skein has other abilities too, best explored by experimenting. For instance, we can edit the commands by clicking and holding on the command text in a knot. We can add new knots in the middle of existing lines using the "add knot" mouseover button. The Play All Blessed option (on the Build menu in OS X) is especially powerful: it tests each possible blessed history in turn, trying all of them, and can therefore test very complicated multiple endings and the like in a single click. (Windows only) The Skein has other abilities too, best explored by experimenting. For instance, we can edit the commands by selecting Edit Knot from the contextual menu, and we can add new knots in the middle of existing lines using the Insert Knot item on that menu. The Play All Blessed option (on the Game menu) is especially powerful: it tests each possible blessed history in turn, trying all of them, and can therefore test very complicated multiple endings and the like in a single click. (Linux only) The Skein and Transcript are not implemented in the Linux version. (Gnome only) The Transcript is not implemented in the Gnome Linux version. 1.9. Summary of the Skein and Transcript The Skein records the history of different plays through the current project, and the Transcript records the text of each response, comparing it with a "blessed" or correct version if one is available. In the Skein each typed command is a "knot". The threads hanging down from the top "- start -" knot are possible histories. Double-click on a knot to play through to there. Yellow knots are commands played so far in the current game: green knots are possible lines not taken, or not taken yet. A solid thread is "locked" and protected from deletion (by accident or when Inform trims away loose ends): a dashed thread has no such protection. A bright knot has a blessed transcript: a darker knot is one which has no blessed transcript. When a bright knot shows a red badge, this means that when last tested its command produced a textual reply which wasn't the same as the blessed transcript. Clicking on the badge shows exactly how. The thicker thread in the Skein shows the history currently being displayed in the Transcript panel. (Linux only) The Skein and Transcript are not implemented in the Linux version. (Gnome only) The Transcript is not implemented in the Gnome Linux version. 1.10. The Inspector (Mac OS X only) The Inspector window on the Mac OS X interface for Inform is a small separate panel providing additional features designed for use with Inform 6 projects, which this manual does not talk about. On other platforms (notably Windows and Linux), Inform is not designed to support Inform 6, and therefore does not have an Inspector window. (Windows only) The Inspector window on the Mac OS X interface for Inform is a small separate panel providing additional features designed for use with Inform 6 projects, which this manual does not talk about. On other platforms (notably Windows and Linux), Inform is not designed to support Inform 6, and therefore does not have an Inspector window. (Linux only) The Inspector window on the Mac OS X interface for Inform is a small separate panel providing additional features designed for use with Inform 6 projects, which this manual does not talk about. On other platforms (notably Windows and Linux), Inform is not designed to support Inform 6, and therefore does not have an Inspector window. (Gnome only) The Inspector window on the Mac OS X interface for Inform is a small separate panel providing additional features designed for use with Inform 6 projects, which this manual does not talk about. On other platforms (notably Windows and Linux), Inform is not designed to support Inform 6, and therefore does not have an Inspector window with all the features of the Mac OS X interface. (Mac OS X only) The Inspector window is a small separate panel which contains a number of useful ways to look into the project - to inspect it, in fact. This is not the place to document everything the Inspector does, because many of its features are designed for use with Inform 6 ("I6") projects, which this manual does not talk about: what this manual calls Inform is Inform 7 ("I7"). For the same reason, it is not normally open for I7 projects, but can be opened from the Window menu, and its palette of utilities can be selected from the Preferences. (Gnome only) The Inspector window is a small separate panel which contains a number of useful ways to look into the project - to inspect it, in fact. This is not the place to document everything the Inspector does, because many of its features are designed for use with Inform 6 ("I6") projects, which this manual does not talk about: what this manual calls Inform is Inform 7 ("I7"). For the same reason, it is not normally open for I7 projects, but can be opened from the Window menu, and its palette of utilities can be selected from the Preferences. (Mac OS X only) Project Files - I7 projects generally keep their source text in a single file organised internally with headings and subheadings: whereas older I6 projects organised their sources by cutting them into numerous separate files. This panel allows us to switch between those source files, so although it is an essential tool for I6 users, I7 users can leave it closed. (Mac OS X only) Notes - A place where we can type any aides-memoires, notes to ourselves about what to do next, etc.: a sort of scratchpad associated with the project. (Gnome only) Notes - A place where we can type any aides-memoires, notes to ourselves about what to do next, etc.: a sort of scratchpad associated with the project. (Mac OS X only) Index - A contents page for the project, listing all its headings and subheadings. Clicking on one jumps the source panel to the relevant point in the source. While you can see a fuller list of contents from the Contents tab of the Index pane in the main window, this is more concise and may be convenient to keep open, especially if you have a wide screen. (Gnome only) Index - A contents page for the project, listing all its headings and subheadings. Clicking on one jumps the source panel to the relevant point in the source. While you can see a fuller list of contents from the Contents tab of the Index pane in the main window, this is more concise and may be convenient to keep open, especially if you have a wide screen. (Mac OS X only) Skein - A more condensed view of the same Skein shown in the main window panel. (Seeing it here allows us to have this open at the same time as two different panels are open on the main window, and it takes less screen space here.) (Mac OS X only) Watch Expressions - Part of the I6 source-level debugger, so not useful for I7 projects. (Mac OS X only) Breakpoints - Ditto. (Mac OS X only) Search Files - This searches not only the source code, but also the documentation and even the extensions for all references to given text. Search results are produced in a fresh window and clicking on each result jumps the source (or the documentation) there. For instance, searching for "stegosaurus" will almost always bring us to the present page, which is the only one in the documentation containing that word. (Gnome only) Search Files - This searches not only the source code, but also the documentation and even the extensions for all references to given text. Search results are produced in a fresh window and clicking on each result jumps the source (or the documentation) there. For instance, searching for "stegosaurus" will almost always bring us to the present page, which is the only one in the documentation containing that word. Chapter 2: The Source Text 2.1. Creating the world Designing an interactive fiction can be divided into two related activities. One is the creation of the world as it appears at the start of play: where and what everything is. The other is to specify the rules of play, which shape how the player interacts with that initially created world. A new Inform project is void and without form, so to speak, with nothing created: but it starts with hundreds of standard rules already in place. The same division between creating things, and laying down rules, is visible in Inform source text. The creation of the world is done by making unconditional factual statements about it. For example, The wood-slatted crate is in the Gazebo. The crate is a container. Inform calls sentences like these "assertions". The verb is always written in the present tense (thus the crate "is", not "will be"). Further examples are: Mr Jones wears a top hat. The crate contains a croquet mallet. The words "is", "wears" and "contains" are forms of three of the basic verbs built in to Inform. There are only a few built-in assertion verbs, of which the most important are to be, to have, to carry, to wear, to contain and to support. (As we shall see, further assertion verbs can be created if needed.) The world described by these assertions is the starting condition of the game: what happens when play begins is another matter. If somebody picks up the crate and walks off with it, then it will no longer be in the Gazebo. Mr Jones may remove his hat. 2.2. Making rules The other kind of sentence tells Inform what should happen in certain circumstances, and reads like an instruction issued to someone: Instead of taking the crate, say "It's far too heavy to lift." This is a "rule", and it changes the crate's behaviour. The player who tries typing "take crate", "pick up the crate" or similar will be met only with the unhelpful reply "It's far too heavy to lift." The many different kinds of thing which the player can do are called "actions", and are always written as participles: "taking ...", for instance, or "putting ... on ...". Inform is built on a mass of several hundred rules, some quite complex, and it could even be said that Inform is that mass of rules. We never see the complexity behind the scenes because the whole aim is to provide a basic, penny-plain, vanilla flavoured sort of realism. It would be surprising if one could put the crate inside itself, so a rule exists to forbid this. It would be surprising if one could drop something which was already on the ground, and so on. These basic rules of realism are the ones which every new Inform project starts with. 2.3. Punctuation The example rule just given demonstrates one of Inform's conventions about punctuation, and is worth pausing to look at again. Instead of taking the crate, say "It's far too heavy to lift." In English grammar, it's usual to regard a full stop as closing its sentence even when it occurs inside quotation marks, provided there is no indication to the contrary, and this is also the rule used by Inform. Thus: The description is "Shiny." It is valuable. is read as equivalent to The description is "Shiny.". It is valuable. Sentence breaks like this occur only when the final character of the quoted text is a full stop, question mark or exclamation mark (or one of these three followed by a close bracket) and the next word begins, in the source code, with a capital letter. A paragraph break also divides sentences, behaving as if it were a full stop. Text in square brackets [like so] is "comment", in computing jargon: it is considered as being an aside, a private note by the author, and not read in by Inform. This allows us to make notes to ourselves like so: The China Shop is a room. [Remember to work out what happens if the bull gets in here!] Double quotation marks can't be used in text, because they would end the piece of text then and there. Instead, we use single quotation marks: Instead of taking the crate, say "Simon says, 'It's far too heavy to lift.'" Inform will automatically convert the speech marks to double-quotes when it prints, resulting in: Simon says, "It's far too heavy to lift." Note that apostrophes inside words, such as the one in "it's", remain apostrophes. This is a rule which sometimes goes wrong. In: Instead of going outside, say "Lucy snaps, 'What's the matter? You don't trust my cookin' mister?'" the apostrophe at the end of "cookin'" is wrongly made into a double-quote. We can get around this by writing: Instead of going outside, say "Lucy snaps, 'What's the matter? You don't trust my cookin[apostrophe] mister?'" which shows another punctuation convention of Inform: inside quoted matter, like the line being said here, square brackets are used to describe what to say without giving the literal text. We shall see many more usages of this convention in later chapters. For now, this seems the place to mention just two other points: ['] is a convenient abbreviation for "[apostrophe]", and has the same effect; and "[quotation mark]" makes a double-quote, but ["] is not allowed. As these examples begin to show, Inform source imitates the conventions of printed books and newspapers whenever there is a question of how to write something not easily fitting into words. The first example of this is how Inform handles headings, but to see why these are so useful we first look at Problems. 2.4. Problems The language used in the source reads as if it were English aimed at a human reader (and this is intentional: the designer, after all, is a human reader and needs to be able to understand his or her own source), but in reality Inform can only understand a very modest range of sentences and will complain if its limits are passed. Subtler problems arise if the source contains contradictions. For instance, the following "Problem" might be produced: Problem. You wrote 'A starting pistol is in the cup' (Image Reveal.png here), but in another sentence 'A Panama hat is on the cup' (Image Reveal.png here): the trophy cup cannot both contain things and support things, which is what you're implying here. If you need both, the easiest way is to make it either a supporter with a container attached or vice versa. For instance: 'A desk is here. On the desk is a newspaper. An openable container called the drawer is part of the desk. In the drawer is a stapler.' This is a rather discursive error message, and a similar problem were to occur in the same run through, it would be curtailed to: Problem. You wrote 'A firing pistol is in the box' (Image Reveal.png here), but in another sentence 'A fedora hat is on the box' (Image Reveal.png here): again, the croquet box cannot both contain things and support things. 2.5. Headings (Mac OS X only) Once the source grows beyond 1000 words or so, it can all too easily become disorganised, and by the time it reaches the size of a novella it can be difficult to find things (though the Mac OS X user interface provides a Find function, Command-F). (Windows only) Once the source grows beyond 1000 words or so, it can all too easily become disorganised, and by the time it reaches the size of a novella it can be difficult to find things (though the Windows user interface provides a Find function, Ctrl-F). (Linux only) Once the source grows beyond 1000 words or so, it can all too easily become disorganised, and by the time it reaches the size of a novella it can be difficult to find things (though nearly all editors provide a Find function). Inform provides for us to organise the source code in just the way that a printed book would be organised: with headings and subheadings. Firstly, we can put the title at the top. If the first paragraph consists only of a single quoted piece of text, then that's the title; and an author can also be given, as follows: "Spellbreaker" by Dave Lebling We will later see that more bibliographic information can also be placed here, in the same way that the imprint page of a novel comes before the text gets going. The author's name can normally be given without quotation marks, so long as it contains no punctuation. For instance: "Three Men in a Boat" by "Jerome K. Jerome" needs quotes as otherwise the full stop after the K will be mistaken for the end of a sentence. A sentence which is the only one in its paragraph and which begins with any of the words "volume", "book", "part", "chapter" or "section" is considered to be a heading or a sub-heading. It must not contain a typed line break, and in order to stand alone in its paragraph there should be a skipped line both before and after it. For instance: Section 2 - Flamsteed's Balloon Headings can be written in any format, provided they start with one of the five indicator words, and they are hierarchical: a "Part ..." heading is considered more significant than a "Chapter ..." heading but not so significant as a "Book ..." heading, and so on. (We do not need to use all five kinds of heading.) 2.6. Why using headings is a good idea Reports of problems, as we have seen, often quote back the source to justify themselves. Rather than quoting line numbers ("Midsummer Day, line 2017" or something similar) Inform uses the (Image Reveal.png here) icon. The down side of this is that a glance at the list of problems might give little hint of whereabouts in the source the difficulties lie. Inform therefore makes use of headings to give a general indication: In Part the First, Chapter 1 - Attic Area: Problem. You wrote 'South of the Attic is the Winery' (Image Reveal.png here), but in another sentence 'South of the Attic is the Old Furniture' (Image Reveal.png here): this looks like a contradiction, which might be because I have misunderstood what was meant to be the subject of one or both of those sentences. In Chapter 2 - Deeper In: Problem. You wrote 'The Disused Observatory is south of the Dark Room' (Image Reveal.png here), but in another sentence 'South of the Dark Room is the Cupboard' (Image Reveal.png here): again, this looks like a contradiction. Secondly, headings are used in the Contents tab of the Index, and are also displayed in the Inspector window of the Mac OS X Inform application: in both cases they allow rapid navigation through the source, by jumping to any heading or subheading with a single click. Finally, headings are used when working out what a name refers to. Suppose the source contains both a "four-poster bed" and also a "camp bed", and we write something like "The pillow is on the bed." Inform decides which bed is meant by giving priority to whichever is defined in the current section, or failing that the current chapter, or current part, or current book, or finally the current volume. This allows us to write, for instance, The four-poster bed is in the Boudoir. The pillow is on the bed. and not have the pillow mysteriously turn up on the camp bed, which hasn't been mentioned since way back in Chapter 2. 2.7. The SHOWME command Problem messages are generated when the source text does not make sense to Inform. Even if it does make sense, though, there is no guarantee that it does what the author intends, and the only way to find out is to test the result by playing through it (or asking others to). For the most part one plays as if one were the eventual reader of the work, but sometimes it is highly convenient to have the god-like powers which are an author's prerogative. These are provided by the testing commands, which are present at every stage until the final release version (generated by the Release button). They will be introduced in this manual as they become relevant: here is the first. (Testing command) The testing command SHOWME prints out a brief summary about a room or thing, and any contents or parts it may have. Typing SHOWME on its own shows the current room, but any item or room in the game, however distant, can be named instead. For instance: >showme Boudoir - room four-poster bed - supporter yourself - person pillow >showme diamonds diamonds - thing location: in the strongbox on the dresser in the Drawing Room unlit; inedible; opaque; portable; singular-named; improper-named description: The diamonds glitter dangerously. printed name: diamonds Much of this can be seen, and seen more easily, in the World tab of the Index panel: but that only shows the initial state of play, whereas the SHOWME command reveals the situation in mid-game. ("Room", "supporter" and so on are kinds, of which more in Chapter 3.) 2.8. The TEST command The only way to thoroughly test a work of IF is to run a complete solution through it, and carefully check the resulting transcript of dialogue. The Skein and Transcript tools of the Inform application are provided for exactly this purpose. All the same, most works of interactive fiction contain occasional vignettes, either in terms of short scenes of narrative, or in the behaviour of particular things or rooms, which we would like to test without the fuss of using the full game-level Skein tool. The examples in the documentation are like this: in almost every example, typing TEST ME puts the game through its paces. (Testing command) Solutions or sequences for testing ("scripts") can be defined with sentences like so: Test balloon with "get balloon / blow balloon / drop balloon". This has no effect on the design itself, but ensures that when the game is played, typing "test balloon" will run through the given three commands in sequence, as if we had typed "get balloon" and then "blow balloon" and then "drop balloon". The name for the test (balloon in this example) has to be a single word. Typing just "test" at the game prompt gives a list of all the test scripts known to the game. Test scripts can make use of each other, for instance: Test all with "test balloon / test door". One convenient way to keep track of the solution for a work being written is to include a test script at the end of each section, and to place a master test script (like "test all") at the top of the source. But different designers will prefer different approaches, and this testing system is no more than an optional convenience. Many tests will only be sensible in given places, which may be hard to reach from the initial position; or with the aid of given things, which may be difficult to obtain. We are therefore allowed to add stipulations to test scripts: Test balloon with "get balloon / blow balloon / drop balloon" holding the balloon. The "... holding the balloon" means that the balloon will be transferred to the player's ownership immediately before the test script is run, unless it is already held. Similarly: Test jam with "get jam / taste jam / eat jam" in the Kitchen. Or we might want to say both: Test jam with "get jam / taste jam / eat jam" in the Kitchen holding the jam. (Single quotation marks in test scripts are interpreted the same way in test scripts as they are in other text: that is, they are sometimes read as double-quotes unless they appear to be present as apostrophes. The notation ['] forces a single quotation mark if necessary. Similarly, [/] forces a literal forward slash, and prevents the / from being read as dividing up two commands.) 2.9. Material not for release Special testing commands, like "TEST" and "SHOWME", are automatically excluded from the game if it is exported from the Inform application using the Release button. We sometimes want to write our own for-testing-purposes-only code, though, and for this purpose we are allowed to designate whole headings as being "not for release": Section 10 - Open sesame - Not for release Universal opening is an action applying to nothing. Understand "open sesame" as universal opening. Carry out universal opening: now all doors are open. Report universal opening: say "Open Sesame!" Clearly we do not wish the final reader to be able to type "OPEN SESAME", so this whole heading will be disregarded in the Release version, as will any heading whose name includes "not for release". Note that if a chapter, say, is marked as "not for release", then its subheadings (mere sections) will also not be for release. If in doubt, check the "Contents" index: if any section is "not for release" then so are all of its subheadings. 2.10. Installing extensions The original Inform of 1993 provided no special facilities for "extensions" - in effect, additional packets of rules providing extra features - but the creation and circulation of these extensions soon became a flourishing part of Inform culture. Today's Inform actively promotes sharing of such extensions, both to bring writers together and to support good practice. For the user of an extension, the advantage is clear: why go to great trouble to (say) work out how to make doors open automatically as needed, when somebody else has already perfected this? For the writer of an extension, there is the satisfaction of producing a good solution to a ticklish problem, and contributing to the public good. Newcomers will probably not need extensions for quite some while, but there is nothing difficult about using them, so a few brief notes are worth giving here. (The final chapter of the documentation covers the writing of new extensions.) Extensions are identified by name (say "Following People") and also by author (say "Mary Brown"). They will probably be downloaded from the Internet as needed, or exchanged by email, but they need to be installed before they can be used. (Mac OS X only) When using Inform on Mac OS X, this means storing them in the folder (Mac OS X only) ~/Library/Inform/Extensions/ (Mac OS X only) where "~" signifies your home folder. (Your home folder and its Library subfolder will already exist, but you may need to create "Inform" and then "Extensions" by hand with the Finder.) Each author has a subfolder of this folder, and his or her extensions live inside it. Our example extension should therefore be placed as: (Mac OS X only) ~/Library/Inform/Extensions/Mary Brown/Following People (Windows only) When using Inform on Windows, this means storing them in the folder (Windows only) My Documents\Inform\Extensions (Windows only) Each author has a subfolder of this folder, and his or her extensions live inside it. Our example extension should therefore be placed as: (Windows only) My Documents\Inform\Extensions\Mary Brown\Following People (Linux only) When using Inform on Linux, this means storing them in the folder (Linux only) ~/Inform/Extensions/ (Linux only) where "~" signifies your home folder. (This will have been created for you the first time you ran i7.) Each author has a subfolder of this folder, and his or her extensions live inside it. Our example extension should therefore be placed as: (Linux only) ~/Inform/Extensions/Mary Brown/Following People (Gnome only) When using Inform on Linux, this means storing them in the folder (Gnome only) ~/Inform/Extensions/ (Gnome only) where "~" signifies your home folder. (This will have been created for you the first time you ran i7.) Each author has a subfolder of this folder, and his or her extensions live inside it. Our example extension should therefore be placed as: (Gnome only) ~/Inform/Extensions/Mary Brown/Following People (no filename extension is used). In fact, though, Inform can automatically install extensions for us: we need only select the "Install Extension..." item on the File menu. The actual extension file is sometimes named with a ".i7x" suffix, meaning "I7 extension" - for instance, "Following People.i7x" - but this is not compulsory. To provide an example, Emily Short's useful extension "Locksmith" is one of a small number of extensions which come ready-installed as part of the basic Inform package, and need not be downloaded and installed. Each time that Inform translates any source text, it performs a quick check of the extensions available, and updates its own internal records. A directory of the extensions currently installed can be found by clicking on "Installed Extensions" from the contents page of the documentation. 2.11. Including extensions We talk about "including" such an extension into a work of IF because the process merges rules and behaviours from the extension with those we have described ourselves. It's not uncommon for contributions by five or six different people to be pooled together this way. Including an extension is only a matter of writing a single sentence in the source. For instance: Include Locksmith by Emily Short. Note that it is compulsory to name both extension and author. An extension which Inform has noticed in the extensions folder receives only a brief listing in the Inform documentation at first. But once it has been used for the first time, by being included in a successfully translated source text - even if only a tiny one - the new extension is indexed more thoroughly, and its own documentation is added to Inform's, as if extra pages were being added at the back of a ring-binder. Again, follow the "Installed Extensions" link to see this additional documentation. 2.12. Use options One more preliminary. Inform has a small number of optional settings which affect the result of translating the source. The sentence: Use American dialect. makes the resulting work of IF use American spellings (except where the designer spells otherwise) and the American convention for spelling out numbers (thus, "one hundred seventeen" not "one hundred and seventeen"). Similarly: Use the serial comma. uses a comma when printing lists: thus "Julian, Dick, George, and Anne" rather than "Julian, Dick, George and Anne". A more profound change is made by Use no scoring. which abolishes the concept of a numerical score - something which modern authors of interactive fiction often feel is inappropriate, but which Inform does provide by default. Two alternative options: Use full-length room descriptions. Use abbreviated room descriptions. change the normal way room descriptions are shown: normally they are given in full when the room is first entered, but are subsequently shortened unless the player actually asks to "look". In full-length mode, they are always given in full; in abbreviated mode, never. (The latter is a bad idea in any publically released game, but is provided for completeness and in case it may help testing.) Then we have: Use undo prevention. which disables the UNDO verb, both in play and after death, for the benefit of games which are heavily randomised and where we do not want players to keep on UNDOing until they get a random outcome which is to their taste. (Many players consider UNDO to be their birthright, and that any work using this option is an abomination: indeed, it has even been suggested that this section of the Inform documentation be censored. To use the option is to court controversy if not outright hostility.) We can combine any number of options in a single "Use" sentence, so for example: Use American dialect and the serial comma. brings about both of these changes. 2.13. Limits and the Settings panel No computer has unlimited capacity, and a large, complex project may eventually bump its head against the ceiling. Inform is a system for translating textual descriptions of interactive fiction into "story files". No single format of story file is standard to the IF community. The formats developed over the history of IF differ in three key respects: - the range of computers or devices capable of playing them; - how large they are, that is, how much play they can express; - what extra-textual effects they can bring off. Inform can write to four different formats. None of these are proprietory, and none were created by the authors of Inform: each of the formats is a community property, defined by published standards documents. Each individual Inform project has its own choice of story file format, which can be changed using that project's Settings panel. The format normally used is known as version 5 of the Z-machine, or "z5", which is highly standardised and can be played on a very wide range of computers, including a few handheld devices. For a small or medium-sized work of IF with no need of pictures, its widespread playability almost certainly makes it the best choice. Larger works will need version 8, or "z8". For very large works of textual IF, or to introduce pictures, the best option is to switch to the Glulx format. (In principle, the Z-machine version 6, or "z6", is also capable of displaying pictures, but Inform's support for z6 is limited and Glulx is a much better option.) Internally, the Inform application uses a tool called Inform 6 (which was once the entire Inform system) to manufacture the story file. There are therefore two ways that large projects can run out of space: (a) By exceeding some maximum in Inform 6, or (b) By exceeding some fundamental limitation of the current story file format. In both cases, the Inform application will display a Problems page explaining that the Inform 6 tool has failed to work as intended, and refer us to the "console output" - the text produced by Inform 6 - which is normally ignored, but can be found on the Progress tab of the Errors panel. In case (a), Inform 6 will say that a memory setting has been exceeded: it will say what this setting is called (for instance "MAX_ZCODE_SIZE") and what its current value is (for instance 50000). We can then avoid the problem by adding the following use option into the source text: Use MAX_ZCODE_SIZE of 60000. And similarly for every other Inform 6 memory setting. (If the source tries to specify the same setting more than once - which is quite possible if extensions are included, with rival ideas - then the highest value is used.) In case (b), we must either switch to a larger story file format, or economise. The simplest thing to do is to switch up from z5 to z8, and then from z8 to Glulx, until no limits are reported any more. (Glulx has a huge capacity, so we need never worry about size limits again.) However, if we really do need to stick to a specific format - say, if we want a story file playable on a tiny handheld computer unable to manage Glulx - we still have a few options. Unless the story is very large (in which case there is little we can do), the "z8" format is most likely to be exhausted for lack of what is called "readable memory", with a message like so: This program has overflowed the maximum readable-memory size of the Z-machine format. See the memory map below: the start of the area marked "above readable memory" must be brought down to $10000 or less. followed by a tabulation of how the Z-machine's storage has been used, a large but not very useful diagram. The first time one runs into the problem on a large project, it can be postponed, by adding the following to the source: Use memory economy. (Economy cuts down the verbosity of some of the testing commands, but otherwise subtracts no performance.) Writing this into the source is the equivalent of a diver switching to an emergency oxygen tank: it gives us a generous safety margin, but also tells us that now is the time to wrap things up. If we hit the problem again, genuine cuts must be made. As a general rule, the most memory-expensive ingredients of an Inform design are various-to-various relations between large kinds such as "thing" or, if there are many rooms, "room". Other than that, if a kind has been festooned with new properties and we have created dozens of items of that kind, then we can get a fairly large saving simply by doing without one of those properties; and so on. The ultimate memory-saving device, of course, is the one used by book publishers when there are too many pages to bind: to cut the design into two stories, Part I and Part II. 2.14. What to do about a bug In its present guise, Inform is a young piece of software, and bugs are to be expected from time to time. The most obvious bugs are the ones which Inform catches itself, when it confesses that it has halted in failure, or translated the source text into a program which cannot be compiled further. But sometimes it will also happen that Inform will issue a misleading Problem message, or appear to work normally but to produce a game which does not do what it should have done. It is very helpful for users to report faults, so that the program can be improved for everyone else. To report a fault, please first check with the Inform home page to make sure that the fault is present in the latest version of Inform available: if so, then please also download the bug report form and fill in a copy. Further details are on the form itself. Inform's home page is: www.inform-fiction.org and the site map may be the quickest way to find the form. 2.15. Does Inform really understand English? No. No computer does, and Inform does not even try to read the whole wide range of text: it is a practical tool for a particular purpose, and it deals only with certain forms of sentence useful to that purpose. Inform source text may look like "natural language", the language we find natural among ourselves, but in the end it is a computer programming language. Many things which seem reasonable to the human reader are not understood by Inform. For instance, Inform understands something which is carried by the player but not (at present, anyway) something which the player carries even though both are perfectly good English. So it is not always safe to assume that Inform will understand any reasonable instruction it is given: when in doubt, we must go back to the manual. More philosophically, to "understand" involves contextual knowledge. Just because Inform recognises and acts on a sentence, does it really understand what we meant? It will turn out that Inform is both good and bad at this. For instance, from Mr Darcy wears a top hat. Inform will correctly deduce that Darcy is a person, because inanimate objects do not ordinarily wear clothes, and that the top hat is clothing. But it will not automatically know that Darcy is a man rather than a woman because it does not know the social convention implied by "Mr". Moreover, if instead we had written Mr Darcy carries a top hat. then Inform would not guess that the top hat is clothing. This is because it does not have the vast vocabulary and experience of a human reader: it is probably discovering the word "hat" for the first time. Finally, it is best to avoid ambiguities rather than rely on Inform to know which meaning is patently absurd. For instance, in Heatwave bone breaks clog hospital. (a headline once printed by the Oxford Mail newspaper) a human reader quickly realises that there is no clog hospital being broken. But if Inform had been taught the verbs to break and to clog then that is exactly the conclusion it would have drawn. Or an example which genuinely arose in beta-testing: The life support unit fits the egg. in which Inform construed the verb as support and not fits, and then created items called "the life" (plural) and "unit fits the egg". That disclaimer completes the groundwork, and we are ready to begin on simulating a world to explore. 2.16. Review of Chapter 2: The Source Text 1. The content of the text. (a) Assertions. An assertion is a sentence describing the initial state of the world. These are all assertions: The Twinkie is a thing. The description of the Twinkie is "A confection made of gelatin and preservatives." Two hands are part of every person. The prevailing wind is a direction that varies. Assertions are the main subject of the next two chapters. (b) Rules. Rules tell Inform how the interactive fiction is to behave under certain circumstances. A rule may be fairly short, as When play begins, say "Welcome aboard, Mr Bond." or may contain a longer sequence of instructions, as in Instead of attacking the donkey: remove the donkey from play; if the donkey carries something, now everything carried by the donkey is in the location; say "The donkey bolts, of course." Rules will be covered in much more detail later, but for now note the punctuation: a rule is a list of "phrases". Each phrase except the last ends with a semi-colon to show that the rule is not finished yet. We may only use "if..." (such as "if the donkey carries something...") within a rule, where Inform can be sure of exactly when the condition is to be considered. (As we shall see later, "Instead of attacking the monkey" tells Inform when the rule is applied.) So the following is not allowed: The Rain Forest is a room. If the player is in the Rain Forest, say "Rain falls steadily on your hat and rucksack." (If the idea is to apply this test all of the time, it needs to be wrapped up in a rule making this clear. "Every turn: if the player is..." would do the trick, as we shall see in the chapter on Time.) (c) Headings. Headings are typed in their own paragraphs (with a skipped line above and below) and start with one of the words Volume, Book, Part, Chapter or Section. (When typed, they immediately become bold in the source panel.) Headings are useful because they help us to organise and find our way around a large source text. They also make problem messages clearer. (d) Comments. Comments enclosed in square brackets [like this] allow us to insert our own remarks about the source text. Inform ignores them: they're for our own benefit only. (e) Tables of information. These have not yet appeared, but look like tables printed in books. They will be the subject of a later chapter. (f) A few special sentences. A few sentences are read by Inform as instructions on how we want the source text to be understood. For instance, we can say "Use American dialect" or tell Inform to "Include Locksmith by Emily Short" (or some other extension set of rules, by some other author). 2. Testing and Troubleshooting (a) What's where? Sometimes, during play, we want to see where everything now is. Inform contains a number of testing commands giving us a look behind the scenes: one of these is SHOWME. For instance, if there is a helmet somewhere, SHOWME HELMET tells us about it. Typing SHOWME alone tells us about the current location. (b) Making our own test commands. We can for instance write: Test helmet with "wear helmet / listen / x helmet / doff helmet". This creates a short sequence of commands which we can replay during the game at any time in order to test whether the helmet does what we intended. (Like all testing commands, these will be omitted from any finished games we create with the Release button. We can exclude other testing-purposes-only material, too, by placing it under a heading which includes the words "not for release".) (c) Limits. There are several formats in which we can release a finished game. The advantage of the smallest "z5" format is that it is highly portable and can be played on the widest selection of machines, including various kinds of handheld computer. Inform uses this format for any newly-begun project. If we should run out of space, Inform will advise on the options, but the only way to gain a large amount of extra room is to use the Settings panel to switch to a larger format. Chapter 3: Things 3.1. Descriptions At its simplest, the interactive fiction will be simulating a physical world to explore. The forerunner of today's IF is generally agreed to be a computer simulation by Will Crowther of the exploration of a cave system in the Mammoth and Flint Ridge chain of caves in Kentucky, a part of which might be described in Inform thus: "Cave Entrance" The Cobble Crawl is a room. "You are crawling over cobbles in a low passage. There is a dim light at the east end of the passage." A wicker cage is here. "There is a small wicker cage discarded nearby." The Debris Room is west of the Crawl. "You are in a debris room filled with stuff washed in from the surface. A low wide passage with cobbles becomes plugged with mud and debris here, but an awkward canyon leads upward and west. A note on the wall says, 'Magic word XYZZY'." The black rod is here. "A three foot black rod with a rusty star on one end lies nearby." Above the Debris Room is the Sloping E/W Canyon. West of the Canyon is the Orange River Chamber. Here we sketch in four of Crowther's locations, and two objects: just enough to be able to walk around the caves and pick up the rod and the cage. The text in quotation marks will appear verbatim as paragraphs shown to the player as the caves are explored. The first paragraph, as we have seen, is the title of the work. The other quotations describe the places and objects introduced. If we play this game, we find that we can type TAKE CAGE or TAKE WICKER CAGE, for instance, but not TAKE SMALL CAGE. Inform saw that we called this "a wicker cage" when it first appeared in the source text, and assumed that the player would call it that, too. (Whereas it didn't look inside the descriptive text to allow for TAKE SMALL CAGE or TAKE DISCARDED CAGE or TAKE NEARBY CAGE.) A small limitation here is that probably only the first 9 letters of each word are read from the player's command. This is plenty for handling the wicker cage and the black rod, but it might be embarrassing at a meeting of the Justice League to find that KISS SUPERHERO and KISS SUPERHEROINE read as if they are the same command. So we have already found that Inform has made some assumptions about what we want, and imposed some limitations on how much computational effort to go to when the work of IF is finally played. If Inform guesses what we need wrongly, we need to know more advanced features of the language in order to overcome these problems. (We shall see how to change the way the player's commands are read in the chapter on Understanding.) This is often how Inform works: make the standard way of doing things as simple as possible to describe, but allow almost any behaviour to be altered by more elaborate source text. Example 2 (*): Verbosity Making rooms give full descriptions each time we enter, even if we have visited before. Example 3 (**): Slightly Wrong A room whose description changes slightly after our first visit there. 3.2. Rooms and the map Rooms are joined together at their edges by "map connections", most of which are pathways in one of the eight cardinal compass directions: north, northeast (written without a hyphen), east, southeast, south, southwest, west, northwest. We also have up and down, suitable for staircases or ladders. In real life, people are seldom conscious of their compass bearing when walking around buildings, but it makes a concise and unconfusing way for the player to say where to go next, so is generally accepted as a convention of the genre. Two more directions are provided by Inform: "inside" and "outside". These are best used when one location is, say, a meadow and the other is a woodcutter's hut in the middle of it; we might then say Inside from the Meadow is the woodcutter's hut. The "from" is important, as it clarifies that we intend to link two different locations, not to create an item - the hut - in a single location - the meadow. A problem which sometimes arises when laying out maps is that Inform allows short forms of room names to be used as abbreviations. This is usually a good idea, but has unfortunate results if we write: The Airport Road is west of the Fish Packing Plant. The Airport is west of the Airport Road. ...because "Airport" is taken as a reference to "Airport Road", so Inform makes only two locations, one of which supernaturally leads to itself. We can avoid this by writing: The Airport Road is west of the Fish Packing Plant. A room called the Airport is west of the Airport Road. Using "called" is often a good way to specify something whose name might give rise to confusion otherwise. It always makes something new, and it is also neatly concise, because we can establish something's kind and name in the same sentence. As another example, suppose we want to create a room called "South of the Hut", to south of the Hut. We can't do so like this: South of the Hut is a room. South of the Hut is south of the Hut. ...because Inform will read that first sentence as placing a (nameless) room to the south of a room called "Hut". Once again "called" can save the day: South of the Hut is a room called South of the Hut. It is best to use "called" in the simplest way possible, and in particular, best not to use "called" twice in the same sentence. Consider: The kitchen cabinet contains a container called a mixing bowl and a portable supporter called a platter. It is unlikely that anyone would want to name something "a mixing bowl and a portable supporter called a platter", but not impossible, and Inform tends not to be a good judge of what is likely. Example 4 (*): Port Royal 1 A partial implementation of Port Royal, Jamaica, set before the earthquake of 1692 demolished large portions of the city. Example 5 (**): Up and Up Adding a short message as the player approaches a room, before the room description itself appears. Example 6 (***): Starry Void Creating a booth that can be seen from the outside, opened and closed, and entered as a separate room. 3.3. One-way connections Connections are ordinarily two-way, but do not have to be. One of the map connections in the Mammoth Cave simulation was made by the sentence: The Debris Room is west of the Crawl. Besides reading this sentence at face value, Inform also deduced that the Crawl was probably meant to be east of the Debris Room: in other words, that the path between them is a two-way one. When Inform makes guesses like this, it treats them as being less certain than anything explicitly stated in the source. Inform will quietly overturn its assumption if information comes to hand which shows that it was wrong. That might happen in this case if another sentence read: The Hidden Alcove is east of the Debris Room. These two sentences are not contradictory: Inform allows them both, simply accepting that the world is more complicated than it first assumed. There are relatively few situations where Inform has to make educated guesses, but when it does, it tries always to follow Occam's Razor by constructing the simplest model world consistent with the information in the Source text. We can even explicitly make a route which turns around as it leads between two rooms: West of the Garden is south of the Meadow. Finally, if we want to establish a route which cannot be retraced at all, we can specify that a particular direction leads nowhere: East of the Debris Room is nowhere. Example 7 (*): Port Royal 2 Another part of Port Royal, with less typical map connections. Example 8 (*): The Unbuttoned Elevator Affair A simple elevator connecting two floors which is operated simply by walking in and out, and has no buttons or fancy doors. 3.4. Regions and the index map Rooms represent individual places to which one can go, but we tend to think of the world around us in larger pieces: we think of a house and a garden, rather than each of the single rooms of the house and all corners of its garden. To Inform a collection of rooms is called a "region", and we can create one like so: The Arboretum is east of the Botanical Gardens. Northwest of the Gardens is the Tropical Greenhouse. The Public Area is a region. The Arboretum and Gardens are in the Public Area. The real usefulness of creating regions like "Public Area" will only appear later, when we begin defining rules of play which apply in some areas but not others, but in the mean time we can see the effect by turning to the World tab of the Index. In the World Index, Inform draws a map - or at least a stylised attempt at a diagram of the rooms and their connections: this will not always correspond to how we imagine things, but with any luck it should mostly be right. Rooms are represented by coloured squares, and the colour-coding is done by region. In the above example, the two "Public Area" rooms are coloured green (as it happens); the Greenhouse, since it belongs to no region, is a neutral grey. Regions can be put inside each other: The University Parks is a region. The Public Area is in the University Parks. but they are not allowed to overlap other than by one being entirely inside the other. (See Improving the index map for ways to adjust the way the index map is drawn or exported for publication.) Example 9 (*): Port Royal 3 Division of Port Royal into regions. 3.5. Kinds The following description runs to only 33 words, but makes a surprisingly intricate design. It not only places things within rooms, but also places them very specifically with respect to each other: "Midsummer Day" East of the Garden is the Gazebo. Above is the Treehouse. A billiards table is in the Gazebo. On it is a trophy cup. A starting pistol is in the cup. Inform needs to identify the places and objects being described by the nouns here, and to guess what it can about them. For instance, the pistol can be picked up but not walked inside, whereas the Treehouse is the reverse. (This is obvious to someone who knows what these words mean, less obvious to a computer which does not, but the text contains sufficient clues.) Inform does this by sorting the various nouns into different categories, which are called "kinds". For instance: Garden, Gazebo, Treehouse - room billiards table - supporter cup - container starting pistol - thing East, up (implied by "above") - direction (A container is something which can contain other things, and a supporter similarly.) For instance Inform knows that if one thing is in another, then the second thing is either a room or a container, and if one thing is on another, the second thing is a supporter. This worked nicely for the design above, but: In the Treehouse is a cardboard box. results in the cardboard box being made only a "thing": because nothing has been put inside it, there is no reason for Inform - which does not know what a cardboard box looks like - to guess that it is a "container". So we need to add: The box is a container. It is rather clumsy to have to write two sentences like this, so we would normally write this instead: In the Treehouse is a container called the cardboard box. Example 10 (*): First Name Basis Allowing the player to use different synonyms to refer to something. Example 11 (*): Midsummer Day A few sentences laying out a garden together with some things which might be found in it. 3.6. Either/or properties Some containers, like bottles, can be opened: others, like buckets, cannot. If they can be opened, then sometimes they will be open, and sometimes closed. These are examples of properties, which can change during play. The following source sets some properties: The cardboard box is a closed container. The glass bottle is a transparent open container. The box is fixed in place and openable. There are only four different properties referred to here. Closed means not open, and vice versa, so these two adjectives both refer to the same property. (As might be expected, when a container is open, one can see inside and place things within, or take them out.) The glass bottle and the box being containers is a matter of their kinds, which is something fundamental and immutable, so "container" does not count as a property. A "transparent" container is one which we can see inside even when it is closed, and the opposite is an "opaque" container. The property of being "fixed in place" ensures that the player cannot pick the item up and walk away with it: this is useful for such things as oak trees or heavy furniture. The opposite condition is to be "portable". A container which is "openable" can be opened or closed by the player. This property has no friendly adjective for its opposite, so we would need to write "not openable". (Inform does not guess that, say, "unopenable" means "not openable". Such guesses are too risky, when so many "un-" words are irregular: "unified", "uncle", "ungulate" and so on.) With a really large cardboard box, we might imagine that the player could get inside: such a container should be declared "enterable". Example 12 (*): Tamed Examples of a container and a supporter that can be entered, as well as nested rooms. 3.7. Properties depend on kind Properties depend very much on kind. It makes no sense to ask whether a room is transparent or opaque, for instance, so Inform will not allow this either to be specified or queried. Another way that kind influences properties can be seen from an earlier example: The Gazebo is a room. A billiards table is in the Gazebo. On it is a trophy cup. A starting pistol is in the cup. The cup, the pistol and the table are all allowed to have the "fixed in place" property, but in fact only the table actually has it: the cup and the pistol are created as "portable" instead. This is because Inform knows that most things are portable, but that supporters - such as the table - are usually fixed in place. If this assumption is wrong, we need only add the line: The table is portable. Example 13 (*): Disenchantment Bay 1 A running example in this chapter, Disenchantment Bay, involves chartering a boat. This is the first step: creating the cabin. 3.8. Scenery As we have just seen, making something "fixed in place" will prevent it from being picked up or moved. But it remains substantial enough to be described in its own paragraph of text when the player visits its location. This can be unfortunate if it has also been described already in the body of the main description for that location. For instance, if we wrote: The Orchard is a room. "Within this quadrille of pear trees, a single gnarled old oak remains as a memory of centuries past." The gnarled old oak tree is fixed in place in the Orchard. This would end up describing the oak twice, once in the paragraph about the Orchard, then again in a list of things within it: Orchard Within this quadrille of pear trees, a single gnarled old oak remains as a memory of centuries past. You can see a gnarled old oak tree here. We avoid this by making it "scenery" instead of "fixed in place": The gnarled old oak tree is scenery in the Orchard. Any thing can be scenery, and this does not bar it from playing a part in the game: it simply means that it will be immobile and that it will not be described independently of its room. Being immobile, scenery should not be used for portable objects that are meant to be left out of the room description. If a supporter is scenery, it may still be mentioned in the room description after all, but only as part of a paragraph about other items, such as On the teak table are a candlestick and a copy of the Financial Times. If the player takes the candlestick and the Times, the teak table will disappear from mention. (Scenery containers do not behave in this way: their contents are assumed to be less immediately visible, and will be mentioned only if the player looks inside them.) Example 14 (*): Replanting Changing the response when the player tries to take something that is scenery. Example 15 (*): Disenchantment Bay 2 Disenchantment Bay: creating some of the objects in the cabin's description. 3.9. Backdrops It is a cardinal rule that nothing can be in more than one place at the same time, but rules were made to be broken, and an exception is allowed for a special kind of thing called a "backdrop". For instance: "Streaming" The Upper Cave is above the Rock Pool. The stream is a backdrop. It is in the Upper Cave and the Rock Pool. Backdrops are ordinarily in the background: if the sky needed to be referred to in the course of play, it might be represented by a backdrop, for instance. Here we have a stream of water running through two rooms, though it might be any number. Backdrops are always fixed in place. Backdrops can be put in regions as well as rooms, and if so, then they are present at every room in the given region (or regions), as well as any specific rooms they may also be put into. For instance: The Outdoors Area is a region. The Moon is a backdrop. The Moon is in the Outdoors Area. The Moon is in the Skylight Room. The special place "everywhere" can be given as the location of a backdrop to make it omnipresent: The sky is a backdrop. The sky is everywhere. Inform assumes that backdrops are also scenery unless told otherwise, so this will not result in messages like "You can also see the sky here." being included in room descriptions. In the case of the stream above, we could artfully mention it in passing in the room descriptions of the Upper Cave and the Rock Pool. (-See Moving backdrops for ways to place backdrops in dynamically changing selections of rooms.) Example 16 (*): Disenchantment Bay 3 Disenchantment Bay: adding a view of the glacier. 3.10. Properties holding text The properties we have seen so far have all been either/or: either open or closed, either transparent or opaque, either fixed in place or portable, either openable or not openable. However, some properties can have a much wider range of possibilities. For instance, the "description" of a room is the text revealed when the player first enters it, or types "look". This needs to be textual: Inform would complain if, for instance, we tried to set the description of something to the number 42. We have already seen a concise way to set the description of a room: The Painted Room is north of the Undertomb. "This is the Painted Room, where strange wall drawings leap out of the dark at the gleam of your candle: men with long wings and great eyes, serene and morose." This does the same thing as: The Painted Room is north of the Undertomb. The description of the Painted Room is "This is the Painted Room, where strange wall drawings leap out of the dark at the gleam of your candle: men with long wings and great eyes, serene and morose." Or even: The Painted Room is north of the Undertomb. The description is "This is the Painted Room, where strange wall drawings leap out of the dark at the gleam of your candle: men with long wings and great eyes, serene and morose." 3.11. Three descriptions of things The player's first sight of something is the text used as its "initial appearance": The plain ring is here. "Cast aside, as if worthless, is a plain brass ring." This text appears as a separate paragraph in the text describing the Painted Room. It will continue to be used until the first time player picks the ring up (if this ever happens), so it normally describes things in their original, undisturbed context. (Inform uses an either/or property called "handled" for this: something is "handled" if it has at some point been held by the player.) Thus when a piece of text stands alone as a sentence in its own right, then this is either the "description" of the most recently discussed room, or the "initial appearance" of the most recently discussed thing. Either way, it is used verbatim as a paragraph in the text shown to the player visiting the room in question. But a thing also has an ordinary "description", which is used to give a close-up look at it. This text is ordinarily only revealed to the player when a command like "examine ring" is keyed in: The description of the plain ring is "No better than the loops of metal the old women use for fastening curtains." Example 17 (*): Disenchantment Bay 4 Disenchantment Bay: fleshing out the descriptions of things on the boat. Example 18 (**): Laura Some general advice about creating objects with unusual or awkward names, and a discussion of the use of printed names. 3.12. Doors The map of an interactive fiction is the layout of rooms and the entrances and exits which connect them. So far, these map connections have always run from one room to another, like so: The Painted Room is north of the Undertomb. However, we can also interpose doors between rooms, like so: The heavy iron grating is east of the Orchard and west of the Undertomb. The grating is a door. The second sentence is needed since otherwise Inform will take "heavy iron grating" to be the name of a third room, whereas what we want is for the grating to be something physically present in both the Orchard and in the Undertomb, and acting as a conduit between them. To this end it needs to be a "door", a kind we have not so far seen. In the absence of any other instruction, a newly created door will be fixed in place, closed and openable. The grating really does come in between the two rooms: the grating is what lies immediately east of the Orchard, not the Undertomb room. So if we wrote the following: The Undertomb is east of the Orchard. The heavy iron grating is east of the Orchard and west of the Undertomb. The grating is a door. then Inform would say that this is a contradiction: we said the Undertomb was east of the Orchard, but then we said that the grating was east of the Orchard. Inform's "door" kind can be used for all manner of conduits, so the word door need not be taken literally. In Ursula K. LeGuin's beguiling novel "The Tombs of Atuan", from which the above rooms are stolen, it is not a grating which interposes, but: The red rock stair is east of the Orchard and above the Undertomb. The stair is an open door. The stair is not openable. In real life, most doors are two-sided, and can be used from either of the rooms which they join, but this is not always convenient for interactive fiction. Here is a one-sided door: The blue door is a door. It is south of Notting Hill. Through it is the Flat Landing. (Note the use of "it" here as an optional abbreviation.) This will make a door visible only on the Notting Hill side; no map connection will be made in the reverse direction, unless we ask for one. Should we ever need it, the values "front side of ..." and "back side of ..." reveal where a door is placed. (For instance, "front side of the heavy iron grating" is the Orchard.) Example 19 (*): Disenchantment Bay 5 Disenchantment Bay: adding the door and the deck to our charter boat. Example 20 (**): Escape Window that can be climbed through or looked through. Example 21 (***): Garibaldi 1 Providing a security readout device by which the player can check on the status of all doors in the game. 3.13. Locks and keys It seems unwise for a door in Notting Hill to be unlocked, so: The blue door is lockable and locked. The matching key of the blue door is the brass Yale key. Since the second sentence here is a little clumsy, we can equivalently say The brass Yale key unlocks the blue door. Yet a third way to say this is: The blue door has matching key the brass Yale key. This introduces three new properties: a door can be locked or unlocked; lockable or not lockable; and it can have a matching key, which must be another thing. The same thing can be the matching key of many different locks: and note that a door can be locked and even lockable without having a matching key at all, in which case the player trying to open it will be permanently out of luck. Doors are ordinarily unlocked, not lockable, and without a matching key. Containers can also have locks, in exactly the same way, and are allowed to have the same properties. On the other hand supporters never have locks: it makes no sense to be able to lock a tabletop, for instance, and Inform will not allow any discussion of the matching key of a supporter, or of a supporter being locked or unlocked. Example 22 (*): Disenchantment Bay 6 Disenchantment Bay: locking up the charter boat's fishing rods. Example 23 (**): Neighborhood Watch A locked door that can be locked or unlocked without a key from one side, but not from the other. 3.14. Devices and descriptions A "device" is another of the standard kinds of thing, and should be used for anything which can be switched on or off: a light switch, say, or a slide projector. Devices are generally machines, clockwork or electrical. A device is always either "switched on" or "switched off", but is switched off unless we specify otherwise. That makes three kinds of thing which will likely change their appearance according to which of their two possible states they are in: doors and containers, which can be open or closed; and devices, which can be switched on or switched off. We would like to produce text accordingly, and we can do this using Inform's ability to make (almost) any piece of text change with circumstances. For instance: The coffin is an openable container in the Undertomb. "[if open]The lid of a plank coffin yawns open.[otherwise]A plank coffin lies upon the dirt floor of the Tomb." We could use a similar trick to make the appearance of a device change "if switched on". There will be much more about text substitutions, as instructions in square brackets like these are called, in later chapters. (See Text with substitutions for more on varying what is printed.) Example 24 (*): Disenchantment Bay 7 Disenchantment Bay: making the radar and instruments switch on and off. Example 25 (**): Down Below A light switch which makes the room it is in dark or light. 3.15. Light and darkness Rooms can be "dark" or "lighted", though they are lighted by default, and are lighted in all the examples we have seen so far. The Sinister Cave is a dark room. "A profoundly disquieting rock formation, apparently sculptured by some demonic hand, this is not a cave in which to relax." When the player is in a dark room, he can still go in various directions, but he cannot see the room description or interact with any of the objects in the room, except those he is holding. This means that, unless we should change the Cave in some way during play, the text above ("A profoundly...") will only be read if the player succeeds in bringing light into the Cave, perhaps by bringing along the following: The flaming torch is in the Sandy Passage. "Stuck loosely into the sand is a flaming torch." The flaming torch is lit. A thing with the property of being "lit" will enable the player to see inside dark rooms, and to carry out other activities requiring light, such as examining items. A lit thing in an open container will still light up a room; a lit thing in a closed container will not, unless the container has been given the "transparent" property. It is possible to adjust the way darkness behaves, and we will see more on this topic in the chapter on Activities. (See Printing a refusal to act in the dark for the first of several ways to control what is printed in the dark.) 3.16. Vehicles and pushable things Next in the tour of standard kinds is the "vehicle". This behaves like (indeed, is) an enterable container, except that it will not be portable unless this is specified. In the Garage is a vehicle called the red sports car. The player can enter the sports car and then move around riding inside it, by typing directions exactly as if on foot: and the game will print names of rooms with "(in the red sports car)" appended, lest this be forgotten. We have already seen that some things are portable, others fixed in place. In fact we can also make a third sort of thing: those which, although not portable, can be pushed from one room to another with commands like "push the wheelbarrow north". At a pinch, we might just be willing to allow: The red sports car is pushable between rooms. But of course this is a property which almost any thing can have, not just a vehicle. (Only "almost" because Inform will not allow a door to be pushable between rooms, in the interests of realism rather than surrealism.) If we need vehicles which the passenger sits on top of, like a horse or a tractor, the standard "vehicle" kind will not be ideal. However, by loading one of the extensions which comes ready-installed: Include Rideable Vehicles by Graham Nelson. ...we are provided with two more kinds, "rideable vehicle" and "rideable animal", just right for the tractor and the horse respectively. (As with all extensions, the documentation can be seen by clicking Go on some source which contains the above line, and then turning to the Contents index.) (See Going by, going through, going with for further ways to customize vehicle behaviour.) Example 26 (*): Peugeot A journey from one room to another that requires the player to be on a vehicle. Example 27 (**): Disenchantment Bay 8 Disenchantment Bay: a pushable chest of ice for the boat. Example 28 (***): Hover Letting the player see a modified room description when he's viewing the place from inside a vehicle. 3.17. Men, women and animals Rounding out the standard kinds provided by Inform are four for living things: "person", which is a kind of thing, and "man", "woman" and "animal", all kinds of person. For instance: In the Ballroom is a man called Mr Darcy. For the time being, men and women will be little more than waxworks: they will come to life only when we go beyond the present stage of creating an initial state of the world. People can be male, female, or neuter: this is an attribute for the "person" kind, and it affects play at run-time a little, because the player can use "him" and "her" to refer to male or female people encountered, or "it" for neuter animals. Men and women are always male and female respectively, but the gender of an animal can be any of the three: male or female if we want (say) a stallion or a nanny goat;