I7: Having trouble with rule for multiple actions

I’m trying to write an “instead” rule which applies to all actions other than a few specified actions. The specified actions (i.e., those to which the instead rule does not apply) include some actions that take no objects, some that take one object and some that take two objects.

I first tried “Instead of doing something other than looking, examining the gadget or putting the gizmo on the table . . .” This did not compile; the error message indicated that it can only handle mutiple actions in this context where they involve the same set of nouns. It also suggested using a definition.

For my next try, I defined a term to include each of the specified actions (Looking is QQQQing. Examining the gadget is QQQQing. Putting the gizmo on the table is QQQQing) and then wrote the instead rule as “Instead of doing something other than QQQQing . . .” It still didn’t compile.

Interestingly, “Instead of QQQQing” does work (well, it compiles – I didn’t test to see if it actually behaves as expected). Unfortunately, that doesn’t help me, since in order to use that formulation I would have to define hundreds of actions as QQQQing, instead of the few that I want as exceptions to the rule.

Any suggestions?

Thanks.

  Robert Rothman

I have A way. As with most of my suggestions, someone will probably come up with a more typically Inform-y one in a post right after me :slight_smile: but this way seems to work well.

Basically you have a flag. Before performing one of the 3 allowed actions, we turn the flag on. Then an instead rule checks All actions in the world, and activates if the flag is off. After performing our allowed action, we turn the flag off again.

You only have to add two lines of code for each allowed action, hence this is a good method to use when you want only 1% of actions to be allowed.

Compile this code in Inform then type ‘test me’ at the prompt:

[code]“Legend of Test Room: The Jericho Files” by Wade Clarke.

There is a room called The Test Room. “Try actions here. Only looking, examining the gizmo and putting the gizmo on the table will be allowed. All others will produce ‘NO WAY!’”

The allowed flag is a number which varies.
The allowed flag is 0.

There is a supporter called a table in the test room.

When play begins: say “(You’re carrying the gizmo. I thought I’d tell you this now because I’m not going to let you take inventory. HA!)”

The player carries the gizmo. The description of gizmo is “This looks freaking interesting!”

Instead of doing something when the allowed flag is 0, say “NO WAY!”

Before looking:
now the allowed flag is 1.
After looking:
now the allowed flag is 0.
Before examining the gizmo:
now the allowed flag is 1.
After examining the gizmo:
now the allowed flag is 0.
Before putting the gizmo on the table:
now the allowed flag is 1.
Carry out putting the gizmo on the table:
say “The gizmo is now on the table. You don’t have to take my word on this. Try doing a ‘look’. You might as well, I’m only gonna let you perform 3 actions in this game.”
After putting the gizmo on the table:
now the allowed flag is 0.

test me with “look / jump / examine gizmo / sing / put gizmo on table / look / get gizmo / inventory”[/code]

  • Wade

Okay, that wasn’t only educational, it was also VERY funny! I am not the OP… but I thank you for the useful technique. And the laugh. :smiley:

This is maybe a bit more concise:

[code]
Looking is QQQQing.
Examining the gadget is QQQQing.
Putting the gizmo on the table is QQQQing.

Instead of doing something when not QQQQing:
say “No time for that, you have to QQQQ!”[/code]

But in the context of a single room… with specific item(s) that the rules will apply to, and others it will not apply to… or in multiple rooms with multiple items that might not have the same rules applied depending on the item, and the room (and region, etc), Wade’s is more logical, and more readable, even if more verbose.

A few more “if’s” would be needed. But one of the things I have learned recently is that it is better to write more lines of readable, and reusable code, that is specific to the room/items being mentioned, than to create a rule that can bite you on the ass later when Inform decides to use it where you did not intend it to be used. QQQQing could work the same way. QQing, QQQing someplace else, and QQQQing in another place… and so on. But it is harder to read and follow the logic over multiple rooms, scenes, and regions.

I think this is where it comes down to personal ways of programming and visualizing the flow of the program. Plus, each instance could/would have a variety of situational responses if each was coded with a separate list of flags. And, just to spice things up… 0 and 1 do not need to be the only flag options. :wink:

Just a thought…

Thanks to all. I think that in the particular context in which I’ll be using it, Juhana’s approach may work for me. All of the rules in question will be limited to a particular scene, which is otherwise set up so that it all takes place within a single room. I’ll give it a try tonight.

The context here is that I’m trying to create what is effectively a cinematic interlude, while still giving the player the illusion that he is not just a passive observer. The player, a spy, is being briefed on his new mission (the execution of which will form most of the game). Once the briefing starts, the only thing that I will actually let him do is wait (so that he is basically forced to sit through several turns while an NPC goes through the “installments” that together give the player the information he needs). There will be a few specific disallowed actions which will trigger “you can’t do that” messages tailored to the particular attempted action. Any attempted action other than (i) waiting, (ii) listening (which will be redirected to waiting) or (iii) one of the specific disallowed actions, will trigger a generic “you can’t do that” message. The rule for the latter case is what we’re talking about here. (To add a little more variety, a separate variable will keep track of the NPC’s mood; he will get more annoyed each time the player attempts a disallowed action instead of paying attention to the briefing. All of the “you can’t do that” messages will vary depending on the NPC’s mood.) It all adds up to a fair amount of coding for what is basically a simple situation, but I’m hoping the effect works.

Thanks again.

Robert Rothman

To diverge slightly to the topic of programming methods – the reason I often program Inform via numerical flags is because I’m very used to them from BASIC and assembly language, the places I developed all my programming chops. Sometimes these flags can be unnecessary but equally efficient as the English language equivalents, sometimes more efficient and less verbose, sometimes less efficient and more verbose (like in the example in this topic - see, I knew someone would do it one post after mine :slight_smile:).

I would say an area in which I’ve noticed the ‘flag attitude’ is a good way of programming is when you want some tight control over timing in Inform. With things like actions and rules, the precise moments at which they start and end can feel a bit loose. You have to do playtests to see when things begin and end, both ‘to the eye’ and within the code. Then there are actions which tick over on the turn, and others which may be fired during the turn. Getting things to line up, descriptions to change at exactly the right moment, etc., I’ve found can be fiddly just using ‘every turn’, ‘when’ and ‘while’.

The good thing about explicitly telling Inform to change a flag or equivalent, or to consider the value of one and react, is that you always know where in the sequence of things it will occur. You can get the change to happen at any particular point during a turn. I’m working on a game which is very time/move sensitive, so this is important to me at the moment. Anyway, this is the main observation I’ve made so far in the course of bringing my 8 and 16 bit programming experience to Inform 7.

PS Glad you liked ‘Legend of Test Room’, Seeker!

Inform isn’t very nice with flags, in my opinion. There’s no flag equivalent that reads as nicely as a “to decide whether” phrase. Fortunately, you can use the “to decide whether” phrase in this case:

[code]Instead of doing something when the action is inappropriate for the briefing, say “NO WAY!”

To decide whether the action is inappropriate for the briefing:
if looking, no;
if examining the gizmo, no;
if putting the gizmo on the table, no;
yes.[/code]

Another trick that’s handy in this sort of situation is to use “continue the action” within an Instead rule. Then you don’t have to put every single condition in the preamble:

Instead of doing anything: if looking, continue the action; if examining the gizmo, continue the action; if putting the gizmo on the table, continue the action; say "NO WAY!"

Thanks to all. I wound up using Capmikee’s suggestion of a “to decide” phrase.

Robert Rothman