Asking the player for a number

Once again I come to you with the ever-changing Test Game by C.E.J. Pacian. This time I want to ask the player to supply a number.

Based on the example Down in Oodville, I came up with the following:

[code]“Test Game” by “C.E.J. Pacian”

Someplace is a room.

Instead of jumping:
say “You carefully consider your jumping routine.”;
now the command prompt is "How many times do you want to jump? > ".

To decide whether hopping:
if the command prompt is "How many times do you want to jump? > ", yes;
no.

Understand “[number]” as selecting.

Selecting is an action applying to one number.

Carry out selecting:
say “You don’t need to supply a number right now.”

Instead of selecting when hopping:
say “You jump [the number understood] times.”;
now the command prompt is “>”.

Instead of doing something other than selecting when hopping:
say “Maybe not then.”;
now the command prompt is “>”.[/code]

This gives us the following:

That’s all fine apart from that last bit. Borrowing some code from here:

Rule for printing a parser error when the latest parser error is the didn't understand that number error (this is the Numbered Disambiguation Choices don't use number rule): now the latest parser error is the didn't understand error; make no decision.

We now get:

Which I guess kind of fixes the last command (although is there a reason it shouldn’t be a “not a verb I recognise error”? when does the “didn’t understand error” actually get triggered normally?) but now our attempt to jump “loads” is worse.

Is there some way to just read in the player’s command (as in Identity Theft, for example) and see if it’s a number?

NBx1: Why not just implement a new command like “jump [number] times”? In this simplified example, that might be the right answer. In my actual project, the command required would be lengthy and non-intuitive.

NBx2: I am still using 6G60 - however the main reason I was sticking with this old version was in a vain attempt to release for the Z machine, which my project has recently exceeded. I’m not super thrilled with dealing with the ten million syntax errors I expect to get based on my brief flirtation with 6L38 way back when it first came out, but I’ll bite the bullet if it’ll help.

If I change the following:

Rule for printing a parser error when not hopping and the latest parser error is the didn't understand that number error (this is the Numbered Disambiguation Choices don't use number rule): now the latest parser error is the not a verb I recognise error; make no decision.

I get:

Which seems like the result I want, but I’m still concerned about the possible conflation of errors going on.

This all seems very complicated when all I really want is a way to try converting the player’s command to a number.

I believe that what’s going on is that, when you have an Understand line without a verb in it, Inform will take any command that doesn’t start with an apparent verb and try to match it to that token. So ordinarily, what Inform does is to check to see if the first word is a verb or direction, and if it doesn’t it returns the not a verb I recognise error. But if you’ve got a line that Understands “[number]” as an action then it can’t return an error as soon as it doesn’t recognize the first word as a verb/direction, so then it tries to match “hooray” to the “[number]” token. When that doesn’t match you get the “didn’t understand that number” error.

By the way you can convert the player’s command to a number without going through the parser if you want, by using After reading a command:

[code]“Test Game” by “C.E.J. Pacian”

Someplace is a room.

Instead of jumping:
say “You carefully consider your jumping routine.”;
now the command prompt is "How many times do you want to jump? > ".

To decide whether hopping:
if the command prompt is "How many times do you want to jump? > ", yes;
no.

After reading a command when hopping:
if the player’s command matches “[number]”:
say “You jump [the number understood] times.”;
otherwise:
say “Maybe not then.”;
now the command prompt is “>”;
reject the player’s command.

After reading a command when not hopping:
if the player’s command matches “[number]”:
say “You don’t need to enter a number now.”;
reject the player’s command.[/code]

I don’t know how you want to handle non-number commands when hopping really. The way you had it originally set up seems to me a bad idea–it has the effect that if the player enters a valid command it’ll stop the jump but won’t execute the command, which seems like the worst of both worlds.

Maybe this covers it:

[code]“Test Game” by “C.E.J. Pacian”

Someplace is a room.

Instead of jumping:
say “You carefully consider your jumping routine.”;
now the command prompt is "How many times do you want to jump? > ".

To decide whether hopping:
if the command prompt is "How many times do you want to jump? > ", yes;
no.

After reading a command when hopping:
if the player’s command matches “[number]”:
say “You jump [the number understood] times.”;
now the command prompt is “>”;
reject the player’s command.

Before doing something when hopping:
now the command prompt is “>”;
say “Maybe not then.”

For printing a parser error when hopping:
say “I didn’t understand that–enter a number, or try doing something else if you don’t want to jump after all.”

After reading a command when not hopping:
if the player’s command matches “[number]”:
say “You don’t need to enter a number now.”;
reject the player’s command.[/code]

If the command is a number, then the After reading a command rule grabs it. If the command is not a number but is parseable, then it gets turned into an action so you can use the Before rule to print “Maybe not then” and change the command prompt. (Make sure that that’s the first Before rule.) Otherwise, the command winds up as a parser error, so you can print your custom message, and since you don’t change the command prompt you’re still hopping.

Thank you!

if the player's command matches "[number]":

I think this is basically what I was missing. I should probably just sit down and read Writing with Inform one of these days to learn things like this - unfortunately, I’m lazy.

You’re right, and your suggested solution works very neatly. I shall rip it off wholesale.

Thanks again.

You have to be a bit careful–I kept trying this:

Rule for printing a parser error when the player's command matches "[number]":

but it reintroduced “I don’t understand that number” as a response to “hooray.” I’m not at all sure why. (The parser internals can be pretty opaque.)

Anyway, glad to help!

This is something that will be covered by Unified Glulx Input. UGI isn’t finished but it handles this case now – see the “Requesting a Number” example.

github.com/erkyrath/i7-exts/blo … 0Input.i7x

That looks cool–but also scary, or anyway the kind of thing that I could only use out of the box unmodified. Is a lot of the extended functionality going to require diving into parser internals like TryNumber?

Shouldn’t. Look at the two keystroke examples.

The main point of UGI is to write games that don’t use the parser, or make it optional. When you’re bypassing the parser, obviously you don’t need to touch parser internals.

Also, think about how you’d have to implement this feature – asking for a number as a separate input – without UGI. Honestly I’m impressed that I did it with just one short I6 function call. :slight_smile: