Implementation Tips

Authoring General Design Discussions
1

I bet there’s probably a set of implementation tips somewhere already. Maybe the IF Wiki, or somebody’s blog?

On the chance that there isn’t, or on the chance that there’s still more to add, here’s a start. If anybody has more to add, I’ll update this post with it. If possible, I’d like to avoid the more subjective suggestions – the things that are more of a personal preference nature than an actual problem in implementation. I’ve avoided adding “beta-testing” as a line item, since that’s more for finding implementation problems rather than an implementation problem itself.

Try to avoid restricting actions that are nearly synonymous with the one you intended.
As an example, suppose there’s a book on a shelf, and by “pulling” it, a secret door will open. If the player pushes it, you need to say something other than just “it won’t move.” If the player tries to “get” it, that implies pulling. Don’t say “it’s fixed in place.” If the player tries to “move” it, same thing. Otherwise, you’re purposely building a guess-the-verb puzzle, and these rarely work. Many players will give up, believing that they’re not even trying the right thing. If you feel like a specific phrasing is really needed and other likely phrasings must be prevented, try re-thinking the puzzle, or at a minimum, allowing the wrong attempts to hint at the right one.

Use synonyms for everything
This can be tough when different regions or countries use words for things that other regions don’t, so it’s worth asking beta-testers to be on the lookout for those things in particular. Even aside from that, sometimes I just want to use the shortest word possible, or the one I tend to use casually for describing the same thing. If there is an “automobile” in your game, please be sure it can be called a “car” or a “truck” or whatever the case may be. Definitely allow synonyms for every noun you use to describe it in your text. But any others that come to mind as well. It isn’t fun to have to keep re-looking at a description to figure out what the author called something that you already know is there.

Add adjectives for everything
If you have a “big green cube” in your game, which when looked at says “the large cube is a dark viridian” then you need adjectives for big, green, large, dark, and viridian. This is especially important for disambiguation. You must have unique adjectives for every item that is both (a) something you can pick up and take with you, and (b) has a noun in common with any other item in the game, including other inventory items. Or more briefly, every item that can be in the same scope (probably the same room) as another item of the same name. Otherwise, you make it difficult or impossible for players to choose between them.

2

I’m really dilatory and distractable, so probably nobody should follow my tips if they want to produce a game this year. However, I do have something I feel is important to add to the advice on synonyms.

  • Don’t add any synonyms or alt adjectives to any nouns until your game is nearly finished. You might suddenly decide that you don’t need those nouns in the first place, or that all the ‘folders’ should be ‘sacks’.
  • Corollary: Don’t rush through through adding synonyms or adjectives at the end because you are so nearly finished. Consider every single noun in turn. Scour your descriptions for unimplemented physical nouns. Until you do this in as painstaking a way as an artist with a brush, your game is still just a sketch.
3

Every physical noun in every room description should be implemented as an object (or a synonym of a related object) and have at least a cursory description in response to EXAMINE. This includes the player. (edit: Okay, Laroquod beat me to this, but it’s important!)

Every new noun referenced in an object’s EXAMINE text should also be implemented, either as a synonym of the original object or as its own object.

The viable directions out of a room should be clearly stated, either within the room description or as a separate sentence afterward.

“You can’t go that way” is not a helpful message. Going in the wrong direction should present a helpful reminder about which directions you actually can go.

4

If you indicate to the player that they could do something, make sure the wording you use also works as a commmand! For example, if there’s a piece of paper stuck under large furniture and trying to take it results in “It’s stuck under the bookcase but you could rip it out”, make >RIP PAPER [OUT] a synonym for >PULL PAPER. If the suggestion is too complex to reasonably implement as a command (“It’s stuck but it might come loose if you gave it a good yank”) modify the prose to use a more simple structure (“It’s stuck but it might come loose if you yank(/pull) it.”)

5

Implementation sends a message to the player about what you think is important. If you have many scenery items with lavish descriptions and multi-level details, you’re sending a signal to the player that you want them to slow down, smell the roses and look closely at everything. If you have relatively short descriptions, fewer scenery items and no second-level details, you’re encouraging the player to move more quickly and be more goal-oriented. The depth of implementation that you choose helps determine the pace and mood of the game.

Similarly, if you implement a room or an object in greater depth than is usual in the rest of the game, you’re telling the player that it’s important, and they should pay more attention to it. (‘Important’ could mean ‘an element of a puzzle’, but it might also be important to characterisation, plot, atmosphere, sense of place and so forth.) If you avoid implementing it (by, e.g., making it a synonym of another object) or implement it lightly, you’re telling them that it doesn’t really matter too much and they should direct their attention elsewhere. If it’s really unimportant, consider not mentioning it and leaving it unimplemented. You don’t need to add a bathroom to every house.

Realism is never a reason on its own. When you’re asking yourself ‘why am I including this?’, ‘because it’s realistic’ is not a useful answer. There are far, far too many aspects of reality for you to implement them all. (As an exercise, try implementing every single individual item in the room you’re in now.) All games, and all stories, focus on some aspects of reality over others.

Since you’re going to have to prioritise, you should have some reason, some purpose, for everything that you decide to include. (That sounds kind of intimidating, but they don’t have to be big reasons.) If you know what those purposes are, you’ll do a better job of crafting your content to fit them.

6

Avoid repetitive tasks or make them skippable when performed once or twice. If you have to i.e. unlock a door, open it, enter the next room, close and lock it again because of a wandering killer NPC, and need to do it every time to escape the same NPC, make it so the first time you have to actually lock the door, while on later attempts it goes automatic.

(This may be old style and rather personal, but:) Avoid putting 20 useful items in the same sack or room. They can be all useful, partly useful or (as I usually tend to believe) completely useless. Discard your objects wisely.

(IMO) Useless rooms are ok, as long as 90% of your game is not made of empty, scenery rooms. Keep it simple. But don’t forget the landscape :slight_smile:
[Edited to add]. A room should be there if there is some description appended. Making passageways that just say “you can go north, south etc” are not that useful, both to gameplay (useless room) and to the story. So, if a room’s description is made only of its exits, you can grant it is useless and remove it.

Always think in 5 senses. For the sake of realism, at a very cheap cost but with a really nice outcome, one should be able to SMELL in a smelly room, or LISTEN in a noisy one. Don’t make EXAMINE the only living verb in the game.

[Edited to add] for overachievers (like me): sometimes it is useful to have a look at the index tab/actions (Inform7 only) to list all of the verbs. A lot of new ideas for good responses come from that list. I.e.: you are on a boat: no use for the verb DANCE, but what about JUMP/DRINK/LOOK UNDER?

7

I’m not sure whether these are really implementation tips, but here are some things I’ve noticed from my recent IfComp inspired binge:

  • Don’t implement things like you don’t care about them. The message about not having “You see nothing special about the …” seems to have got through, but I quite often come across descriptions that amount to the same thing. They scream “This is a boring thing that I am going through the motions of implementing.” Typical examples: “It’s just and ordinary widget.” “The widget is large.” “It’s a regular widget.” Solution: maybe you don’t need this widget at all. Solution 2: think about something other than what it looks like – why it’s there, how it makes me feel, and so on. If you find yourself writing about colour or size, think whether this is actually worthwhile.
  • Please don’t make me have to answer endless disambiguation questions. If you must give me an iron key, a brass key, a bronze key, a large key, a skeleton key, a small silver key, a large silver key and a square key, please make sure that doors are automatic.
  • Because of both the previous points, be very wary of making places which consist of many similar items, mostly unimportant: libraries, kitchens, shops. You hate making them, and I don’t enjoy spending much time in them.
  • One or two interesting places, people or things are worth many boring ones.
  • Remember that I spend most of my time doing the wrong thing. A game that only rewards correct actions is going to get annoying. Rewarding near-misses and outright failures, and acknowledging the things that we as players do in frustration, is also important.
  • Remember that most of the best IF is not just about a simulated space, but about the things that happen there (understanding “happen” broadly). It’s action (whether triggered by the player or generated by you) and friction (whether from characters or puzzles) that bring your world alive. Worry first and most about them, and only secondarily about the setting.
  • Writing matters. If your writing is weak, work at it. At the very least give us what any professional can deliver: correct, properly spelled, properly punctuated prose (but aim higher).
8

If you’re adding a new action to your game or customising an existing action, here are some things to think about/test.

What happens if the player uses the action on:

  • something similar to but not quite the same as the intended object(s)?
  • himself/herself?
  • NPCs?
  • things belonging to any new classes you’ve created?
  • directions? (in Inform at least, directions are literal objects that are in scope, but not things, which can lead to subtle bugs)
  • breakable things?
  • things s/he is carrying/wearing?
  • things s/he is not carrying?
  • things an NPC is carrying/wearing/guarding?
  • things that are fixed in place?
  • things that are portable?
  • things that are out of reach?
  • things that are not tangible, e.g. a smell?
  • a tiny thing?
  • a huge thing?

What about using the action:

  • with the same object as both noun and second noun (i.e. using something on itself?)
  • in an indoor room?
  • in an outdoor room?
  • in a non-standard room, e.g. up a tree, or in a swimming pool, or on a boat?
  • when the player is in/on an enterable thing?
  • in the presence of an NPC?

Obviously these are not all going to apply to every game, and you wouldn’t want to implement custom responses in every situation even if they did! But it’s a good idea to think about them, and any other unusual situations that might come up in your game, and make sure your default responses don’t assume anything about the object or situation that might not always be true. And if something might be a genuine attempt by the player to solve a puzzle or move the story along, add a custom response letting them know that’s not right, and gently hinting what might work instead.

9

Dan Shiovitz’s Think Like A Player is worth re-reading. (And it links to Stephen Granade’s The Player Will Get It Wrong, which should also be engraved on every author’s heart.)

There’s also far, far more discussion about The Dreaded M-Word at ifWiki’s list of old rec.arts.int-fiction topics than anyone could ever desire. (Mimesis has fallen out of fashion as a game design ideal, partly because it was so heavily used from about 1996-2002 that everybody got sick of the word, and partly because the word encapsulates an ideal of total, indiscriminate realism that most authors have decided isn’t all that useful. But a lot of useful discussion took place around the term, and it’s worth going over.)

10

Also, something that Emily repeats a lot, though I can’t find a specific instance off-hand: if there’s something that you absolutely need the player to know, you need to put it where they stand absolutely no chance of missing it. If the player can’t understand something crucial without digging around in optional content, it’s your fault when they fail to understand it.

11

Actually I think it might be OK if trying to push it does say “It won’t move”; but trying to move it ought to work (or at least respond “Which way?” or something). Trying to get it should work too (if it is stuck, it should probably tell you that, but still try to pull it too).

12

It’s easy to forget about all the stuff an IF language already does for you, especially during the early stages of learning it. Using Hugo as an example, there are quite a few grammar definitions that you normally wouldn’t think of or even need to use in a game, but the mere fact that they exist means there’s a good chance of misleading “you can’t do that” kinds of messages for things that you actually can do – if done another way. For example:

It becomes more than just trying to predict what the player will try. It means understanding the game’s supported grammar and how it might apply to the “thing” you expect the player to do. And beyond that, being able to extend the grammar as much as you can, so that things it can’t do by default are covered too. At least, in Hugo.

But that kind of strays from the original point, which takes less effort. If you know what’s possible, it usually isn’t a good idea to ignore how it might apply to the situation, simply because you want the player to go for one very specific version of the action. That isn’t to say something like that is never justified – maybe it is, depending on the game – just that most of the time, there is no reason other than inadequate implementation.

13

That is one reason why intend (and suggest to other people) to design the library to be very minimal, and any actions you want must be explicitly programmed in (the other reason is to make a smaller file size and more efficient).

14

My favorite example for this sort of thing is the ladder in “The Meteor, the Stone, and a Long Glass of Sherbet.” If you haven’t played it, there’s a ladder leading from the ground to the bottom branches of a tree. You climb the ladder, then take it and use it as a bridge to get to another area.

It accepts all sorts of verbs to use it as a bridge, but when I tried to put it back in its original place (as a ladder) nothing would work. Eventually I consulted the walkthrough and found the command “hang ladder” would work.

At first I thought this was a ridiculous guess-the-verb puzzle, but then I realized I couldn’t think of any better verbs to use. I had been trying things like “drop ladder” and assuming the game would figure out what I wanted, but I couldn’t think of a way to explicitly say what I wanted. So now I always try to think of at least three synonyms for what the player will need to do, and implement all of them. If I can’t, I try to imply the correct wording somehow.

15

What I’d like to add:
Think about what happens, if the player tries your new action a second (and third and fourth…) time after a successful try and (IMHO less important, but nonetheless sometimes interesting) a second time after an unsuccessful try.