Novice Friendly extension

In the last few months there has been a renewed focus on making IF accessible to players who are entirely or partly unfamiliar with the form. While a lot of discussion has revolved around high-level changes (‘can we live without the parser’, that sort of thing), I’ve also run across many, many suggestions for smaller, less earth-shaking changes that wouldn’t affect experienced players much, but could make a good deal of difference for novices.

There are problems with this: there have been so many ideas of this kind that I can’t remember them all. And all these good ideas don’t help the novice much if they only appear scattered across a handful of games, each of which only use a few of those ideas. And some of the ideas, while simple, are such a pain in the arse to actually code that the grunt work should only ever have to be done once. (I mention this because, in the light of Sarah Morayati’s eminently sensible post on default parser messages, I was going through Custom Library Messages to make sure that everything out-of-world was consistently bracketed. And good weasels in a basket but it’s an unpleasant chore.)

So I’m wondering about the utility of collating a big grab-basket of novice-friendly, low-impact tweaks into a single bloated extension. This would be a fairly big-tent approach, written with the understanding that authors can strip out individual features that don’t agree with them. In general, though, these should be features that will work just fine without the author doing anything further to them.

Here are some things that might make sense: I’m mostly feeling out how this might work at this point.

  • Use David Fisher’s Custom Library Messages to bracket (or otherwise consistently distinguish) all out-of-world text.
  • Gank or integrate a quite embarrassing number of Aaron Reed extensions: Keyword Interface, Remembering, Extended Grammar, Small Kindnesses, Smarter Parser, and Poor Man’s Mistype look like candidates.
  • Use Juhana Leinonen’s Reversed Persuasion Correction.
  • No-input commands (when the player just hits ENTER) default to… something. WAIT or HELP?

Thoughts very much appreciated; this is extremely speculative at the moment.

This makes tons of sense, and is more or less what I’m trying to implement in my game - but yeah, just as you said: making sure that everything that’s out-of-game is bracketed completely stinks.

No-input commands defaulting to LOOK was one of the things I thought was most useful about Blue Lacuna’s various attempts at making things easier for new players.

Yeah, that’s a great idea. My plan was to create a tutorial extension when the tutorial game is finished, but that wouldn’t be an all-in-one solution, just for detecting when the player is stuck and for giving advice on how to play.

Aaron Reed’s Whom the Telling Changed transcripts and other people’s experiences suggest that many new players just hit enter when they don’t know what to do or they want the plot to advance (like WAIT). Something like this might work, with the action tips being context-sensitive:

  • Use David Fisher’s Custom Library Messages to bracket (or otherwise consistently distinguish) all out-of-world text.
    • Gank or integrate a quite embarrassing number of Aaron Reed extensions: Keyword Interface, Remembering, Extended Grammar, Small Kindnesses, Smarter Parser, and Poor Man’s Mistype look like candidates.
    • Use Juhana Leinonen’s Reversed Persuasion Correction.
    • No-input commands (when the player just hits ENTER) default to… something. WAIT or HELP?

Those are all great ideas! I’m trying to do something similar in this year’s Comp entry, but it isn’t formalized out into a single extension. I’ve used Aaron Reed’s Blue Lacuna convention of ENTER equating to LOOK, but that’s because I’m using highlighted keywords in the text, so the user is presented with at least some things to do when they hit ENTER. Juhana’s suggestion sounds great also.

Emily Short’s Tutorial Mode extension also looks very promising as something that could be added to an omnibus extension like you propose – I’ve adapted quite a bit of it along with many of the Aaron Reed extensions you indicate above in my current WIP and they all work well together.

I have stumbled over a few incompatibilities between Keyword Interface, Remembering, and Smarter Parser. I’ll try to summarize them when I get home and give you a heads up on them – there was a bit of code required to get them all to work seamlessly, but I can’t remember right now whether that was because of my inclusion of Eric Eve’s conversation engine or not. I’ll check and let you know.

I will also say that Keyword Interface is about as far from “low impact” as you can get. As it is, it can change the startup sequence of the game, and without significant modifications to the source code it looks really odd (no keywords in room descriptions except for items that get default text printed – keywords are always highlighted in inventory listing unless you have any custom text, in which case they’re not unless you specifically set that up). It’s a great extension, but requires significant work to get value from.

These all sound like good ideas. Note that as extensions can require other extensions, the “Novice Friendly extension” wouldn’t have to be long, it could just consist of a list of other extensions it requires.

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.


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.


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.)


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: … ?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]]): 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. :slight_smile: