Instead of asking Nurse about something when the topic understood matches the regular expression "\bdoctor":
say "Whatever."
doesn’t work if the player types Doctor or DOCTOR?
Is there a way to make the input case insensitive?
Ye gods, man! Why are you using regexes for ordinary conversation??? Unless there is some highly, highly specific and very good reason why you have to do it this way, and therefore like manually reimplement Inform’s parser as to every possible subject of conversation, you’d be much, much better off using the built-in systems for this stuff.
See 7.7. Saying Simple Things in the Recipe Book, especially the tokens stuff in Sybil 1, to get started.
2 Likes
I highly recommend Conversation Framework by Eric Eve. It defines actions that allow you to refer to things in conversation instead of topics. Very convenient.
3 Likes
This happens in Glulx because command input is not converted to lower case automatically when the command is processed.
While I agree with the suggestions by DeusIrae and rileypb, the most direct answer to your question is that you can manually convert the contents of the topic understood for the purposes of evaluation:
Instead of asking Nurse about something when the topic understood in lower case matches the regular expression "\bdoctor":
say "Whatever."
See WWI 20.4 Upper and lower case letters.
You may also want to look into the if <snippet> includes <topic>... functionality specified in WWI 18.33 Reading a command. I believe that it is a lot less computationally expensive to use than regex matching.
1 Like
Yes, I would do:
Instead of asking the nurse about "doctor":
Not to pick on Daniel who’s just mimicking the OP’s rule preamble, but I really wouldn’t use an Instead rule for this.
Fun story – in my first game I wasn’t yet comfortable with Inform’s complex before/after/check/carry out/report rules structure, so I just put basically everything I did into Instead rules, since those were easy to understand – including dozens of conversation rules of the type “Instead of asking CHARACTER about TOPIC”.
Except then I got halfway through the game and realized I had a sequence where the player needed to stay quiet, but since none of those conversation rules ever lead to a completed action, I couldn’t write a single “After asking someone about something” rule to cover what happened if the silence was broken – cue like an hour of copy-and-pasting, and of course I missed a couple which created some new bugs.
Don’t be like me, and don’t use Instead rules unless you really need to!
5 Likes
That’s just how someone told me to do it either here or on Discord when I was trying to figure out how to implement dialog into my first game, it seemed to work at the time so I kept doing it. I was starting to wonder if there was a better way to handle conversation.
Anyway, I looked over the examples from the documentation that you linked. They’re still using “instead” rules. Is there another way to do it?
The later examples mostly use Carry Out rules, I think, which is probably the best practice here.
2 Likes
The general convention is to use Instead rules for exceptional behavior and Carry out/Report rules for standard, expected behavior.
2 Likes
To elaborate on that a little—
The purpose of Instead rules is to override the usual action processing. They keep the standard implementation (carry out and report) from running, because presumably you want something special to happen instead. After your “instead of taking the lobster” rule, you don’t want the game to move the lobster to the player’s inventory and say “Taken.”.
And this is a good thing! The Standard Rules handle the default implementation, and then you write all the exceptions and special cases that make up your game.
But it means you don’t generally want to use Instead rules to create the standard, expected, default implementation of an action. Because the point of the default implementation is that Before, Instead, and After can intervene at specific points to interfere with it: Before kicks in before the feasibility checks, Instead kicks in before the actual functioning of the action, and After kicks in before describing the results. If your default implementation is done in Instead rules, you lose that flexibility to modify it.
So the question is: is this conversation system a default implementation you’ll want to override in specific ways? Or is it a special case that’s meant to override the default implementation?
Depending on your game, it could be either! The Standard Rules give a default implementation of all the conversation actions that just does nothing at all, with the intent being that you can override it with Instead rules to do the specific things your game needs. This works well for games where conversation is only a minor point with a handful of rules for the special cases you want to use. But in a game that’s full of conversations with all sorts of people, you might want to build your own default implementation (maybe consulting a table of responses written for each person), which you can then override for the special cases (like Mike’s “don’t break the silence” scene).
There’s no single correct answer here. It fundamentally comes down to the needs of your game and how conversation is going to be implemented.
5 Likes
I decided to start working on fixing a section of dialog gradually, by first changing the INSTEAD OFs to CARRY OUTs.
Carry out asking the Waitress about something:
say "[one of]'I simply don't know what you mean.'[or]'That seems irrelevant.'[cycling]"
Carry out asking the Waitress about something when the topic understood matches the regular expression "\bdiner":
say "I had to work to get this place. I don't know why or how."
ask waitress about diner now yields:
"I had to work to get this place. I don't know why or how."
"That's simply not important now."
There is no reply.
When things said “instead of”, You’d get only the appropriate reply.
For now, I am going with the “topic understood in lower case” band-aid so I don’t break my game. If I can figure out how to “fix” my dialog without breaking it simultaneously, I’ll redo everything.
My recommendation would be to keep the Instead rules but to use Inform’s normal parser instead of regex matching, for what it’s worth.
2 Likes
The “There is no reply” comes from the “block asking rule”, which is a Report rule (“Report an actor asking something about”).
One way to prevent that message from being printed (in those cases when people have something interesting to say or do) is to use “After” rules, which end the action as a success and prevent the Report rules from firing:
After asking Adam about "foo/bar/baz":
say "Adam nods.".
This will only print “Adam nods.”, not “There is no reply.”.
1 Like
In my ever-humble opinion, the doc examples overuse Instead rules. Daniel did a good job laying out the thinking behind it, but I’d submit variously:
- if you’re just forwarding something to a different action, a Before rule’s a better choice. Using an Instead rule instead of a Before rule just buys you an extra trip through the visibility/accessibility/carrying requirements rules (unless someone has a very weird and specific reason it’s a good thing to go through them the first time in the context of the original action)
- There’s rarely a downside to pushing specific behavior into check rules, and doing so helps keep the Instead rulebook free for the really weird exceptional behavior.
- There are a lot of anecdotes to be found in the forums of people who regret overusing Instead rules because it turned their code into a hard-to-understand hard-to-modify mess. I’ve never seen a single account saying “I wish I hadn’t used Check rules so much”. (I’m sure there are instances of “Hey, this discrete thing would have been better as an Instead rule”, but that’s a different thing from “I wish I’d automatically reached for Instead rules more often.”)
(That’s just one person’s opinion and there are people with far more experience than I have who embrace Instead rules for more things than I would, so take it as you will.)
You got disappointing results here 'cause every applicable Carry Out rule in the action’s Carry Out rulebook runs. You’d have to stop the action to keep from proceeding to the next. The docs advise structuring things in a way that minimize using explicit stop/continue the action (and if recollection serves they don’t make very clear that stop the action doesn’t do what you expect in the Carry Out rules: it stops that rulebook, but you continue to the After rules normally).
If you’re dealing with a situation that doesn’t change the game state and makes you tempted to stop the action in a Carry Out rule, it’s a good sign that you’d be better off with Check or Instead for that case. (Or maybe an After rule, as @StJohnLimbo just suggested, but I’d been assuming the “simply not important” was from a different Carry Out rule.)
4 Likes
That’s a little over my head but you’ve given me some key terms to look for.
I am a pretty bad coder and have been cobbling games together the only way I know how, which involves a lot of uses of “instead.” From what you’re saying, I’m probably going about things the wrong way. I’ll see if I can figure out how to use Check and Carry Out.
My current predicament is that a collaborator and I are trying to slam out a game by the ECTOCOMP deadline. The dialog works as-is though we have had to up the MAX_STATIC_DATA and I’m wondering if that problem was caused by the way we are handling dialog. Anyway, for our workflow we have to pass working copies of the game back and forth a couple of times a day, so if I’m going to break anything I have to be prepared to fix it immediately on the spot. Right now I don’t know how to do that.
I’ll read up on dialog and Check and Carry Out though and see if I can figure out a better way to structure dialog. I’m thinking there’s probably some way I could put this all in a table or something.
1 Like
If you’re working toward the ECTOCOMP deadline, I definitely don’t think switching to check/carry out rules is worth it. I do think switching to use Inform’s parsing facilities instead of regexes will save you a lot of time in testing and debugging, though.
2 Likes
Thanks, I will try to figure that out.
Instead of asking Waitress about something:
say "[one of]'That's simply not important now.'[or]'That seems irrelevant.'[cycling]".
Instead of asking Waitress about "diner/work/job":
say "I had to work to get this place. I don't know why or how."
ASK WAITRESS ABOUT DINER
yields
"That's simply not important now."
What I’m trying to accomplish is that when the waitress is asked about a topic we have accounted for, she gives an appropriate answer. When the waitress is asked about a topic we haven’t accounted for, she gives a throwaway answer. This worked using the regular expression thing.
Wild stab in the dark here: try putting the irrelevant rule at the end of the instead rule book? (Or just declare it last?)
1 Like