top expert

Today: keeping our texts in separate tables for readability, and using definitions to keep track of it all.

last time, on Let’s Write IF

After experimenting with different options, I decided that using tables would be the best way to manage text in my little fortune-telling game. I left with a few concerns, though. I was especially worried about keeping the code readable and simple, and also wondered what kinds of tables would be the easiest to populate and proofread. You can get caught up here:

let’s write IF #6: more design thoughts on a project with highly variable text

breaking up is (not so) hard to do.

My table of fortunes, simple as it is right now, will probably be hard to read, edit, and maintain in the long run. Let’s look at it (I’ve expanded it to eight rows).

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"
5	"red"	"blue"	"green"	"orange"
6	"red"	"blue"	"green"	"orange"
7	"red"	"blue"	"green"	"orange"
8	"red"	"blue"	"green"	"orange"

I’d like to do a table per color, instead. I’d prefer a small table per color. For example:

table of red fortunes
index	text
1	"red"
2	"red"
3	"red"
4	"red"
5	"red"
6	"red"
7	"red"
8	"red"

There could be (at least) one for every color. As indicated last time, we could check a fortune by using four rules, one for each color, as in:

carry out card-picking a redc:
	choose row with an index of the magic number from the table of red fortunes:
		say the text entry.

This is fine. The table is easy to read, and the rule is easy to follow. However, it could be limiting in the long run. What if, for instance, we wanted a cycle of sessions or “games,” each made up of eight possible fortunes? I think I’d like to go ahead and think about ways to handle more complex situations, even though it isn’t necessary right now. This will also help us use a single rule for drawing cards, which is one of my design goals. How would that work? Let’s create a sort of table of contents:

table of contents
tarot	table
redc	table of red fortunes
bluec	table of blue fortunes
greenc	table of green fortunes
orangec	table of orange fortunes

Note that our table of contents contains the four tarot cards. Inform will recognize column types automatically without a little fuss, so it knows that when we refer to that column we mean members of the tarot kind (redc, bluec, greenc, and orangec).

This allows us to take the noun from the player’s command and use it to find the right table! Consider this code:

to decide which table name is the current collection:
	choose row with a tarot of the noun in the table of contents;
	let t be the table entry;
	decide on t.

A “to decide” is what Inform 7 calls a definition. We can use definitions to establish set routines for Inform to follow when processing our rules. In this case, we want Inform 7 decide which table to use from the table of contents. We need to tell it how to do that. In this case, the magic phrase is “to decide which.” We follow it with something that varies (a number, a noun, a value, or even a table name) followed by the name we will refer to it. I picked “current collection” because it makes sense to me. You can choose anything you like; current collection isn’t a baked-in Inform 7 name.

Next, we send it through some familiar table operations. The interesting part is that we are choosing a row based on the “noun” in the current action. From there, we assign a temporary value (“t” is again my choice, you can call it anything you want). Finally, we close things out with “decide on t.” Whenever we refer to “current collection” in our code, Inform will go through this process to determine which table to use.

As a note of caution: this assumes that there will be a noun, so it isn’t going to work where that isn’t applicable. We have options for getting around that, but let’s see if we need it first.

We can make another definition to handle what is said:

to say a default fortune:
	choose row with an index of the magic number from the current collection;
	say text entry.

It’s just what it looks like: a “to say” definition creates a text substitution that we can use. What’s special about it? We can use some pretty complex code in a substitution, including activating rules or firing off actions. In this case, we’re just doing a simple table lookup, but that’s more than we could do in a simple quoted passage! This also leaves us room to do something more complex later if we need to. Finally, our new card-picking rule to tie it all together.

carry out card-picking (this is the basic card-picking rule):
	say "[a default fortune]";

I’d like to add some things to it, just in case. Let’s increment the clicker of the noun, so we can keep track of how many times each card has been drawn. I’d also like a separate variable for tracking the current tarot. Finally, we need a way to increment the magic number. None of this is necessarily the best way–we haven’t written enough to know–but let’s get something down.

cnoun is a tarot that varies.

carry out card-picking (this is the basic card-picking rule):
	say "[a default fortune]";
	increment the clicker of the noun;
	increment the magic number;
	now cnoun is the noun.

OK. Now we have something that updates by magic number. If I add numbers to my red table, I get this output.

>pick red
red 1
>g
red 2
>g
red 3
>g
red 4
>

Not super exciting to read, but we’ve gotten a lot done under the hood! Soon, it will be time to start filling in the blanks. Some future considerations:

• Is this all that I want to vary? What should the overall play experience be like? What should the screen look like?
• Once the magic number reaches eight, the player will get a run-time error because we have run out of rows. What to do?
• How should we deal with the usual parser stuff (all the verbs, etc that aren’t relevant here)?
• How should we teach the player how to engage with this work? Is there a narrative frame, or what?

We can’t get to it all at once. It’s a lot to chew on!

Current source code.

Next

Ending the cycle and finding more content to vary.