top expert

Continuing to build a “frame” for our varied texts.

where were we.

Last time, we looked at some ways that we can use text substitution to print different texts within simple rules and statements. Experiments included the printed names of things and kinds. Need a refresher? Have a look here.

Let’s Write IF #4: A Basic Design for Highly Variable Texts

let’s keep going.

Looking over our code so far, I can see that we have some bare-bones code for the following:

• a room description that does not vary.
• a printed name of a room (ABR) that varies according to a “print order”
• a table with an empty description “[the table text]”
• four cards: red, blue, green, orange with fixed names and no descriptions
• a custom action, card-picking, that uses the printed name of the noun

Let’s focus on the output for card-picking now. That’s the main mechanic of the game: choosing cards. We are using a “say” definition at the moment for our card-picking rule. Here’s everything so far:

card-picking is an action applying to one thing.
understand "pick [something]" as card-picking.

check card-picking (this is the must pick a tarot rule):
	if the noun is not a tarot:
		say "That's not a card, silly!" instead.
		
carry out card-picking (this is the basic card-picking rule):
	say "[the relevant fortune]".
	
to say the relevant fortune:
	say "My goodness! The [printed name of the noun]! This must be your lucky day."

As-is, I think we can stick with the actions and look out output. Let’s run through some options. Note that I’m not worrying about writing the text itself at the moment. Let’s get the structure in place and then we can think about that.

The tried-and-true “[one of]” construction

We’ve done this before. What might it look like?

to say the relevant fortune:
	if the noun is redc:
		say "You've picked [the noun] [one of]1[or]2[or]3[or]4[or]5[or]6[or][bold type]a lot[roman type] of [stopping] [one of]time[or]times[stopping]!";
	if the noun is bluec:
		say "You've picked [the noun] [one of]1[or]2[or]3[or]4[or]5[or]6[or][bold type]a lot[roman type] of [stopping] [one of]time[or]times[stopping]!";	
	if the noun is greenc:
		say "You've picked [the noun] [one of]1[or]2[or]3[or]4[or]5[or]6[or][bold type]a lot[roman type] of [stopping] [one of]time[or]times[stopping]!";	
	if the noun is orangec:
		say "You've picked [the noun] [one of]1[or]2[or]3[or]4[or]5[or]6[or][bold type]a lot[roman type] of [stopping] [one of]time[or]times[stopping]!";	

This looks bad, doesn’t it? Imagine if we had full sentences instead of numbers in our conditional text! It would be very hard to read. Avoid hard-to-read code! That’s not the only issue, though. We also probably want some kind of state tracking, don’t we? There’s no mechanism here or in the rule itself for tracking the number of cards taken. Yes, Inform does know how many times we’ve taken these cards, but the method isn’t ideal for our needs. Besides, we’ll want to use our own handmade variables for readability and ease of use.

keeping track.

Let’s make some counters. We do this kind of thing all the time.

a tarot has a number called clicker.
a clicker is usually zero.

I called it “clicker” because I imagined something like cookie clicker. You can name it anything you want! I could have done this other ways. I could have had variables that weren’t affiliated with nouns:

red card clicker is a number that varies.
red card clicker is zero.

That option isn’t great for us, though, because can’t deal with clickers in a general way. With the second example, we’d have to have unique code lines for each tarot:

carry out card-picking redc:
	say the relevant fortune;
	increment the red card clicker.

If we use clicker in a more generalized way, we can say

carry out card-picking:
	say the relevant fortune;
	increment the clicker of the noun.

As much as we can, I’d like to avoid making rules that only apply to one card. Let’s use a kind (tarot) if possible.

what numbers are for.

A couple of posts ago, we tried to use a number “[print order]” in our [one of] constructions. It wasn’t optimal. As in today’s case, it seems we’re out of gas with our [one of] approach. That’s great for adding a bit of spice to a text, but my goal with this design is to have a lot of variation. I want to be able to read the options easily, instead of combing through a glob. How would that work? I think the answer is to use a table. If you’ve been with me for long, you probably saw this coming. A table is a good way for us to organize text. There are lots of ways we can use code to get at it, too. Let’s make one. This isn’t actually my final table design, but let’s get started with something easy.

Tables are a little intimidating, but don’t worry! We’ll talk through it. To start, you just need a name.

table of picked cards

What kinds of things can you put in a table? Our big focus is text; we want to have 1) a place to put text and 2) a way to find it. We could keep other things there: nouns, actions, numbers, really any kind could go in the column of a table. Inform’s big requirement is that everything in the column of a table be the same kind of entry. At least one of our columns will be text. The other will be a number. How about this:

table of picked cards
index	red	blue	green	orange
1	"red"	"blue"	"green"	"orange"
2	"red"	"blue"	"green"	"orange"
3	"red"	"blue"	"green"	"orange"
4	"red"	"blue"	"green"	"orange"

After our title, we name our columns. In the example above, I’ve made five columns: an “index” column that holds a number, and four more columns representing our four cards. Inform is usually smart about recognizing a column’s contents by looking at the first row of data. It will know we are dealing with text and a number without any special effort from us. I’ve gone ahead and made four rows, just to give us a little room for experimentation: Inform doesn’t like it when it tries to find something in an empty row!

“Index” is a fairly common name for a column that contains a row number. You don’t have to call it that, you can call it anything! But I’m used to “index,” so that’s what I’m going with. If we could tie “index” to something, we’d have a way to look up our information.

(side note: Inform could just reference row number. The actual “index” column is for us, because it’s easier for us to read. We don’t want to manually count rows when we’re checking our code)

We have clickers for our cards, but let’s also have a single, general number.

magic number is a number that varies.
magic number is one.

Ok. How do we look up some text according to a magic number? We need an action processing rule. Let’s change our “to say” definition for what we’re calling “the relevant fortune.”

First, we need to tell Inform which the row (and table) where our information is located. We can base this off of our so-called “magic number.”

to say the relevant fortune:
	choose row with an index of the magic number from the table of picked cards;

Since we haven’t made a way for the magic number to change, that means Inform will choose row one because it has an index of one, which matches the magic number. Once the row is picked, it will stick. Now, we can have a look at the rest of the row.

to say the relevant fortune:
	choose row with an index of the magic number from the table of picked cards;
	if the noun is bluec:
		say blue entry;
	otherwise if the noun is redc:
		say red entry;
	otherwise if the noun is greenc:
		say green entry;
	otherwise if the noun is orangec:
		say orange entry.

That yields this:

>pick red
red
>pick blue
blue
>pick green
green
>pick orange
orange
>pick red
red

This isn’t very exciting, but we are getting data out of a table. We have places to put our text! Still, this isn’t really baked yet. Some to-do items and observations:

• Formatting-wise, our “fortunes” need a line break. This is because there aren’t periods or other sentence ending punctuation marks to tell Inform to add a break. We will ultimately be using sentences in these fields, so that’s ok. Otherwise, we’d want to add “[line break]” to our texts.
• The above example is just reading from row one again and again. We need to push the number up (without letting it get higher than the number of filled rows).
• This all looks a little busy. If we had full sentences in our table of picked cards, it would be difficult to hunt down what we were looking for (or proofread, probably).
• I don’t personally like the large number of [if] statements. I think I’d prefer individual rules for each noun, or, better yet, a single, short rule that can do it all. Reminder, my goal is to use kinds (instead of specific things) as often as I can in action rules.
• I haven’t used the clickers yet!

How would we do these things? This is more of a data organization problem than a code problem, believe it or not. If we can come up with a solid plan for organizing our texts, we can have simple code and readable tables. That will help us come up with some (hopefully) good fortunes that will be easy to track and revise. We’ll focus on that next time, hopefully coming up with a model we can use for all of our variable text in titles, card names, room descriptions, and more! Don’t miss it.

Once we get everything scaffolded, we can start laying down some text.

today’s source

next.

There’s a table in my table.