In Bocfel, I automatically expand x, g, and z if they are the first character of input. The implementation was always pretty lame and ham-fisted (including not checking whether “examine”, etc. were even in the dictionary), and I’ve finally been called out on it by a player of German games (https://code.google.com/p/bocfel/issues/detail?id=4).
The “obviously correct” solution is to turn off expansions unless the user asks for them. However, I’m reluctant to do this because the largest user base of Bocfel by far comes via Gargoyle, whose users won’t necessarily know what Bocfel is, let alone how to configure it. Thus I’d like to provide the best experience by default, which means abbreviations work as expected in older games, but do not break anything.
Ultimately it’s a balancing act: I want to make things as comfortable as possible for most users without ruining the experience for others.
I’m looking for feedback on a proposed solution. I’m not familiar enough with most games out there to be able to see something that would clearly be a problem, as can be seen by my lack of foresight on abbreviations in non-English games. If there is something in the following that would be an obvious problem, I’d like to know.
Proposed steps for expansion:
If the game is V5+, don’t do any expansion.
[list][]V5+ Infocom games include the expansions, and of course Inform games do, too; Infocom V4 games are hit and miss.
[/:m]
[]If the last token was a separator and a full stop (or this is the first token), continue with abbreviation expansion.[/:m]
[]If this is an abbreviation, look up the replacement in the dictionary (e.g. look up “examine” if the abbrevation was “x”).[/:m]
[]If the replacement does not exist in the dictionary, process the abbreviation as a normal word; otherwise, use the replacement.[/:m][/list:u]
This only has a chance of breaking V1-4 games, the vast majority of which are Infocom games, to my knowledge. Are there any clear problems with Infocom games that would be created by the above proposal?
My own solution is simply they are programmed in the configuration file. Each game can have a separate configuration file that overrides the global file.
Currently in my program the configuration file doesn’t have conditions for the compiler info, serial number, game version number, etc, although I could add them. You, too, could add such thing into your program if you find it useful.
Note that Inform and Zilch aren’t the only two compilers for Z-machine games. (However, ZAPF fills the compiler info in with “ZAPF”, while Frolg fills it in with “Fr” and the version number in binary, and Zilch just puts null bytes there, and I don’t know of others; however, I am guessing that anything written with the newer compilers will usually have the abbreviated verbs built-in. Such thing in your interpreter should still be a user option though.)
I do not like having a list of games internally to the program; they should be external. (You can make them internal if you want to, but I won’t. And if you do make them internal, please provide an option to disable the internal list of serial numbers.)
Cas, are you able to get settings from garglk.ini? If you could then a generic expansion setting could be turned on, with game specific exceptions, using Gargoyle’s natural override system.
garglk.ini can be used to pass arguments to the interpreters, which could be used to selectively enable/disable abbreviations on a per-game basis. However, it still relies on a properly-configured garglk.ini, and unlike the Bocfel configuration, it works on filenames, not serial numbers, so has more of a chance of failure.
I agree with you in principle, zzo38: I dislike the idea of internalizing a white/blacklist (checking the serial number and/or what’s at 0x3c), but from a practical standpoint I think it’s the best way to provide the best user experience in all cases. I will certainly keep the option to disable the expansion of abbreviations and thus any white/blacklist checking.
Thanks for all of the input; given the existence of the Infocom fact sheet, gathering serial numbers for V1-4 Infocom games will be trivial, and combined with the steps listed above, should create a very low chance of expansions leaking out of the small area I want them in.