top expert

Making a game our own.

last time, on let’s make IF…

We are getting closer to a workable template that–let’s hope–anyone can fill in with their own content. In my last post, I reviewed several changes related to printing text based on systems we had already come up with: taking text from tables and printing based on a value (the so-called “magic number”), sometimes in concert with a player’s choice of noun. Hopefully by now, these procedures seem pretty familiar! In this project, I’ve tried to focus on a few core techniques that we can use to produce varied results. Catch up here:

let’s write IF #13: further framings

What remains (I think) is some customization: limiting acceptable commands and tweaking default action responses and error messages.

customizing standard responses.

From time to time, I bring up the Standard Rules as an asset to people like us who are learning about Inform, whether we started yesterday or two years ago. It contains very nearly everything needed to compile a game file. If we declare a location, for instance…

lab is a room.

…we have a working game program. There’s not a lot to do there, naturally, but we have many catch-all guidelines and responses for actions–we can start writing our content right away! We’ve been doing just that: setting up actions and action responses that will make up the experience of our project.

But what about everything else? Inform 7 has 77 verbs built into it, and several error messages (responses to flawed input) besides. The messages included with the Standard Rules work fine, and will almost always make sense to players, but they won’t sound like our own narrative voice. To truly make a game our own, we will need to explore these messages and change anything that doesn’t seem to fit. There are two basic, high-level categories we should consider:

• Parser errors: these messages are printed before Inform attempts to act upon the player’s command. That is, they are printed by the parser, Inform’s mysterious shadow world that we don’t touch or control. Unlike the action responses we’ve written in the past, where we have the power to manipulate the world and its clock, there is very little we can do to manipulate what happens when parser errors print.
  • Because of our limited control over the situation, we must take care that parser errors make sense in every imaginable situation where they might apply.
  • We can use some conditional text, i.e., [if the apple is red], but in some cases we are limited. The parser may not yet know what the [noun] is, for instance.
  • Tone is an important consideration. Players will get annoyed by repetitive snark, especially if the problem is on the author’s end. For instance, audiences may bounce hard off of a game that mocks the player for trying to interact with nouns that aren’t there when they are mentioned in room descriptions 💀
• Action responses: these messages are similar to ones we’ve written in the past. The difference is that these are fixed, canned responses.
  • Unlike parser errors, we have a lot of flexibility when it comes to action responses. We can change the game world. We can use elaborate conditions.
  • Tone remains an important consideration. In general, rejection messages require a light touch, especially if there’s a chance that the player is trying to do something reasonable. Try to find that balance between your voice and player expectation. It is a very hard goal, but in an ideal game every reasonable command will receive a reasonable response.

Not too long ago, I shared a link to my Default Responses Template. It’s a list of every response message in the Standard Rules. We could open it up and get started, but let’s narrow things down a bit. We’ve talked about kinds of things and kinds of values. Did you know that there can be kinds of actions, too? Since this a game with only four productive actions, we can create a kind that only applies to actions that will work in our game. Unlike declaring kinds of values or actions, we just jump right in with an action and the name for our kind.

card-picking is performing a productive action.
looking is performing a productive action.
choosing an orange card is performing a productive action.
choosing a red card is performing a productive action.
choosing a yellow card is performing a productive action.
choosing a blue card is performing a productive action.

I prefer long, readable names, but you can call your kind almost anything. Here’s what my rule looks like:

before doing something:
	unless performing a productive action:
		say "That's not productive!" instead.

Lots of Standard Rules responses happen at Check and Instead phases. To get ahead of them, I’ve made a Before rule. You may wonder: why did I include looking? Remember that we’re talking about actions here, and not commands. Even if the player never types the commands “look” or “l”, the looking action occurs regularly. We have to be careful with “big” rules that cover so many conditions at once to make sure we aren’t accidentally excluding something important!

Of course, with a rule so strict, there aren’t many action responses that require attention. They’re all stopped before they can happen! We probably don’t want to go so far. Curious players will want to examine what little there is to examine, for instance, and they’d likely resent it if we stopped them from doing so. This is another balancing act: trying to provide reasonable responses while managing the scope of play. What else might we include? Inventory, probably, and maybe a few others. We should wade through the list of responses and see what might make sense.

Default Reponses Template (Inform 7) by Drew Cook

My advice is to copy everything into the bottom of your project, then work your way through it. Start with the parser errors first, since that will buy you time to think about which actions you want to permit in your game. Rewriting the messages is easy. Simply replace the quoted text. The template explains when specific parser errors displayed. For instance:

[the most familiar of all these responses, perhaps. Prints when the player's command refers to a noun that is not visible or in scope. or else the noun (or a typo) does not exist anywhere in the game. Be careful with snark.]

The parser error internal rule response (E) is "[We] [can't] see any such thing.".

can be updated to

The parser error internal rule response (E) is "There's nothing like that here".

In this way, we can make the text our own. Note that we aren’t doing anything irrevocable. If we delete the line from our project, the response from the Standard Rules will print instead, so don’t be afraid to experiment! Just test often and pay attention to tone.

It would be a waste of time to write custom responses for actions that don’t work, obviously, so once we’ve decided what to leave in our game, we can begin customizing action responses. My advice is to prioritize common actions that testers will expect. Or that they will enjoy. Perhaps they would laugh at a response to jumping, for instance.

Remember to designate any new actions you have decided to make possible (“performing a productive action” in my example).

performing a productive action.
The report jumping rule response (A) is "Stop being silly.".

I need a little time to consider how I’ll update our shared source code, so stay tuned some updated source later in the week.

next.

We’re getting there! Let’s talk about playtesting next time.