top expert

a biting cat website

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

Where will all of this text go?

planning things out.

So far, we’ve been looking at ways to vary text in simple but effective ways. But where should the text go? As a reminder, this series is meant to demonstrate an actual design for a small widget/toy/thingy. I have said it’s a fortune telling game. My plan for this series is to focus on the design, rather than on my own text. Why? I want you to be surprised when you play it in next year’s Spring Thing (you are going to play it, aren’t you?)! Here’s the basic idea.

Large/broad ideas

  • A single room.
  • Very few nouns.
  • Completable by entering one-letter commands (a choice design).
  • Multiple endings with one “true” ending (like a visual novel)
  • Imitate gameplay of “single choice” jam games
  • Experience is made up of single screens in which all printed text varies.

Mechanics (to start)

  • Four cards are on a table. Every turn, the player can pick one of four cards. The player’s choice will dictate what the output is.
  • After eight draws, the player will reach an “ending.”
  • A cycle of endings based on which cards have been chosen.

a bare-bones setup.

To get started, we’ll need some cards on the table. That’s not too hard. I’ll set it up, and then we can talk about it.

a redc is on the table.
the printed name of redc is "red card".
understand "red / card" as redc.

a bluec is on the table.
the printed name of bluec is "blue card".
understand "blue / card" as bluec.

a greenc is on the table.
the printed name of greenc is "green card".
understand "green / card" as greenc.

an orangec is on the table.
the printed name of orangec is "orange card".
understand "orange / card" as orangec.

If you’ve been reading along, this might look like overkill. Why non-English thing names? Creating separate printed names and “understand” phrases is extra work. That’s definitely true! I have a couple of things in mind:

  • We are going to be using these things a lot. I don’t want to type out a long, two-word name every time I do something with a card.
  • Printed name is text, and we are varying all text, remember? So we’d be declaring a printed name no matter what.
  • I am interested in minimizing what the player has to type, and I may need to tinker with what Inform recognizes as names for the cards. The current “understand” phrases are just placeholders for future experiments.

That’s not all. We are definitely going to need a way to refer to the cards as a general category. That’s easy! We will define a kind.

tarot is a kind of thing.
the plural of tarot is tarots.

redc is a tarot.
bluec is a tarot.
greenc is a tarot.
orangec is a tarot.

I like declaring a plural when I set a kind up. I may never use it, but since I’m there, why not? The kind will be very helpful, since it lets us say things like

carry out taking a tarot:

…and so forth.

an action.

We have cards. What should we do with them? It’s time for a new action.

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

Alright. Note that “card-picking” is a long action name. We won’t be typing it too many times. Most of our code is going to refer to values and nouns. You might be wondering why I didn’t strictly define the pick command as something used with a tarot. The answer is simple: that will create a generic “parser error” message, which, yes, we can customize, but it’s best to keep those things simple. Parser errors are “under the hood,” so to speak, and we’ll be better off using our own code and feedback to handle people card-picking the wrong stuff. This is a good place for a check rule. Check rules are gates, essentially, permitting somethings while preventing others.

check card-picking:
	if the noun is not a tarot:
		say "That's not a card, silly!" instead.

By default, check rules don’t stop actions. Unless the action triggers our instead phrase, (if the noun is not a tarot), the action will continue without comment. That’s what we want, here! We can handle the actual act of picking a card with a carry out rule.

Since we’re just getting started, let’s set up a basic framework for printing varied responses.

carry out card-picking:
	say "[the relevant fortune]".

As you probably recall, the text in brackets is a substitution. In this case, our substitution doesn’t exist. There’s no such thing as “the relevant fortune” in our code. I’ll cook something up using a specific kind of definition.

to say the relevant fortune:
	say "My goodness! The [printed name of the noun]! This must be your lucky day."

This is mostly a placeholder for varied text. Even in this simple state, it allows for a bit of variation: the response will include our own printed name for the noun involved. This will prove handy if we decide to vary the printed names of cards. & we do! A design goal is varying all onscreen text. Here’s what that gets us:

>pick orange
My goodness! The orange card! This must be your lucky day.

>pick green
My goodness! The green card! This must be your lucky day.

>pick blue
My goodness! The blue card! This must be your lucky day.

what’s next.

This is a framework, but not an experience. At the moment, we have a room description, a table description, card names, and a response to picking cards. As I mentioned at the beginning of this post, we’re looking to have eight different texts, since a “cycle” consists of eight card-picking actions. Here’s some next steps for the project:

  • come up with a strategy for what text prints when (random, deterministic, etc). That is, if a player picks eight cat cards in a row, what should that experience be like?
  • devise simple method for varying text that we can use for multiple responses, descriptions, etc.
  • devise reasonable (maybe “simple” is asking too much) method for organizing printed text, allowing for easy proofreading and editing.
  • consider QOL needs for action input, minimizing player friction.
  • determine what happens when a cycle ends.

The title of this series is “Let’s WRITE IF,” but I haven’t talked about writing in this post. Think about this: the format determines what we can write, just as our writing dictates a format. This design is absolutely about setting up a method for us to write in a specific and hopefully interesting way. Form, as we said in the old MFA days, is inseparable from content. I hope the writing opportunities of this design will become clear as we continue.

current source

Categories: , , ,

Leave a comment