Daily Nugget # 1: Asking a question to the player before play begins

Hi All, I feel like every day brings something new to the table. It is not always a huge find, but sometimes the little things are just the more rewarding.

Searching the forum gave me this: Asking questions of the player before play begins - Authoring / Inform 7 - The Interactive Fiction Community Forum (intfiction.org)

However I wanted to achieve a relatively simple effect:

  • Print some introductory text leading into the…
  • Print game’s banner text
  • Ask a yes/no question to the player
  • Show starting room description

And then allow the player to start commanding the game.
I remembered Emily Short asks a tutorial question in Bronze, and so I had a look at the source code: http://inform-fiction.org/I7Downloads/Examples/bronze/source.txt.

The answer was much simpler than I expected. I have taken the liberty to rewrite it a bit in order to be able to use it (replaced the change commands by now commands):

The story description is "Once upon a time..." [the introductory text]

When play begins:
	say "[the story description][paragraph break]".

Setting is a kind of value.
The settings are unset, functioning and dead.
Novice mode is a setting that varies. Novice mode is unset.

After printing the banner text:
	if novice mode is unset:
		say "[line break]Have you played interactive fiction before? >";
		if the player consents:
			now novice mode is dead;
			say "[line break]If you have not played [story title] before, you may still want to type HELP to learn about special commands unique to this game.";
		otherwise:
			now novice mode is functioning;
			say "[line break]Some extra command help is provided, though you may turn it off at any time.".

Of course to complete implementation of “novice mode”, you no doubt want to add commands to disable or enable it later on. For further details check out the source code link provided above.

7 Likes

Nice! Since this thread has a clear title for searching, I’ll share a method I’ve been using for numerical values. I can’t take credit for it. Wade Clarke wrote it; I just changed some values and texts.

To decide what number is the key-pressed:
	let keypress be 0;
	while keypress is 0:
		let keypress be the chosen letter;
	now keypress is keypress minus 48;[returns a '1' if player pressed 1, '2' if they pressed 2, etc. If you want to collect/interpret alphabet keys as well, you'd comment out this line, but it makes life easier if all you want to do is collect numbers from 1-9]
	[say "* Keypress number is [keypress].[line break]";][Uncomment this line to see what number the game is seeing when the player presses a particular key.]
	decide on the keypress;

To ask the resolution question:
	say "This 25th Anniversary Edition of [it]Repeat the Ending[rt] can optionally display artwork by Callie Smith. Because different hardware and software systems present images differently, you can choose between small, medium, and large image sizes. Note that this choice can be changed at any time by entering the *GRAPHICS* command.[lb]";
	say "What image size would you prefer?[pb]";
	say "(1) Small[lb]";
	say "(2) Medium[lb]";
	say "(3) Large[lb]";
	say "(4) Print image descriptions instead[pb]";
	while 1 is 1:
		let KEYPRESS be the key-pressed;
		if KEYPRESS > 0 and KEYPRESS < 5:
			say "[lb]This setting can be changed at any time by entering the *GRAPHICS* command.
[pb]***[pb]";
			now resolution is KEYPRESS;[store the answer for later in this variable.]
			make no decision;[ends this keypress loop]

When play begins:
	ask the resolution question;

note that I have some substitutions for line and paragraph breaks

4 Likes

The usual strategy of “use the RULES command” to find out where to intervene doesn’t help for the startup sequence. The following allows manipulating it programmatically:

Section Debug Rules (not for release)

A debug-verbosity is a kind of value.
The debug-verbosities are rules off, rules on, rules all.
To debug (dv - a debug-verbosity): (- debug_rules = ({dv} - 1); -)

…and then one could

after starting the virtual machine, debug rules all.

And looking at the Standard Rules directly can be helpful, too:

Note that the Standard Rules frequently use a pattern of repeatedly saying that successive rules are listed first or listed last, a practice referred to in WI 19.4: Listing rules explicitly. It can be a little confusing at first glimpse, but it’s not hard to get. With:

The A rule is listed last in the whatever rules.
The B rule is listed last in the whatever rules.
The C rule is listed last in the whatever rules.

the order really ends up being A, B, C. (If there aren’t issues of preamble-specificity affecting rule order, the behavior for is listed in is the same as is listed last in.) But with

The A rule is listed first in the whatever rules.
The B rule is listed first in the whatever rules.
The C rule is listed first in the whatever rules.

the order ends up C, B, A. The Standard Rules will sometimes do both of these for a given rulebook, like the Startup rules, excerpted below (omitting some lines not having to do with adding rules).

The start in the correct scenes rule is listed first in the startup rulebook. [7th.]
The position player in model world rule is listed first in the startup rulebook. [6th.]
The declare everything initially unmentioned rule is listed first in the startup rulebook. [5th]
The update chronological records rule is listed first in the startup rulebook. [4th.]
The seed random number generator rule is listed first in the startup rulebook. [3rd.]
The virtual machine startup rule is listed first in the startup rulebook. [2nd.]
The initialise memory rule is listed first in the startup rulebook. [1st.]

[ the comments above are in the original source; the comments below I've added ]
The when play begins stage rule is listed in the startup rulebook. [8th]
The fix baseline scoring rule is listed in the startup rulebook. [9th]
The display banner rule is listed in the startup rulebook. [10th]
The initial room description rule is listed in the startup rulebook. [11th]
3 Likes