One tester's game polish tips for parser authors

[johnnywz00 (John Ziegler)]

Hello parser-making friends! Until a few short months ago, I had never tested another author’s game, but since that time I have partially or completely tested some ten or twelve games. In the course of doing so, several recurring themes have emerged, so I figured it might be of some help to publish them so that authors may be able to apply them during the course of game creation.

My suggestions are concerned mainly with some elements of what I consider to give a game a higher degree of polish. Perhaps some of them will be considered overkill or too much work for a given game. But I think a general awareness of these principles won’t be amiss…

• Provide default responses for every NPC, covering every conversational verb. TalkTo, GiveTo, ShowTo, AskAbout, TellAbout, AskFor, “actor, hello/goodbye”, “actor, do command”.
  If it’s a very prominent NPC I suggest that each verb has a unique default. "Igor doesn’t feel disposed to answer your question. " "Igor manifests no interest in what you are telling him. " Even better if the default cycles through a few different wordings. If the NPC plays only a small role, it’s okay to catch multiple verbs with the same message, but just don’t leave the default as "There is no reply. " (sounds unimplemented)

• "You can’t go that way. " If it’s not already obvious from the room description, tell us why we can’t go that way! In a given location, three directions might be implausible because the protagonist would be abandoning the mission, two might be implausible because of obvious physical impediments, and one might be a water body that we could swim but it’s just really not the time for swimming. That’s a really bad location to report “You can’t go that way” for every direction except the road to the north. For locations with very prominent or compelling reasons to not go in a particular direction, give that direction a unique cantGo message. But otherwise rooms that aren’t obviously boxed off with the exits listed should have a customized default cantGo, that catches anything not more specifically defined: at the very least it can say "It only makes sense to head down the road to the north at this point. "

• Untakeable objects: default cantTake/cantMove messages! It’s really detrimental to the atmosphere to try to take a lightweight chair or the shards of a broken urn and be told “It is fixed in place.” Specifically, customize the cantTake/cantMove messages for all objects that are motivationally disallowed or else not impossible but impractical. In TADS3 this is quite simple, as there are separate classes for objects that are actually fixed and those that are not practically movable, but this distinction doesn’t seem to be made in the Inform standard library. If you don’t care to customize all of your applicable cantTake/Move messages, at least customize the game-wide default to something noncommittal like “You won’t be taking the object” instead of “It is fixed in place.”

• It’s understandable that an author doesn’t want to make every object in their game a Container. But if you aren’t going to allow containment functionality, at least be conscious of whether containment is logical for the object in question, and provide a custom cantPutIn message. If a player tries to put the cup in the cabinet, they shouldn’t be told “That can’t contain things.”

• For objects that are described as plurals, always include the singular form in your vocab. Mimesis-breaking to enter “x paintings” and get a lovely description, then “take painting” and be told “You see no painting here.” While on the subject of vocab, include every form you can think of. Just because you carefully called it a “bookshelf” in your description doesn’t mean someone won’t type “book shelf” or “book-shelf” or “shelving”. The more you cover, the less ground a player will have for associating frustration or annoyance with your game.
  And include both British and US spellings!

• Also make sure all plural objects are programmatically marked as plural. Otherwise the player will see “The guard dogs isn’t here.”

• Other default verb messages as yet undiscussed: you’ve put this much effort into your game, go a little further and put the defaults in your own words. Many times you can tailor the message a little bit more to your PC or the general atmosphere, and banishing library messages from a game is almost always a step in the right direction. Most players would rather hear “Quarbucchio isn't interested in sitting anywhere less comfortable than a recliner” than “The front desk is not something that you can sit down on”.

• PITFALL: be careful when awarding points, that it is impossible for the player to repeat the action and score the points again! I’ve run into this twice in the last week. Some puzzles take care of this unintentionally, because the obstacle or the foe disappears, but if it’s something like picking a lock, make sure that the player can’t pick the lock again right after they’ve opened it. Or, if they can re-lock and re-pick it, make sure the points and the celebration only happen once.

INFORM:

• the parser should be able to recognize input beginning with * as a comment
• use Wade/@severedhand’s menu extension. When testers access in-game hints with a transcript on, the standard setup clutters the transcript with huge chunks of repetitive and unnecessary hint menu text.

That’s all for now! Thanks for listening!

[mathbrush (Brian Rushton)]

I don’t like these tips because they’re a lot of work but I opened up my game file to add more specific “can’t go that way” messages. thank you.

[rovarsson]

John Ziegler (aka @johnnywz00 ) is forever banned from the Testers’ Guild for revealing Secrets of the Testing Craft.

However much we Testers may run into these same issues, we choose to keep them under our caps to preserve our dignified privilege to feel superior to mere scribblers (or “authors”, as they pitifully call themselves).

Satisfaction from executing our Craft lies for a great part in smugly asserting that the scribbler overlooked a simple unfillable container or an unpassable passage.

In grave violation of our prerogative to feel better than others while letting those others do the heavy lifting, John Ziegler has given mere scribblers a heads-up that will allow said scribblers to pre-empt the staple errors the Testers’ Guild thrives on.

We decided this in a Secret Meeting behind John’s back. Nah!

[johnnywz00 (John Ziegler)]

Oh man, what have I done…

[Zed (Zed Lopez)]

Of related interest:

Checklist for authors of IF and Inform 7 IF in particular

Just as a thing, I have a base template for an object, and I create one and complete it for EVERY noun in the game : todo is a thing in todo. It is scenery. The description of it is "TODO.". Understand "todo" as the todo. Instead of doing something other than examining with the todo: say "todo.". I find it’s a good habit to get into to copy this super basic template any time I create an object that isn’t useful but still needs some love and attention.

[kamineko (Drew Cook)]

I get and even agree with these suggestions, but I do wonder sometimes how much time an Imp spends readying things for the one or two players out to troll the parser.

I also wonder if it can be tempting to focus on these inarguable binaries over qualitative testing or interpretation of the text. It’s very comfortable to discuss whether or not a mentioned noun is implemented, since there is no judgement or subjective reaction to contend with.

This is not a dismissal at all. If there are any default responses left in my game, then they have slipped past quite a few testers. I’ve tried my best to do all this stuff.

Though I must have borked Wade’s extension, because my implementation of it turns up in the transcript.

[AmandaB]

@johnnywz00

"You can’t go that way. "

This has never bothered me. If the available exits are clearly stated, then I can’t go that way because there’s no exit there. Outside locations are a tad different. If there’s a river to the south, I should get a response for going south that I can’t swim, or I don’t want to get wet. But this is something I can’t get worked up about.

[johnnywz00 (John Ziegler)]

Just a few remarks, Drew @kamineko…
When I test, I typically do try to break the game and “fool” the parser, as it were, and I will put a flag there if I find something incongruous. I realize in those cases, that those things will probably never be seen except by the parser trolls that you mention, but it only takes a second to flag, and I do it for the author’s benefit, knowing that they can choose which of my comments to act on or ignore as they see fit.

But I don’t think any of the points I put in the article are things that only a parser troll will see. I think players giving honest effort have the potential to see all of the situations above, and the potential to notice a jar in the rhythm because of them.

Also I tried to preface the article by saying that the elements mentioned were not issues that determine whether a game stands or falls, but elements that I thought gave a game an extra degree of polish. And that authors can make their own determination of which elements they find worth the time to implement for their game.

I should add a PS here, that I have mentioned these things with a TADS3-only understanding of how to implement them, and from my background they are quite trivial additions to the codebase. I have since been apprised that it isn’t quite as straightforward to define custom strings on a per-instance basis in I7, so I honestly don’t know what the amount of effort looks like there.

And I also don’t intend for my suggestions to supplant concentration on text interpretation, game design, and other overarching qualities involved in a work of IF. They are just meant to address what they are addressing, in addition to other existing considerations, because I happened to notice the pattern and thought that active authors may get some good out of applying them now, rather than being called out on some or all of them by members of the Testers’ Guild (@rovarsson).

The article was meant for authors’ benefit, not to be a credo or dogma to pass judgment on authors that are already sweating to put in their best efforts!
I apologize if anyone took it differently than intended, and if it makes any difference, I try to live up to the same standards in my own work…

[johnnywz00 (John Ziegler)]

@AmandaB , I should clarify. If you’re clearly in a walled room, and you’re told that there are doors to the north and the west, I am not passing condemnation on an author for failing to customize NORTHWEST to say “You bonk into the corner of the room that way”! (But kudos to those who want to.) It’s the (rather many, to be frank) locations where as an adventurer, you would love to see what is this way or that way, but aside from the fact that the author has explicitly mentioned something interesting to the northeast, you have no idea why you’re being told “You can’t go that way.” I confess that to me, that just has an unimplemented look. I feel like a customized message there can immediately enrich and even broaden the feeling of the game world. I think it would be an improvement even if the game-wide cantGo message was changed from the stark “You can’t go that way” to something like “It’s best to follow one of the suggested directions”, with an optional exit listing being printed.

[kamineko (Drew Cook)]

Sure, John. I’m talking about general phenomena in testing, just like you’re talking about general practices in testing. Since we are talking about binaries, though, there’s no line, not really, where one can say something is too much. The switch is either on or off. If I have sinks and a toilet in my game, I have to account for people putting things in them. Not because it will advance the story, but because they are in the game, and they could hold things.

There’s nothing mimetic about putting things in a toilet, but it has to be accounted for. There’s a moon in the sky, so there needs to be custom responses for that, and so forth.

As I said, I don’t disagree with your suggestions, I’ve followed them all myself. But I do think that a lot of responses in my game will never be seen, unless someone is deliberately trying to poke holes in it. I tried to amuse myself with the responses, which helps, but I like people to read what I write.

I think you and I are outliers, though, in that we’ve spent more than a year apiece on our games. That’s right, isn’t it? I’d be surprised if the average dev time here was six months. We’ve had a lot of time to do this detail work that others may not have had.

But again, not disagreeing with you. I hope ST players find things I missed. I’ll fix them.

[severedhand]

@kamineko

Though I must have borked Wade’s extension, because my implementation of it turns up in the transcript.

No, you haven’t done anything wrong; it turns up in the transcript, but pretty insignificantly compared to what @johnnywz00 is referring to.

The old, original Menus extension has this up/down/in/out arrow key navigation system where every single time you move the cursor, the screen is reprinted. So as the player moves the cursor down to item four of the first menu, you get four identical printouts of the first screen of menu options in a row. This adds up massively, quickly, and then you tear your hair out. This was one of my motivations to redo a Menus extension.

-Wade

[johnnywz00 (John Ziegler)]

@kamineko

I think you and I are outliers, though, in that we’ve spent more than a year apiece on our games. That’s right, isn’t it?

I’ll hit the four-year mark in June, and I don’t expect to be finished before then, although it may be right around that time…

@kamineko

But I do think that a lot of responses in my game will never be seen

I don’t think I’d want to be told the number of life-hours I’ve spent typing things that will never end up being seen or noticed by mortal eye…

[Warrigal (Garry Francis)]

I enjoyed reading this article and I think it’s generally very good advice, both for authors and for testers.

I have mixed feelings about the cant_go recommendation. I will provide a string to explain why you can’t go in a certain direction when it’s appropriate, but I’m not about to add a custom string for cant_go in every location, especially when up and down need to be catered for.

One thing that I have been doing in recent games is telling players that there are no diagonal directions in a game if they enter NE, SE, SW or NW and there are no diagonal directions in the game. By doing so, they know not to waste time trying every diagonal direction in every room.

I particularly commend you on suggesting that containers and supporters should be implemented as such, even if they aren’t important to the game.

One thing that you didn’t mention is that you should account for different spelling in different countries, e.g. if you have a ‘tire around the center post’ (in American), don’t forget to have a synonym for ‘tyre’ and ‘centre’ (for UK and Australian English). I often get tripped up by this with American authors.

[fos1]

Games should be “played” not “shotgunned”.

[kamineko (Drew Cook)]

Nice. It was the screen reader mode that pulled me in, but this is great news.

[pinkunz]

@Warrigal

One thing that you didn’t mention is that you should account for different spelling in different countries, e.g. if you have a ‘tire around the center post’ (in American), don’t forget to have a synonym for ‘tyre’ and ‘centre’ (for UK and Australian English). I often get tripped up by this with American authors.

Is there a semi-exhaustive list for these variations? Like I know many of the common ones, but I’m sure there are plenty I miss.

[johnnywz00 (John Ziegler)]

@Warrigal Aha! I was fully intending to add the British/American spelling variants in my vocab paragraph, and then it slipped my mind… thanks for the nudge! I’ll edit the original post for the benefit of any future readers.

I’m not sure if my shelteredness of having learned programming through TADS has maybe created expectations that seem unrealistic.
For one, you can handle specific directions differently from the rest. That is to say, in T3 you can define UP to return “There’s no plausible way to go up here” for every room game-wide except those locations where you have defined a specific UP response. Same with down, in, and out: they can all have their own game-wide response (and diagonal too if you want it). So you don’t have to cater for any of those directions when you add custom cantGo strings to rooms.
(Not sure if you saw my follow up to AmandaB, but I wasn’t saying that every room needs a custom string, even if it’s walled with clearly listed exits. It’s primarily for outdoor locations, where travel is plausible but the author doesn’t have anything for the player to do that way.)
I’m still in favor of specific messages for specific directions when there is a poignant reason for being unable to travel that way, but let’s just say you’re in a forest with paths described as leading south and northeast, then I’m just saying the game loc looks better with a (compass-directional) catch all string that says “You could easily get lost in the forest if you leave the path” than “You can’t go that way”.
In T3 it’s only the addition of one string to your room code:

forestLoc5: OutdoorRoom 
   [room stuff]
   northeast = forestLoc6
   south = forestLoc4
      // this is all you need to add v v
   cantGo = ‘It would be easy to get lost etc’
;

[mathbrush (Brian Rushton)]

I think it really comes down to the fact that you’re writing and testing very large games with both indoor and outdoor areas, where the responses don’t make sense.

For instance, one of the sections I just went and fixed after your suggestion was a part of my game where you are on a beach with a river to the west, more beach north and south, forest to the northeast and southeast, and a gate to the east. I currently had a generic message for all of those, and I agree that doesn’t make much sense.

But a ton of games are smaller and have like ten indoor rooms (like most of the punyjam games, although many of those had water rooms with special messages), in which case I think it’s not worth having a specific message for each room. So I think that in the context you were working in of large mixed indoor/outdoor games, your statement makes complete sense, but given the wild variety of games being made, it may not always be necessary.

[johnnywz00 (John Ziegler)]

@mathbrush

it may not always be necessary.

You’re right, Brian, that’s why I tried to preface the article with the line that says authors can determine for their own game which elements are worth the time to implement…

[kamineko (Drew Cook)]

I almost always did a single instead of going nowhere rule for each room, which I’d use to restate the exits. Really, my purpose was just to spare the player the trouble of having to look. I was more granular in a couple of places, I think.