The Foxaroo tinkering around with Inform7

Authoring Inform 7
21

You can drop the “otherwise: stop the action” lines. They don’t do anything.

“[Paragraph break]” does the same thing as “[Line break][Line break]”. (In this case, anyhow – there may be subtle differences in other cases.)

The code becomes very slightly simpler (albeit weird-looking) if you shift the period around:

A room called Top of Small Pit is west of Splendid Chamber.  "At your feet is a small pit breathing traces of white mist. An east passage ends here except for a small crack leading on[spiel for rough stone steps]."

To say spiel for rough stone steps:
	if the player does not carry the large gold nugget:
		say ".[Paragraph break]Rough stone steps lead [if the player is in Top of Small Pit]down the pit[otherwise]up the dome[end if]"

Hall of Mists is a room. "You are at one end of a vast hall stretching forward out of sight to the west. There are openings to either side. Nearby, a wide stone staircase leads downward. The hall is filled with wisps of white mist swaying to and fro almost as if alive. A cold wind blows up the staircase. There is a passage at the top of a dome behind you[spiel for rough stone steps]."

This way you don’t have to stuff in a spurious space.

22

[EDIT: Hadn’t seen your post above yet Zarf]

For my colossal cave adventure remake I created an electric light simply named “Lamp” (I was going to change its name later to “brass lamp” and expand the descriptions). Worked fine but I grew tired of typing “Turn lamp on” and put in some code so I could just say “Light lamp.” That’s when I found out that the two states work independently. Initially I used “now the lamp is switched on” / “off” and found that this did not in fact change whether or not the lamp was producing light. So I changed to “now the lamp is lit” / “unlit”. This worked to control the lighting, but alter the lamp’s on/off state. Eg: The lamp could be giving off light but when told “Turn lamp off” the player may be told “The lamp is already off.”

The final code I implemented works OK, but it’s odd that I need to alter both states. Is there a better approach?

[code]Understand the command “light” as something new. Understand “Light [something]” as lighting. Lighting is an action applying to one carried thing.
Does the player mean lighting the lamp: it is very likely.
Instead of lighting the lamp:
now the lamp is lit;
now the lamp is switched on;
say “Your lamp is now on.[Line break]”.

Extinguishing is an action applying to one carried thing.
Understand “extinguish [something]” as Extinguishing.
Does the player mean extinguishing the lamp: it is very likely.
Instead of extinguishing the lamp:
now the lamp is unlit;
now the lamp is switched off;
say “Your lamp is now off.[Line break]”.[/code]

23

Thanks Zarf!

Didn’t know about [Paragraph break]. I’ll have to commit that one to memory. I’ve re-read chapter 5.8 now and hopefully I’ll be better familiar with those special codes. Trouble with these things is that you have to actually USE them at least once before you mentally acknowledge that they exist.

I moved the full stop to the end of the spiel because it was appearing as a double full stop on the previous line. Other than that it works and is much simpler than mine, thanks.

(I think I had some other approach in mind when I originally wrote the “stop the action” line and I’ve completely forgotten what it was for now.)

24

I’m still hopeful that someone can let me know if the below code is the most efficient way of turning an electric light kind on & off in Inform (see my earlier post about the difficulties I had with the differences between lit/unlit & on/off)

[code]Understand the command “light” as something new. Understand “Light [something]” as lighting. Lighting is an action applying to one carried thing.
Does the player mean lighting the lamp: it is very likely.
Instead of lighting the lamp:
now the lamp is lit;
now the lamp is switched on;
say “Your lamp is now on.[Line break]”.

Extinguishing is an action applying to one carried thing.
Understand “extinguish [something]” as Extinguishing.
Does the player mean extinguishing the lamp: it is very likely.
Instead of extinguishing the lamp:
now the lamp is unlit;
now the lamp is switched off;
say “Your lamp is now off.[Line break]”.[/code]
Now my latest problem, and I’ve been struggling with this on & off over the course of a couple of months.

The crystaline bridge in Colossal Cave linked the two sides of the fissure to the west of the Hall of Mists (2 adjacent rooms), but only after the player waved the black rod, and the bridge could be made to dissapear again the same way. Therefore I need a manipulable bridge. The bridge is visible in both locations and its very presence permits egress. The obvious conclusion: the bridge is an Inform door.

The crystaline bridge is west of East Bank of Fissure and east of West Side of the Fissure. The bridge is an open door. The bridge is not openable. The description of the crystaline bridge is "A crystalline bridge now spans the fissure." (Code adapted from chapter 3.12 of the manual).

Now I was expecting it to be very easy to manipulate the bridge in and out of gameplay, but all my attempts have failed. (Leaving me with serious doubts as to whether I’m smart enough to be playing with Inform in the first place).

Inform immediately rejected me removing and replacing the bridge from play, saying that this is not allowed on doors.

Re-mapping the bridge’s connections involving two limbo rooms didn’t work either. It had to be worded carefully to prevent the player ending up trapped in one of the limbos, and even when the connections worked I still couldn’t get the bridge into view.

My final idea was to use concealment. I suspect that concealment was probably used on the final puzzle of Zork II; the door that was invisible until the player switched off their lamp and then became permanently visible in light or dark. However I haven’t been able to determine the syntax for concealing objects that are not poessions of a particular actor.

Googling around I found that there’s an extension by Krister Fundin that permits hidden doors. Is this extension necessary, or is there a simpler way?

I hope I’m making sense. I’m on the verge of coming down with another cold, my third in only two months.

25

Is the bridge a room? You can manipulate exits easily enough, but if the bridge is a door, there’s no simple way to move it around. The hidden items extension is the simplest way. It does all the nasty hackery for you.

26

Concealment (the I7 “undescribed” property") is a valid way of handling this. An undescribed door is not passable, exactly for cases like this. The extensions probably make use of this.

Another approach is to not make the bridge a door. Instead, make a normal map connection, and two “bridge” objects. Move the bridge objects into the two rooms at the appropriate time. Then:

Check entering the west-side bridge:
	instead try going east.
Check going east from the West Side when the west-side bridge is not in West Side:
	instead say "The chasm is impassable."

Inform’s parser and world model are not derived from Infocom’s. Infocom doors wouldn’t have had the same restrictions (or abilities!) that Inform doors have.

27

Inform7 indeed tracks the “lit” and “switched on” states separately, and AFAIK there’s no way to automatically synchronize those states with something like “the lamp is lit if it is switched on.” However, what you can do is make the “switching on” and “switching off” actions also update the “lit” state, and then handle commands like “light lamp” with “Instead of lighting the lamp, try switching on the lamp.” like this:

The Maze of Twisty Little Passages is a dark room. "You are in a maze of twisty little passages, all alike."

The lamp is a device. It is switched on. It is lit. The player carries the lamp.

Carry out switching on the lamp: now the lamp is lit.
Carry out switching off the lamp: now the lamp is unlit.

Lighting is an action applying to one thing.
Understand "light [something preferably held]" as lighting.
Check lighting: instead say "You're not sure how to light [the noun]."

Extinguishing is an action applying to one thing.
Understand "extinguish [something preferably held]" as extinguishing.
Check extinguishing: instead say "You're not sure how to extinguish [the noun]."

Instead of lighting the lamp, try switching on the lamp.
Instead of extinguishing the lamp, try switching off the lamp.

Note that, since the updating of the “lit” state is handled using “carry out” rules, the normal action processing rules for switching the lamp on and off (which just update the “switched on” state and report it) still run. For our new verbs, however, the “instead” rules cause the normal processing (defined by the “check” rules above) to be skipped for the lamp.

In fact, in this specific case, it would’ve been even easier to just tell Inform to understand “light” and “extinguish” as synonyms for switching on and switching off respectively. In a more complex story, however, this might produce unexpected responses: on one hand, we might want to include light sources that are not devices; on the other hand, a command like “light blender” should probably not succeed.

Also note that there might be situations where it might be meaningful for the “lit” state not to always track the “switched on” state: for example, if the lamp was out of batteries, switching it on should not make it light up. The Inform model is flexible enough to allow this, but tracking the state transitions (and supplying appropriate messages to the player in each case) becomes somewhat more complicated. (Of course, an alternative approach would be to just make the lamp turn off when the batteries run out, and disallow turning it back on until they’ve been replaced.)

28

Thanks Vyznev, that covers it nicely and I can shorten a lot of code now.

Thanks for directing attention to that. I’d forgotten to add code to produce an error message when the player attempts to light something other than the lamp. Done!

Creating “light” and “extinguish” as synonyms for switching on and switching off sounds even more convenient. I haven’t created synonyms for verbs yet (just nouns). I tried a few times, but couldn’t get it right. What’s the correct syntax?

Also, if I want to include the command “Blow lamp out” (even though the lamp is electric) how would I implement this? Inform hasn’t been too happy about me using the word “Out” due to its reservation as a direction.

Yes the extension worked superbly. I didn’t even have to write in any tricky code; it worked exactly as it appeared in the instructions. Kudos to Krister Fundin; I think this is a feature that should be standard.

To answer the question; no the bridge itself doesn’t serve as a room. However your idea would have been my 2nd choice if the hidden doors extension hadn’t worked. A similar approach was used in my (on hiatus) Dr Who I7 project where I needed to re-direct the TARDIS’ exit to variable locations, and that worked especially well.

Wouldn’t ZIL have had it’s own version of concealment though? Or did they simply move objects in and out of play? I’d need to jog my memory a bit, but I can recall there was a button hidden in the library in the murder mystery “Deadline” which only appeared to the player if they watched the murder victim’s son opening the secret passage. Same for the holes that gardner McNabb finds in his garden; they don’t appear until he shows them to you.

29

You could just tell Inform to understand those commands as denoting the switching on/off actions, like this:

Understand the command "light" as something new. [Remove old synonym "light" -> "burn".]
Understand "light [something]" as switching on.
Understand "extinguish [something]" as switching off.

(By the way, I realized that I forgot to include the “Understand the command “light” as something new.” line in my earlier example, which meant that Inform was still treating “light” and “burn” as synonyms. The reason it still worked is that I’d specified “light [something preferably held]” as the command for lighting, and the “[something preferably held]”, being more specific, took precedence over the “burn [something]” command for the built-in “burning” action. However, as a side effect, “burn lamp” would also be understood as lighting the lamp. If you use my example code from above, you’ll probably want to add that line before the definition of the lighting action.)

I’m not sure why you’re having problems with it. The following works just fine for me.

Blowing out is an action applying to one thing.
Understand "blow [something] out" and "blow out [something]" as blowing out.
Check blowing out: instead say "You huff and puff as hard as you can at [the noun], but nothing happens."

[Blowing out the lamp is something the player might actually try. Let's provide a better message for that.]
Instead of blowing out the lit lamp: say "You huff and puff as hard as you can at the electric lamp, but nothing happens. Maybe you should just try switching it off?"

Alternatively, instead of creating an actual “blowing out” action, you could just designate those commands as mistakes:

Understand "blow [something] out" and "blow out [something]" as a mistake ("You huff and puff as hard as you can at [the noun], but nothing happens.")

Understand "blow [lamp] out" and "blow out [lamp]" as a mistake ("You huff and puff as hard as you can at the electric lamp, but nothing happens. Maybe you should just try switching it off?").

A subtle difference between these two solutions is that mistakes don’t take a turn, whereas actions do. If your game isn’t particularly time-sensitive, it probably doesn’t matter, but it’s worth keeping in mind. For instance, “every turn” rules don’t fire after mistakes, so if you have, say, other characters moving around every turn, then the difference might matter. In this case, since the message I chose to give for trying to blow something out involves the player actually doing something, it probably should consume a turn, and so a real action might be the better choice. But with a different message, a mistake might be preferable.

Also, mistakes always take precedence over actual actions, so defining “blow [something] out” as a mistake would prevent you from using it as a valid action if you did want to let the player blow something out. However, you could work around that by defining the mistake as, say, “blow [something nonblowable] out”, and then adding, say, “Definition: a thing is nonblowable if it is not a candle.” to your code. That said, just using a real action is IMO better here anyway.

30

I can’t really recommend making “light” and “extinguish” global synonyms to switching on/off unless you can come up with a default response that reasonably covers both verbs ( >LIGHT PANTS – “That’s not something you can switch”). It also assumes that the lamp is the only item in the game that can be switched on or lighted (or that the same coupling applies to every such item).

I think simply doing this works to create a special case for the lamp (can’t test it right now):

Understand "light [lamp]" as switching on. Understand "extinguish [lamp]" as switching off.

31

One or the other. I’d have to look at the decompiled source code to tell, and that’s a lot of work.

(Did Allen wind up making a decompile-metadata file for Zork 2? I don’t remember.)

My point is, I7’s data structures are not compatible with moving doors into and out of play. But this was possible with I6, and I have no reason to think that it was a problem in ZIL.

Back to the lamp: Since “light” and “burn” are normally the burning action, I’d go with that:

Check burning the lamp: now the lamp is lit.
Check switching on the lamp: instead try burning the lamp.

This covers the turning-on half without any grammar changes, and it’s no big deal that “burn lamp” is also accepted.

Juhana suggests “Understand “light [lamp]” as switching on” but I avoid these special-noun-cased grammar lines unless they’re absolutely necessary. They muck up disambiguation, because Inform can only consider a single grammar line when generating disambiguation prompts.

32

I agree, which is why I didn’t do it that way in my original example. In fact, my personal rule of thumb is that, in most cases, every valid verb really should have its own action, even if the actual effects of those actions are just delegated to a single “master” action via “instead” rules.

Of course, it’s OK to map multiple verbs to a single actions they really are synonymous in all contexts, but if you start merging a lot of almost synonymous verbs that way, it makes writing meaningful default responses for them a lot harder. The Inform standard library does do that a lot, and it often gets away with it by making the output really generic, but it also often produces silly results. The default synonymization of “light” and “burn” is a case in point: there are plenty of things, like electric lights, which can be meaningfully lit but not burned.

33

I try to look at whether the player is going to be paying attention to both uses of a verb. If a game has a lot of flammable objects and electrical machinery, I’d separate them. If there’s a lot of burning but the only electric light is in a closet and not really important to the game, I wouldn’t worry about it.

34

Thanks again Vyznev! With your help I’ve tightened my code further using the synonyms.

[/code]
[/quote]
Ah! The problem was that I didn’t include “out” in the creation of the command:

Blowing is an action applying to one carried thing. Understand "Blow [something] out" as Blowing.

I’m still grappling with I7’s syntax.

For this project I’ll be okay as Collossal Cave only had the one lightable object. For more complex projects I’ll need to be more careful, yes, so any such advice is most welcome.

No, I wouldn’t expect you to do that. :slight_smile:

If anybody on this forum has it would be nice to learn some of their tricks, though the more I learn on my own the better. My Collossal Cave project is an exercise in going back to the basics.

There will indeed be situations like that if I follow in the footsteps of the greats. Matches were used for lighting objects in Zork I & II. Zork I had the pair of candles. Zork II not only had the fuse for the explosive but also any paper object placed in the receptacle of the balloon basket to generate hot air. Lighting objects (other than the lamp) you were holding proved fatal (wouldn’t the adventurer simply have dropped them?) and apparently the pile of 69,105 leaves would consume the adventurer in the blaze. Seems that objects in Zork burned with a much greater intensity than real life, which would explain how the balloon was able to rise on the mere heat of burning paper. It would also explain why the candles would melt instantly if you tried to light them with the ivory torch. Oddly enough putting the burning torch in the display case didn’t set fire to the white house.

Thanks for your help guys. Onward into the cave I go (after I get over this latest cold virus I’ve contracted that is).

35

That’s weird. It shouldn’t matter what you call the command in the source code, as long as you use it consistently. In particular, any of the following should work:

Blowing out is an action applying to one thing.
Understand "blow [something] out" or "blow out [something]" as blowing out.
Instead of blowing out something: say "You huff and puff at [the noun], but nothing happens."
Blowing is an action applying to one thing.
Understand "blow [something] out" or "blow out [something]" as blowing.
Instead of blowing something: say "You huff and puff at [the noun], but nothing happens."
Foo blarghing quux is an action applying to one thing.
Understand "blow [something] out" or "blow out [something]" as foo blarghing quux.
Instead of foo blarghing quux something: say "You huff and puff at [the noun], but nothing happens."

or even (note the changed word order on the last line):

Blowing it out is an action applying to one thing.
Understand "blow [something] out" or "blow out [something]" as blowing it out.
Instead of blowing something out: say "You huff and puff at [the noun], but nothing happens."

The last syntax is commonly used for two-noun verbs like “putting it in” or “tying it to”, where the first noun goes before the preposition and the second noun after it.

[rant=Note on action names without “-ing”]Ps. While testing the second-to-last example above, I found that the Inform compiler somewhat arbitrarily insists on action descriptions in rules containing a word ending with “-ing”. I say “arbitrarily” because, apparently, any word ending in “-ing” between the “Instead of” and “:” is enough; even “something” or even “the ring” will do. So the following will not compile:

Foo blargh quux is an action applying to one thing.
Understand "blow [something] out" or "blow out [something]" as foo blargh quux.
Instead of foo blargh quux: say "You huff and puff at [the noun], but nothing happens."
Instead of foo blargh quux the lit candle: now the candle is unlit; say "You blow out the candle."

but instead gives the following error messages:

yet the following code does compile and run just fine!

Foo blargh quux is an action applying to one thing. Understand "blow [something] out" or "blow out [something]" as foo blargh quux. Instead of foo blargh quux something: say "You huff and puff at [the noun], but nothing happens." Instead of foo blargh quux the lit candle when doing something: now the candle is unlit; say "You blow out the candle." [/rant]

36

Golly, I forgot all about this forum. :astonished:

Guys, sadly I won’t be doing any Inform tinkering in the foreseeable future. I lost my job in March. :frowning: ALL my hobbies are on hold until I’m gainfully employed again.

37

Hi guys,

A quick update: It took me 6 months to successfully achieve new employment, and currently I’m still in the probationery stage of the job with my review coming up in February March (why on Earth did I write February?). The role is very demanding and to get through the learning curve I’ve had to study their procedures at home.

It’s only rarely that I’m able to indulge in IF projects now. I did a little over the Australia Day long weekend though.

Q: Is there a way to determine the exact number of passageways leaving a room, as opposed to “the number of rooms adjacent”? I wrote a short routine for my Colossal Cave remake to ensure that the player can always use “exit” to return from a dead-end to their prior location. For the mostpart it worked, however there’s a unique room in the pirate’s treasure maze which has 2 passageways and both lead back to the previous room. IE 2 passageways but only 1 adjacent room.

38

You might need to do this in a somewhat roundabout method.

let the passage count be zero;
repeat with the way running through directions:
    if the room way of the location is not nothing:
        increment the passage count.
39

That’s excellent! Thanks Draconis. I’ll give that a try when I get back home.

40

It worked a charm - thanks! :smiley: