Best practise for action blocking ...

(Harald Schuster) #1


I have a lot of instead of rules and sometimes the wrong stuff fires when the action should actually be doing something else. I could of course, put all the relevant checks in one, big routine but that would mean I’d have to edit in an external editor since Inform doesn’t allow me to collapse if- repeat- etc. hierarchies (unless, of course, I missed that feature somehow).

So - apart from making stuff harder to edit - it’d always be checked since it would not be tied to any prechecked condition(s). Like: instead of looking at the lingerie clad lady when her husband is in the same room ^^

It’s a bit hard for me to come up with a fitting example but let’s assume the following:

The player cannot go from room A to room B without having shown an invitation to someone.
The player cannot go from room A to room B if he is carrying a weapon.
The player cannot go from room A to room B when he is being menaced by goons with guns
The player cannot go from room A to room B (or rather doesn’t want to) if the lingerie clad lady is in room A
The player cannot go from room A to room B unless he managed to get rid off the handcuffs the lingerie clad lady might have slapped on him

So - we have a lot of circumstances where the player cannot go from room A to room B. Time restrictions and Scenes might also get in the way.

Now - I haven’t found a good way to priorize actions other than using check, before, instead of and after. Most of my stuff has been done so far with before or instead.

What would be the best approach to this? The one big “instead of” rule that handles it all but will be a nightmare to manage or smaller rules. And if smaller ones - any recommendation on what to use when?

(matt w) #2

It looks to me like this is an ideal time to use Check rules:

Check going from the Boudoir to the Hall when the player carries a weapon: say "You can't take a weapon out to the hall." instead. Check going from the Boudoir to the Hall when Inge is in the Boudoir: say "You couldn't bear to leave Inge here like that." instead. Check going from the Boudoir to the Hall when the player wears the handcuffs: say "You'd better get rid of those handcuffs first." instead.

Assuming it has not already been interrupted by a Before or Instead rule, Inform will go through all the Check rules that apply until it is stopped by the word “instead”; if it is not stopped, it will proceed to the Carry Out stage. So they can all be in separate rules.

(Harald Schuster) #3

Thanks for the feedback - I think I gave up on Check rules because they trigger pretty late and produced a lot of those silly default messages. And I am not really a fan of those “you cannot do that” messages. I’ll do a copy and try to rewrite a couple of things to see if it works out. After all I have a bit more experience now than I had when I started out with that so it’s entirely possibly I dismissed something too early.

Edit: If I understand what you say correctly it means it’ll stop AT THE FIRST instead? So If I wanted a specific thing to be stopping it (in case we had multiple things that prevented the action) I’d have to decide what would be the most important one and put that (or those) inside of a “instead” and keep the lower priority ones in a check rule?

(Hanon Ondricek) #4

Check rules don’t fire “late” unless you’re writing your entire game using Before and Instead rules - which will work, but isn’t really a good practice. You seem like you’re running out of “phases” by only using Before and Instead - you’ve got the right idea, but there is the whole sequence you can use: Before - Instead - Check - Carry Out - After - Report.

Instead rules are intended as a special case - as a hard stop to prevent the parser from considering other rules as a blanket denial (Instead of examining the color wheel: say “But you are color blind.”) or to wholesale redirect an action (Instead of jumping when the player carries the pogo stick: try springy-sproinging.)

Check rules by design are where you’re supposed to code all the reasons a rule might be interrupted. For the love of all sanity, avoid writing one big complicated instead rule. You can divide them all separately. All check rules run unless one stops the action with an instead - oh this is true, so say this instead. It doesn’t really matter if another case is true because the player has already been disqualified from the action and it stops. However, you can sort messages at the beginning of the rulebook with “First check…” or “Last check…” Putting rules in the correct rulebook is designed to do the job of you needing to write one big long instead rule with conditions in the order you want them.

It took me a bit to get over the “but how will the parser know what order to do things?” hesitation. If you put your rules in the correct rulebook, things will usually happen in the order they’re supposed to.

First check going west in the ballroom: if the guard is in the ballroom: do nothing instead.
Check doesn’t have to produce messages unless you write them in. That’s a really nasty thing to do player-experience-wise, though, because nothing happens and the player is not informed why. That would likely be alerted as a bug in testing.

Check going west in the ballroom: if the guard is in the ballroom: say "The guard at the west archway glares menacingly. You'll need to distract him first before you can travel west from here." instead.
Note that you can “instead” out of a check rule.

There’s no “best practice” for code organization, but if the game or a major section of it involves a multi-part puzzle about clearing obstacles from a section of the map, I’d make a heading with all the check rules to keep them together.

Section 5 - Reasons the player can't leave the first floor

(Harald Schuster) #5

Ah, I see … something to think about. One of the problems when starting with things with almost no knowledge of the subject (Inform) and THEN running into problems much later - I have all issues solved for the moment but I wanted to know how to avoid that in the future, so thank you for your feedback

I guess I started with instead because it caused so much less problems when I didn’t know better about the other rules. The story I am trying to implement is a bit on the kinky side (UK style “a bit”) and the player spends most of the time NOT being able to do something in the regular fashion for various reasons. That’s a bit different to, say, a more regular story where things like handcuffs are one obstacle to overcome until things are back to normal. So the idea is immersion - not just checking ability. To just block the action would be a bit meh - you CAN take things when handcuffed. More easily when to the front than to the back. When to the back, the height of the object matters. And when to the back you might need a few tries to get a proper hold on it before it can be put into your inventory.

And when in a cage, the handcuffed or not is your smallest problem as the thing needs to be in reach for you. And not just Inform’s sense of “reach” but the content aware style of reach which can be something outside of the cage (in which case Inform would say you cannot take it without leaving the cage which is hardly an option) but if you imagine the carpet to be close enough to get a hold of it and pull it towards you (on top of which is a chair on top of which lies a key ring which happily includes the cage key). So pulling the (inform unreachable) carpet might get the chair close enough to you. And in situations like that when I used “instead of” I noticed that my checks were not being observed at times and so I kinda fell to only using “before” and “instead of” actions and “after” for cosmetic feedback. And now, as I have gained a somewhat deeper knowledge of Inform, I’m looking for “the proper” way to handle situations like that.

(Harald Schuster) #6

Well, the last post may have been a bit obscure so let me show you a more detailed example. Imagine a burglary scene in a house. The player has been the victim of a burglary and finds him or herself bound in a random set of rooms and the burglar is somewhere in the house.

The type of bondage the player is subjected to is random as may be the pose the player finds himself in.

Now if the player tries to move …

If the player is standing he might try to hop towards the desitnation. Depending on room and floor material and where the burglar is the movement might be heard. hopping is slower than walking so the player would need, say, 3 attempts towards a certain direction to actually “be there”. Oh, and when hopping one might fall and end up lying … with extra noise.

If the player is lying on the floor he might try crawling. Or he might try to change the position to kneeling or standing. Crawling is silent. But much slower than hopping.

Kneeling isn’t really good for movement so the player can’t do that but he could change pose to lying or standing.

Should the player be spreadeagled on the bed … tough luck.

Should the player be tied to a chair … well … you could try to move with that chair. Slowly. Noisily.

That’s the kind of situations I am talking about and I had serious problems when I started out - not knowing, of course, half as much about rule checks as I do now, and I found that a big instead of rule caused me the least problems. But I am quite aware that that is turning about to become “hard to manage” code. :slight_smile:

(Andrew Plotkin) #7

Inform’s reaching activity is flexible enough to handle this sort of thing. You don’t have to use it, but it’s an available option.

(Harald Schuster) #8

Well, that is most probably true but my one attempt at this failed miserably. I used:

after deciding the scope of the player:
   if the player is enclosed by the cage, place the key in scope.

And when I enter the cage and close the door I get a weird message “You can’t see any such thing.” And I can -all of a sudden - take EVERYTHING.

Laboratory is a room.

the gloves are a thing in the Laboratory. The indefinite article of the gloves is "some".
the protection mask is a thing in the Laboratory.
the key is a thing in the Laboratory.

the cage is an enterable, openable, transparent container in the Laboratory.

after deciding the scope of the player:
	if the player is enclosed by the cage:
		place the key in scope;

Meh … I probably made a mistake (hence the error message) but I am 100% incompatible to the Inform 7 documentation and its treasure hunt style of presenting information and having to read through 100 examples to maybe find the one phrase and situation that benefits me. So I find myself unable to make use of “scope” and thus reacing seems to fail …

after deciding the scope of the player: if the player is enclosed by the cage, place the key in scope.

Writing it like that will NOT say that error message when I close the cage but I can’t take the key either …

Edit: I see light at the end of the tunnel …

Forget about scope - it’s about things not visible which my key is.

Do a rule like “rule for reaching out of the cage, allow access”

I cannot block HERE but I can at least take things now from outside.

before taking something (called item) when the player is enclosed by the cage
if the item is the key:
continue the action;
Say “You cannot reach that from inside the cage!” instead;

Now this - as a barebone and no comment version seems to work. :slight_smile:

(Hanon Ondricek) #9

Your error message is because you have a container called “cage”, not a door. A “door” is not inherently part of a container. You would have needed to CLOSE THE CAGE in your example. The built-in reachability rules would prevent your PC from reaching outside the cage when the cage is closed had the player typed in the correct command or if “door” is defined as a synonym for the cage.

Understand "door" as the cage when the cage is touchable.

And while many people here are willing to help out, at some point every Inform author needs to buckle down and RTFM. You don’t have to read far to design a simple game, but If you want to do fancy tricks (I know personally that erotic games are specifically unusual beasts) you’d greatly benefit taking an afternoon and at minimum skimming through the manual to the point where you understand what stuff is called so you know what to search for when you need it.

(Harald Schuster) #10

Well, the “door” thing happens when you copy and paste from the real story to a shorter demo version. Thanks for pointing that out. The original cage HAD a door. :slight_smile: I was just on the wrong track with the “place in scope” thing alltogether.

And it’s not that I don’t read the Documentation. I always look there first, unsing the index and the search field. And I check Jim Aikin’s Handbook as well. The problem is that the information in Inform’s documentation is not layed out in a way that I get much benefit from it. I am used to a different kind of presentation and I usually come here to this forum only after spending more than two hours reading and fiddling myself. :wink:

The topic I asked here was more a “how to do things properly” and I’ve learned something. Rewriting will probably take too much effort and introduce too many errors but I know to make better use of before rules now instead of trying to cram (almost) everything into instead. And I need better planing - the current thing just grew spontaneously. Planning beforehand should allow for a better decision process what will be allowed or blocked when and under what circumstances so rules affected can be better planned and supported by scene specific rules.