Four letter words.

I remember when you could abbreviate most verbs and nouns to the first 4 letters in IF. Why is this feature rare nowadays? Too fiddly to program or do people feel it detracts from immersive gameplay?

It’s only a small point really. Just that it would make input so much easier on my Android.

Actually, Scott Adams games typically matched to just three letters. Early Infocom games matched to six; when they went to the version-4 Z-machine (e.g. Trinity), it went to nine letters.

I’m quite sure that nobody regarded this as a feature; it was purely a matter of saving memory in the dictionary. When more memory became available, designers used more letters in game words. Typing effort was assumed to be too cheap to meter – which was pretty much true, up until the mobile era.

A modern mobile interpreter could auto-complete words based on the game dictionary, although this could conceivably be spoilery.

Thanks for the explanation. I would be happy with an auto-complete feature based on the phone’s internal dictionary, but Twisty hasn’t got quite that far yet.

iFrotz has an auto-complete, and it’s handy most of the time, but on some occasions it can be really frustrating. It autocompletes against a special dictionary of common IF terms, as far as I can tell, which is great, but sometimes if it wants to autocomplete something I don’t want autocompleted, or to a word I’m not looking for, I have to remember to tap the little “don’t autocomplete as this” X every single time I type it. If it’s a word that occurs a lot in the game, this can really drive me up the wall, especially since I’m terrible at remembering to do that (since I have the built-in autocomplete turned off). I think what would be ideal, for me, would be autocomplete that cascaded through a custom IF-related dictionary and then the system dictionary, but as soon as you overrode an autocomplete offering, would give precedence to the word you’d previously typed instead.

TADS games let you abbreviate words to their first six letters (while still considering any that follow as significant – so you can examine a cauldron by typing X CAULDR or X CAULDRO but not by typing X CAULD or X CAULDRI).

Unless the game’s author has changed it. It’s controlled by the library, not the interpreter, so it’s possible for the author to change the number of letters used for abbreviations or turn the feature off altogether.

I believe most MUDs (or actually MUD codebases) do the same, except abbreviating at four letters. Actually, I seem to recall MUDs I’ve played matching to the smallest unique combination. So X SWO (or actually L SWO, as the command would probably be in a MUD) would work for examining a sword unless another object beginning with “swo” were listed first in the room. (I think “SW” might be confused with the command to go southwest.)

I think that’s the most sensible approach, since the game always can ask to disambiguate when the player types ‘get swo’ and there is a sword and a swordfish on the floor.

I did regard this as a feature, although limiting the number of recognised letters is a kludgy way to achieve the benefit, because I shouldn’t have to remember how many letters a game recognises in order to type shortcuts. No, the best way to get the benefit is for the parser to select the single object (assuming there is only one) with a prefix exactly matching what I typed. So if I typed ‘get stat’ or ‘get cord’, either command would match ‘station cordon’ as long as there were no other objects around with names that start with ‘stat’ or ‘cord’ – in which case the ambiguity resolution routine is invoked. This is the way MUDs tend to work [EDIT: as mentioned above by bainespal et. al. – and I had not realised that TADS also resolves ambiguity in this way]. I must say this way has always felt superior to the many text adventures that have insisted I type a word to exactly the number of characters that the game has stored internally as a keyword, and no fewer. It seems an unnecessary level of discipline.


P.S. Note that LambdaMOO does this kind of word resolution only on nouns – never verbs, which need to be matched identically to one of the forms specified by the game designer, or not at all.

Eamon works this way as well, and will accept down to 1 letter, which is cool. While the player side of me would love to see something like this in Inform, my mind fries at the idea of working it out. I mean so much of Inform is about the engine deciding what the player is referring to. How would it cope if you only gave it 1 letter? I guess that by 3 letters, that’s already a much better lockon you’re offering it. I’d be happy to type a minimum of 3, but being asked to type 4 would make me outraged and indignant :slight_smile:

Making this kind of smart word-matching work in Inform will be difficult, just because word-matching is a low-level feature and hard to mess with.

The most obvious quick hack is to give a TOADSTONE synonyms of TOADSTON, TOADSTO, TOADST, TOADS, TOAD, etc. But this is not the desired outcome, because the parser treats all synonyms equally, so this will be fatally confused with a genuine TOAD.

You could get closer by including all of these shortened synonyms except those that directly match other game words. This would however be somewhat inconsistent to the player, because “X TOAD” would fail to match the TOADSTONE even if the actual TOAD has never been encountered. (And when you get into conditional matching and scope checks, you’re seriously impacting performance, plus the result is just differently inconsistent.)

That is unfortunate. In LambdaMOO, ‘toad’ matches ‘toadstone’ if there is no toad present. If there is a toad, then ‘toad’ matches ‘toad’; in the case of a perfect match, all imperfect matches (like ‘toadstone’) are automatically discarded. The correct algorithm for this is clear; it’s too bad it’s so difficult to achieve in i7. I wouldn’t attempt it by filling in every missed synonym manually, either. That way lies madness.


hrm … this kind of makes me think of that TwitComp (you know, it called for 140-char Twitter-size games in I7?). Perhaps someone clever could design a game that only NEEDED 4-letter commands …

But kidding aside, it’s bad when parsers misinterpret a perfectly reasonable input because they’re assuming you typed something else.

The disambiguation thing is particularly knuckle-worthy: I replayed the latest version of a certain well-programmed IF classic this week, and it has still got bugs differentiating similarly named items. I finally had to resort to taking all the similar items out of the room and dropping them out of sight, before the parser let me handle the one I wanted.

I experimented with Twisty and I do see the problem with typing commands on phones, though. Some of my friends who text at Mach 3 would have no problem with it, but I type kinda slow because the screen is very small, and I finally gave up playing games like Anchorhead and Curses on the ol’ Droid, because it’s just a lousy format for really deep games. (Besides, if you’re gonna play a game that requires you to take notes or draw a map, I see no point playing it on a pocket size device when you’re on the go, unless you also carry a notebook and have a hand free to write in it.) An iPad or Kindle, yes; a phone, no. Games with sparser text and shorter plots would probably be better. In fact, I would suggest to the Twisty masters that they should package the app with some more bite-sized fare.