Front matter for our weird color-picking game, and using our first extension.
last time, on Let’s Write IF.
In last week’s episode, we discussed a method for using a simple “table of contents” as a way for Inform to decide what text to print. This was accomplished by creating a new table, modifying our “card-picking” action, and creating a “to decide” definition. Need a refresher? Check it out here:
beginning.
By default, an Inform 7 game begins by printing title and platform information. This happens by virtue of one of many rules that are part of Inform 7’s Standard Rules. In this case, the rule is the DISPLAY BANNER RULE and it is part of the STARTUP RULEBOOK. Inform 7 projects are made up of rules, and we’ve made a few in the course of our project. Rules are just what they sound like; they govern the behavior of compiled Inform 7 code. Rulebooks, for most of us, are a more slippery concept: rules live there, and the rules in their respective rulebooks execute in sequence, one at a time.
We will only rarely need to think about the specific order of rules within a rulebook, because we will be using the entire action processing sequence (BEFORE, INSTEAD, CHECK, CARRY OUT, AFTER, and REPORT). Making good decisions about which of these rule types to use will keep things happening when and how we want in most cases. This is one of the reasons (there are many more!) that experienced authors tell beginners to avoid overusing INSTEAD rules. While it does work in simpler programs, it can become hard to know at a glance what will happen when in a game made exclusively of INSTEAD rules.
Inform tends to handle things in actual order within the source code (first match first) when everything else seems equal. Imagine trying to keep track of that in a 20,000-word project!
The DISPLAY BANNER RULE is, by default, the very first thing that prints in a game. This is usually fine: that’s the tradition, and people are accustomed to it. However, we might want to do something different. Perhaps we have a dramatic blurb that could set the stage. Maybe a content warning is in order? In our case, a tutorial message might be better if set apart from the narrative voice of our game. First of all, we need to stop the display banner from printing. To do this, we simply delist the rule.
the display banner rule is not listed in the startup rulebook.
Note that, in making such a declaration, we really ought to commit to printing the banner elsewhere. Besides giving ourselves credit, the banner acknowledges the platform and version number. It’s appropriate to give credit where credit is due, after all. But no worries, we will absolutely do so! To do something when play begins, we simply use the preamble “WHEN PLAY BEGINS.”
when play begins:
say "[italic type]Portrait With Wolf ^_^[roman type] is a fortune telling game in which the player chooses between one of four colors. Once the player has chosen eight times, the fortune is complete.
This game contains coarse language and potentially disturbing content. Please consider whether this work is appropriate for you."
Note that I’ve italicized type with the bracketed [ITALIC TYPE] substitution and switched back to “normal” text via [ROMAN TYPE]. The content warning is not very helpful; it’s a placeholder for when the game is completed. Let’s look at the output.
Portrait With Wolf ^_^ is a fortune telling game in which the player chooses between one of four colors. Once the player has chosen eight times, the fortune is complete.
This game contains coarse language and potentially disturbing content. Please consider whether this work is appropriate for you.
A Brightly Lit Room!
A bare place. A bright light emerges from an unknown source above.
A small metal table stands under the light. It is covered in gray, chipped paint. The following items rest atop it:
a red card
a blue card
a green card
an orange card
>
This doesn’t look great, does it? We should probably place the warning on its own screen, then start the game proper. To do that, we’ll need to install an extension. Extensions are code projects that can be used to, well, extend the capabilities of Inform 7. The Standard Rules is an extension. Ultimately, we’ll talk about finding extensions and downloading them, but I strongly encourage new writers like us to wait before doing too much with them. Many are quite complex, and if we don’t know what we’re using we can find ourselves troubleshooting code we didn’t write and don’t understand. As an example, the extension we’re downloading, Emily Short’s “Basic Screen Effects,” contains Inform 6 code that is completely alien to me.
In brief: keep things simple at first, and only use extensions as necessary. The more experience you have, the easier it will be to judge when something will and won’t work for your project. Back to the extension:
include Basic Screen Effects by Emily Short.
Since this extension is installed with Inform 7, that is all that must be done. I prefer keeping this kind of code at the top of the project, near its title information. Since the extension is installed, it (and other installed extensions) can be viewed by selecting “file>open installed extension>Emily Short>Basic Screen Effects” from the drop-down menu at top-left of the IDE (Inform 7 programming application). If you do open it, scroll down to the section labeled “DOCUMENTATION” for instructions and sample code.
Basic Screen Effects is so commonly used that I put it any new project as a matter of habit. What will we do with it? Let’s add an any key prompt.
wait for any key;
Next, we clear the screen.
clear the screen;
Both of these phrases only work if Basic Screen Effects is installed. Next, let’s return to our banner. Note that we can use a phrase beginning with “follow” to execute any defined rule.
follow the display banner rule.
However, when we put it all together, things look a bit off. The banner is at the very top of the screen! Attentive players know that there is usually a blank space between the top of the screen and the banner text. We should add our own spacing to maintain convention. Checking another game, it looks like four blank lines is common. Let’s modify our code. Inform’s [PARAGRAPH BREAK] substitution ads two blank lines, so if we add two, everything should look right.
say paragraph break;
say paragraph break;
Note that we don’t need quotation marks here, since there is no actual quoted text. However, we could just as easily use…
say "[paragraph break]";
…if we wanted to.
For completeness’s sake, here’s the rule altogether.
when play begins (this is the PWW startup rule):
say "[italic type]Portrait With Wolf ^_^[roman type] is a fortune telling game in which the player chooses between one of four colors. Once the player has chosen eight times, the fortune is complete.
This game contains coarse language and potentially disturbing content. Please consider whether this work is appropriate for you.
Press any key to begin [italic type]Portrait With Wolf ^_^[roman type]";
wait for any key;
clear the screen;
say paragraph break;
say paragraph break;
follow the display banner rule.
Obviously, once we have a better idea of what our game is like, we might elaborate on instructions, content warnings, or add other information. But this is a fine framework to work from.
today’s source code.
next.
Now that we have a beginning, we should make ourselves an ending. Our current code will throw a runtime error when the eighth color is picked, which isn’t ideal! We’ll take care of that next time.
One response to “let’s write IF #8: before we get too far into this”
-

[…] let’s write IF #8: before we get too far into this […]
LikeLike

Leave a comment