I7: goal, low budget props that work as expected

I attempted to solve a problem using ‘Understand … as a mistake’, however I7 seems to regard some of the input as erm, ‘global’ and other input it seems to regard as ‘local’ to the prop (a sink). I guess I expected ‘Understand … as a mistake’ to restrict itself to the room the sink is in. I tried to add conditions to ‘Understand … as a mistake’, but the IDE gave errors. I may have backed myself into a corner here.

If you can understand what I was trying to do, I’d appreciate a few words of explanation of why my idea didn’t work, and being shown a better method. Thanks in advance.

[code]“low budget props that work as expected” by Jeff

[I want props (e.g. a sink) to work as a player expects, but I don’t want to get involved in a ton of code to do so. My problem is, how to make something like a sink work (anticipating many ways a player might try it) with as little code as possible (i.e. as few new rules as possible).

I thought perhaps the ‘Understand … as a mistake’ structure would be ideal for this. Problem is, some phrases seem to work everywhere, even when no sink is present, while others work as expected. Do ‘test me’ from both rooms and note the difference.
]

test me with “x sink/use sink/get water/drink water/wash hands/drink/wash”;

section - low budget props that work as expected

A sink is a kind of container. It is usually fixed in place. A description of sink is “A chipped and stained basin with no pipes to take away the water. [line break]The water simply drains onto the floor and runs into a grille at your feet.”

[some code that anticipates many things a player might try to do…] [… but it doesn’t work as expected…]
Understand “drink” or “wash” or “use [sink]” or “wash hands” or “drink water” or “get water” as a mistake (“The water is clean and cool, [line break]but the pressure is so high it splashes on your pants.”).

section - center stage

Workshop is a room. In it is an engine. It is fixed in place. A description of Workshop is “To the south is a washroom.”

Instead of examining engine: say “A lawn mower engine. The whatsit has come loose from the whoosit. [line break]Oops, now your hands are dirty. Better go wash them.”

South of Workshop is Washroom. In it is a sink. A description of Washroom is “To the north is a workshop.” [/code]In case it wasn’t obvious, ‘low budget’ here means with as little overhead (work, memory) as possible. Thanks in advance.

Oh, and to reiterate: Do ‘test me’ from both rooms and note the difference.

I hear ya. I think your dream of low overhead detail-filling is the dream of man and flightless bird alike.

You also already identified what’s going wrong. The ‘mistake’ mechanism is global, and I don’t think it can be made otherwise.

For instance if you try to add a condition to a mistake line:

Understand "drink" or "wash" or "use [sink]" or "wash hands" or "drink water" or "get water" as a mistake when player is in location of sink

it doesn’t compile.

So yeah, I think you need to make some actions. I made a demo where I created just two actions which round up all the things you wanted, as an example. I made two because one is the vague version (where the player doesn’t mention the sink) and the other is the sinky version (where they do). These two actions still shove away most irrelevant attempts, because one is only active when the sink is in the room, and the other demands that the noun be the sink.

This looks neat in the short term, but as soon as your game starts getting any legs, you may find it’s actually easier to just attend to the prop via more traditional (IE less herdy) means.

To try my demo, cut out your middle section and replace it with the below one. Then do your double 'test me ’ schtick again.

Btw I notice you have just 1 post to your credit, so you may need to learn the trick of cutting+pasting inform code. If you copy it direct from this post, the formatting will go screwy. What you do is just click ‘quote’ on my post, then copy the code from the editable window that appears. That will preserve the formatting.

[code]section - low budget props that work as expected

A sink is a kind of container. It is usually fixed in place. A description of sink is “A chipped and stained basin with no pipes to take away the water. [line break]The water simply drains onto the floor and runs into a grille at your feet.”

[some code that anticipates many things a player might try to do…] [… but it doesn’t work as expected…]
vague waterfooling is an action applying to nothing.

Understand “drink” or “wash” or “wash hands” or “drink water” or “get water” as vague waterfooling when sink is in location.

sinky waterfooling is an action applying to one thing.

Understand “use [sink]”, “drink [sink]” or “wash hands [sink]” or “drink water [sink]” or “get water [sink]” as sinky waterfooling.

Carry out vague waterfooling: say the splashy message.

Carry out sinky waterfooling: say the splashy message.

To say the splashy message:
say “The water is clean and cool, but the pressure is so high it splashes on your pants.”[/code]

PS - When you say memory, do you mean as in KB useage of your game?

There are other folks here who’d know infinitely more about which techniques use more/less memory than others, but it’s worth checking you’re not trying to cut memory use for no reason. I guess a possible reason is you’re trying to fit a game onto a handheld device. Or you’re trying to fit the game into the Z-machine format as an exercise of self restrcition. But per se, there is no reason at all to watch your memory useage. The glulx format can handle games bigger than any that have been made to date.

You can add any valid condition to mistake grammar. However, “in location of [something]” is not valid. Try

Understand "drink" or "wash" or "use [sink]" or "wash hands" or "drink water" or "get water" as a mistake ("The water is clean and cool, [line break]but the pressure is so high it splashes on your pants.") when the player can touch the sink.

–Erik

Ah, excellent. My understanding of I7 is growing slowly but surely. I have these dead-ends in my wetware sometimes where I notice (in retrospect) that I’m unable to take a pattern from one context and apply it to another. This was one such occasion. Thank you.

Noted. Thanks for the feedback.

Thanks, ektemple. You’ve also expanded my horizons.

I am thus enriched, cautioned, challenged. Thank you both.

I generally say it is bad practice to use conditional verb grammar like this. If you want “wash” to give the player a guidance message, it should give that message anywhere in the game. To get a physical-action reply ("…the water splashes on your pants") in one location but “I don’t recognize that verb” in another location is particularly bad; at best the latter will train your players to never run into the former message.

Defining “get water” as a mistake is another, well, mistake. It fails to cover “get the water” or “get clean cool water” or any other synonyms you or the player might think of.

The best way to catch player actions is to define actions.

Ah, thanks for making that point, zarf. In this case, I simply brainstormed a few verbs I thought a player might use for the purpose of asking the question. But I could easily forget that later when I implement it in a story. Player guidance simply hadn’t even entered my mind yet. Thank you for your feedback on this point.

Oh geez, I knew that was sloppy when I typed it, but I didn’t fix it. But the main thing I learned was you have to add your condition for the mistake after the bracketed section and not before.

you can put [text] between get and water.
you can also change the default mistake message in Language.i6t… :smiling_imp: