After reading the recent newbie thread, I agree that LOOK rather than “I beg your pardon” seems most sensible. It’s also a win for the author, as it’s one less message to customize.
Maga, I still have a half-finished modern version of Custom Library Messages on my hard drive, so if you’d like me to canonize your weasel-herding into a CLM extension, I’d be happy to do so.
I’ve already integrated a few of Aaron’s extensions into the next Textfyre game. (With his permission, of course.)
I’d love to see an extension that bundled up a big bunch of novice mode helpers. I have two concerns. First, it needs to be author-customizable to a high degree, in case the author needs or wants to do something that would conflict with it. Second, I’m a little hazy about exactly what such an extension would do.
Correcting obvious spelling errors if possible.
Responding to complete gibberish (such as the player typing ‘what do I need to do here?’) with a friendly all-purpose message.
Silently (or with a printed-out suggestion) stripping ‘please’ and ‘I want to’ from the beginning of inputs.
What else?
In the past I’ve included a big slab of ‘here’s how to play IF’ text in my games, but I’m starting to think that’s not as friendly as it ought to be. One way to make it easier to read would be by implementing ‘help with commands/input’, ‘help with travel/navigation/movement/going’, ‘help with handling/manipulating/using/- objects/things’, and so forth as separate commands leading to separate short tutorials. But that only works if the player knows what to type in order to find the help topic.
–JA
Yeah, I’m assuming more something like making >NOUN default to >X NOUN without further fanciness, (although I’ve been warned that this might be risky too), but since this is very much Aaron’s bailiwick I thought I’d look at his approach first.
I considered Tutorial Mode, but it’s intrusive enough on player experience that I’m not sure that everybody would want to include it. The aim is to include mostly features that an experienced player will never notice are there.
Possibly, although I don’t know how much that would encourage people to actually use it. And in some cases it might be more efficient to combine things to make them play nicely together, or for efficiency purposes.
This feels like the best option, I agree.
At the point where I have it all straightened out, that would be a fine idea; I started out by just going through the list and bracketing everything that wasn’t bracketed, but there are special cases (‘I only understood you as far as wanting to’) that aren’t amenable to this kind of brute-force approach.
One of the things I was thinking about was allowing the player to dismiss all these features with a NOVICE OFF command, although (hopefully) it wouldn’t be intrusive enough that this would ever really be necessary for an experienced player. But if that functionality could be put in (and I’m not sure how easy it would be, for certain elements) then it would be relatively simple to allow an author to grab the omnibus and then switch off individual features by means of simple Use-like statements.
Here’s another suggestion:
Assistance-requesting is an action out of world applying to (oh, whatever the correct syntax is for text). Understand “who [text]”, “how [text]”, “what [text]”, and “where [text]” as assistance-requesting.
My suspicion is that a lot of novices may type ‘how do I find the sword?’ and such things. Intercepting all inputs that start with query-words and providing guidance, such as “For help with commands, type ‘help with commands’.” would be useful.
–JA
Good idea, but I think Aaron Reed’s Smarter Parser does a lot of this already. There may be additional cases that could be added to augment the ones that are already there – his extension is very extensible.
It would probably be sufficient to set the Keyword Interface “use keyword highlighting”, “use topic highlighting”, and “use location highlighting” options to off, as well as suppressing the opening selection screen. At that point, it would be effectively a drop-in keyword examination extension. Then if an author wanted more, they’d have the full extension right there to work with.
There were two things I found that bite you with the single-keyword examination technique, whether you use Aaron’s extension or roll your own:
The first problem hits if you have a noun like “drill”, and also an action “drill [something]” with which you’d like to use noun inference (allowing the player to just type “drill” and get the action to occur). In those cases you have to provide a specific Understand statement for the single word “drill” (and, likely, an alternate action definition that invokes the general one) in order to make the parser resolve it as an action rather than a generic examine statement.
You can also run into issues with making single-keyword examination work with the Remembering extension if you have objects that potentially require disambiguation (even if they’re not actually ever in the same location). The way this extension handles trying to examine something that isn’t there when you have disambiguation issues is to suppress the usual disambiguation message and print a “You can’t see that here” message. Unfortunately, the mechanics of disambiguation are hard-wired deep within the parser and can’t be worked around easily. Even though it doesn’t ask you to disambiguate, it still expects it to happen. In order to get proper behavior when the following command is a single-word examination of some other object (or even a single-word movement request), there’s a lot of special-case code involved in the “reading a command” and “printing a parser error” activities. It’s doable, but moderately painful.
When you get the point where you’re working on integrating all the extensions together, let me know and I’ll be happy to share what I learned so you can see whether or not you want to include it.
And as long as we’re talking about disambiguation, you might want to look at Numbered Disambiguation Choices (by Aaron Reed, of course) as well – it makes the whole disambiguation whole process clearer and gets you around certain problems where you’re trying to disambiguate certain similarly-named nouns that won’t work cleanly the normal way. It’s another fire-and-forget extension.
Good luck with this! Let me know if I can help in any way!
In general, I definitely agree with the frustration that a lot of these problems have been solved over and over again and yet most authors still aren’t adding the extensions to their own games. Creating a single uber-extension-- ideally one that’s polished and useful enough it might be included as one of the default I7 extensions-- could be a big step towards solving this.
(This all relates to the larger problem of extensions not getting enough visibility. I see a lot of posts everywhere with people wishing that there was some way to do something that there’s already an extension for. But I think this is another discussion.)
I would be very wary of including Keyword Interface in a package like this, though. It fundamentally shifts the IF paradigm to something a little different: and, as was just mentioned, breaks the low-level parser assumption that “first word equals verb.” I found with Blue Lacuna this led to a lot of extremely-difficult-to-diagnose-and-fix type errors.
What might be better is an instructional message: rather than actually trying an action, tell the player that the story expects verbs to come before nouns.
Smarter Parser also has issues, too: I’m quite fond of it, but it can slow stories down fairly significantly, since it’s doing a ton of regular expression matching. This only happens for misunderstood commands, but in Javascript interpreters it’s a point to consider.
In fact, a lot of the extensions under discussion here have some tradeoffs that make me a little wary of lumping them all together in one big package. Sometimes certain features conflict with the way a particular game works: letting people pick and choose by cherry picking which extensions to include has advantages. However, at the end of the day I think the benefits of such a package probably outweigh the gotchas: we can start for a baseline of “Hey, include this one extension, and if you have problems, you can just include the individual components instead.”
Other questions that arise: who maintains the uber-extension? If people keep updating the included extensions, do they have to update them in two places? If an author wants to take one of these extensions off in a more experimental/computationally-expensive direction, does it just fork? I guess none of these are really serious problems. Ideally there could be some sort of collaborative maintenance, so the individual authors could update their own segments, but we’d need an infrastructure for something like that.
One big advantage of the uber-extension is that it would make it easier to solve compatibility problems between newbie-assisting extensions. For instance, I just in the last day noticed that Implicit Actions and Modified Exit (both candidates for being added to the initial list, by the by) are currently incompatible with each other, since they both have a rule by the same name. These things would be a lot easier to catch and fix if people were actively trying to combine them.
Let’s keep this discussion going… I think good things can come out of this.
Regular expressions are something I think would be a prime example for acceleration. Can you provide more details about their performance (perhaps in another topic)?
Having recently optimized a large WIP for speed, I haven’t had any issues with it so far. As long as it only hiccups on invalid input it’s great. Mind, I can sorta call that speedbump a feature, as it gains the user’s attention that something outside the story needs attention.
In theory I feel a little bit uneasy about throwing instructions at the player unbidden, because it’s intrusive; but this is more of a vague prejudice on my part than a coherent objection, and I am coming round to it.
Right. Opt-out is better here than opt-in, I think. In the final analysis, authors can always go into an extension with a machete and take out the one bit they don’t like, and it would be a good idea if the code was organised and documented in a way that would make this easier; it would be extra specially nice if they could do this without needing to break the machete out at all (‘Disable smart parsing’, that sort of thing), but I’m not sure how feasible this would be.
Yeah, I thought about that as I was nodding off last night, and it was not conducive to tranquil sleep. I guess the really important issue here is how much compatability work needs to be done and how much benefit could be gained from streamlining; if the answer is ‘actually, not all that much’ then maintenance isn’t such a major issue. This means that the more distinctively useful the package is, the more maintenance load there’s likely to be. Grmf.
Oh, man, Implicit Actions. That is an excellent example of an issue which I wouldn’t think to implement because everybody was in perfect agreement about it five or ten years ago, so in my head it’s a solved problem.
It’s not too feasible right now for things of this complexity. I would like to see a form of conditional compilation, where you could write:
[b]Section - Keywords (for use with the keywords option)
[code here][/b]
If the author writes “Use keywords”, this section would be included in the story, otherwise not. (I thought there was something like this on the uservoice site, but I can’t find it now.)
–Erik
Yeah, that uservoice site is too delete-happy with comments. Thirty days or so pass, and you can’t look up what comments you’ve written on what suggestions, making it very hard to find suggestions you’re keeping an eye on but not voting for. Makes it a pretty poor place for discussion.
Meanwhile, the uservoice devs keep screwing around with how one logs in. Annoying, and a waste of their time.
Found it: inform7.uservoice.com/forums/573 … ?ref=title
This would be ideal, but I don’t think missing it is a show-stopper. It would require more work, but all the rules could be put into rulebooks that could then be globally turned on and off based on use options. I do something like this in the latest release of Smarter Parser to allow for quickly disabling all the built-in rules. This wouldn’t work in 100% of cases (you can’t make an Understand line a rule, for instance) but should be workable.
Not to be continually condemning my own extension here, but I’m not sure I buy this assumption. Remember, newbies are likely to be seeing MORE invalid input than valid input. I just threw up a transcript a newbie friend sent me ([url]Teaching IF to new players - #12 by aaronius]): it’s 40 moves with 28 misunderstood commands. If each invalid input means a six-second delay (which is quite possible on a mid-range computer running a Javascript interpreter) frustration is going to kick in sooner.
I’ve sent Dannii some Smarter Parser stuff for testing: maybe regex handling can get some of the optimization magic and this won’t be as much of a concern in the future.
Something that’s needed also is a large corpus of valid input that these compound extensions could be tested against, to make sure they don’t break anything as they continue to improve and evolve. I find that many many times an addition which seems to improve the new user experience in one way actually breaks some existing corner of IF implementation. One of the reasons that more of these things aren’t incorporated into standard distributions anyway is that solving them is often more complex than it appears. I know Graham and Emily have some scripts they use to test new Inform builds against a pile of test cases: if this moves ahead, we could see if the uber-maintainer could get access to this.
Just for fun I profiled that transcript using release 3. 6 minutes 44 seconds of processor time. Ick. 12.4 million function calls. At least the responses were better, though a few were really strange:
The second one (as well as a plain “ok”) should probably be caught, maybe synonyms for “yes”.
Yeah, I tried this too! This is obvious a Smarter Parser bug that should be fixed. It needs more field testing. 
That’s true–the hardest things to deal with in this way are kinds and properties, I think, and those may not be important for these extensions. Of course, doing it with rules as you suggest can get hairy if you’ve got a lot of different options, but it probably wouldn’t be too bad. And Understand lines are actually pretty easy to take care of as long as there is a use option or global variable to use as a hook:
Understand “[noun]” as examining when the keyword-examining option is true.
Another idea: if the uber extension were to act largely as a nexus for a bunch of other extensions, making them more compatible, etc., it could be up to the user to include those extensions to turn the attendant functionality on and off. Then we’d have section-level hooks, as well as the ability to nest them. For example:
[code]Chapter - Keyword interface stuff (for use with Keyword Interface by Aaron Reed)
[…]
Section - Special functionality when used with Smarter Parser (for use with Smarter Parser by Aaron Reed)
[...]
[/code]
This kind of thing can get hairy too, but it does have advantages…
–Erik
Aha! Now I see why you were asking about verbs changing their meaning depending on the actor. Just as with “sorry” and “hello,” these pseudoverbs have a habit of reversing their meaning when they are addressed to an NPC (e.g. “Phil, where is my luggage?” might get interpreted as asking Phil to request assistance about the player’s luggage).
I was thinking about this situation, and was wondering if it would be useful to maintain the notion of the narrator-character. For example, “sorry” wouldn’t be considered as asking the PC to perform the action “saying sorry,” but asking the narrator to perform the action “accepting apologies.” The narrator-character would still have to distinguish whether commands were directed at the PC or the narrator-character, but at least each individual verb would be more consistent. Maybe conversational verbs could be a third category after in-world and out-of-world, where in-world verbs are addressed to the PC by default, out-of-world verbs are addressed to the interpreter by default, and conversational verbs are addressed to the narrator by default.
Not sure if any of this is useful, I’m just brainstorming.
I am happy to bring this thread back to life with an update: I’m prepping an all-in-one newbie extension that will incorporate much of what’s been talked about above. To do so I’ve been updating my own extensions to give them a more solid testing and compatibility with each other, and working on a new extension I hope to include to improve the standard library messages.
The thought is that this compilation extension will basically copy and paste (and credit) all contributing extensions, and I’ll update it at intervals, maybe along with each new I7 build… hardcore authors can always cherry-pick the individual extensions they want or get the latest versions, but the goal is to have a single, one-click download that, especially for new authors, lets them easily and drastically improve the player experience.
More later in a new thread, hopefully-- I guess I just wanted to ping and see if anyone has been working on similar things in the usual cone of silence.
Aaron, sounds very promising, especially with updated “Neutral Library Messages”. I’m tempted to look at Ron Newcomb’s “Default Messages”, but if you create one big mega-pack maybe I can just follow whatever decisions you make. 
In case you’re curious, below is the list of extensions I’m currently using in The Z-Machine Matter. (Note this also includes some minor comments to myself on things I need to investigate. Can’t say I’ve been entirely successful with Measured Liquid, Telephones or Assumed Conversers.)
As a first-time author, I greatly appreciate how much effort people have contributed to making extensions that are easy to use.
–Zack
[code]Section - Extensions
[ Requires Z8 or larger story file to compile]
Include Exit Lister by Eric Eve. [ Display exits in status bar ]
Include Keyword Interface by Aaron Reed. [ Highlight objects in text ]
Include Measured Liquid by Emily Short. [ For liquids, glasses, bottles ]
Include Telephones by George Tryfonas. [ Not fully implemented ]
Include Menus by Emily Short. [ Basic help & hint system ]
[ Extensions to help with parsing errors. They also make the game larger ]
Include Extended Grammar by Aaron Reed.
Include Small Kindnesses by Aaron Reed.
[ Source of “I didn’t understand that number” errors ]
Include Numbered Disambiguation Choices by Aaron Reed.
Include Assumed Conversers by Michael Martin. [ Ask About defaults ]
[ Though it does not disambiguate ASK ABOUT Topic with multiple NPCs ]
[ Also, it seems that this creates confusion with Inform / Quiz with objects ]
[ Doesn’t work properly with objects - possibly worth skipping ]
[ Note - Smarter Parser requires Glulx interpreter ]
Include Smarter Parser by Aaron Reed.
Include Poor Man’s Mistype by Aaron Reed.
[/code]