Can we make a better parser tutorial?

It seems to me that a tutorial that says “You have to type a verb plus a noun” without also giving an idea of what is likely to work (especially odd things like “inventory” and compass directions, and maybe also mentioning that you should probably focus on the nouns that are mentioned in-game) would be a rather limited tutorial. I think the postcard teaches both these things, and both are useful.

What I’m saying is: I am not concerned about the hypothetical player who thinks “I want to try taking something, and I’ve typed TAKE, but I don’t know what’s available to take so I don’t know what to type next.” I think there are very few of that person.

I agree that the parser can’t/shouldn’t accept every newbie command, but I have always felt that “look box” should automatically “look at box.”

I know, you might want to “look under box” or “look in box.” But that’s no reason not to have a sane default for “look box.”

Definitions! Okay, definitions are good. I’m in agreement with Zarf on the problem that a tutorial is trying to solve. Here’s my definition of the best possible tutorial.

The best possible tutorial will provide proactive support that will give brand new players all the tools they need to play this specific game, within the game.

Proactive support: The game actively verifies whether the person needs new player help, or immediately provides help with the option for experienced players to turn it off (as Emily’s tutorial extension does.)
Brand new players: People who have never played or even seen a parser IF game before.
All the tools they need: This will vary from game to game, but most games will want to teach LOOK/EXAMINE/TAKE/INVENTORY/DROP, compass movement, and SAVE/LOAD/QUIT/HELP, at a minimum.
This specific game: A game shouldn’t be responsible for teaching people how to play other games. It also shouldn’t teach the player tools they won’t need or that are unimplemented in this game. Because that’s confusing.
Within the game: Instead of pointing them to an external resource or a different game for help.

I definitely see the merit of other kinds of new player help, such as highlighting nouns or providing a list of alternate possible inputs when a command fails. But I don’t see them as a tutorial per se, unless they’re integrated into a tutorial as described above.

I can see times when you might want to do that within a tutorial. For example, if my game includes important objects that are relatively concealed in the room description, then I might want to highlight all the room description nouns for the player temporarily, just to help them get used to to reading the room description carefully.

But I think perma-highlighting is less part of a tutorial and more new player help. Though they’re closely associated.

(I am happy to talk about non-tutorial ways to make games easier for new players. It’s a good topic! But we might want to branch the topic off tutorials.)

The problem arises when the player wants look in or under or behind something, and the author hasn’t provided that command. It’s easy (at least when using Inform) to get:

LOOK BEHIND COUCH
You can’t see any such thing.

But the couch is right there! complains the player. It’s happening because the command is being parsed as “LOOK [AT]” → “BEHIND COUCH” and there’s no such thing as a “behind couch” in the room - but you have to know something about Inform’s parser to realise that.

I’m talking about Inform specifically because TADS 3 doesn’t really have the same problem. It distinguishes between the error states “I don’t recognise a word you used”, “I recognise all those words but they’re in an order that doesn’t make sense”, and “your command makes sense but you’re talking about something that isn’t here”. At least the default library does - adv3lite handles things a little differently. And I don’t know what the other parser IF systems do in that situation.

(For the record, I support “LOOK THING” as a synonym for “EXAMINE THING”. But it comes with its pitfalls.)

Rather than a hand-holding tutorial or a static document, what about something in the middle? Jon Ingold’s Dead Cities has a pane at the bottom which suggests a command you could try in the current situation and, after a few turns, adds, “or type your own command”. You could extend that to include more than one suggested command at a time. It might need more tweaking to suit a particular game than something like Emily Short’s tutorial extension, though, and I imagine it could be hard to find a good way to tell the player, “you’re on your own now,” and switch the suggestions off.

On the other hand, it’s brief and simple. You don’t have a lot of tutorial text that might clash with the tone of your game text or overwhelm the content of a very short game. And you should be able to slowly increase the complexity of the suggestions to teach the most important concepts/commands subtly.

I am… amused? wryly irked? at the prospect of adopting this as a standard at a time when an increasing number of videogames are adopting the 'fuck it, this is expensive, let ‘em figure it out from Youtube or the wiki’ standard for tutorials.

This was one of the hotel-room panels at one of the IF PAX East things; I don’t remember all of it, in part because of the haze of profound depression that settled over the room. But the one thing I did take away from it was that you should never ask players whether they want a tutorial or novice mode; they’ll say no and then blame you for it. You should start with the tutorial and then hide a tiny little button somewhere that might possibly allow them to skip it.

Whoops, I was super unclear about what I meant. I meant that it shouldn’t be too much work for the author to add things to the Tutorial extension, not that it wouldn’t be too much work to add things directly to the extension–it certainly would.

What I mean is something like this: Include an example in the Tutorial Mode documentation that includes, say, buttons, and also this code:

[code]An instructional rule (this is the teach pushing rule):
if the teach pushing rule is listed in the completed instruction list, make no decision;
if the player can see a button (called target):
let N be “[the target]”;
let M be “[target]”;
say “You can see some buttons. The natural thing to do with a button is to push it. To push [the target], try PUSH [N in upper case] or PUSH [M in upper case]; PRESS [N in upper case] would work too.”;
now the expected action is the action of pushing the target;
now the held rule is the teach pushing rule;
rule succeeds;
otherwise:
make no decision.

Carry out pushing something (this is the register pushing rule):
add the teach pushing rule to the completed instruction list, if absent.

Table of Instruction Followups (continued)
selector followup
teach pushing rule “Well done! Many of the things you encounter in the game can be acted on in the ways you might expect. If you see a door, you might try to OPEN it; if you see some food, you might try to EAT it; and so on. Here’s what happens when you push that button:”[/code]

Which gives the author a natural template to make their own action for teaching more than the standard verbs, and hinting to the player about verb flexibility. (Not that they can try pretty much any verb, because they can’t, but that they can try the natural ones.) And lets them know that they ought to substitute something other than pushing buttons, if there aren’t any buttons in their game.

You might also want to have a similar thing in the template for two-noun actions; PUT THING ON OTHER THING would be a pretty good candidate for the example documentation.

Dan etc.–I thought LOOK BOX had been understood as “look at the box” for the last few versions of I7?

This is completely true. But I suspect authors would be wildly resistant to “and your tutorial mode should be on by default”.

I’m not sure how the current audience of habitual parser game players would react either.

maga–that surprises me a bit, that games are increasingly sending people to the wiki and walkthrough. It doesn’t really seem like we can count on wikis and walkthroughs though. Also, are those games where the player can be totally brickwalled by the control scheme at the beginning, the way they can in parser IF? I’d be even more surprised if they were.

One thing that I think of here is this comment of Anna Anthropy’s about Dys4ia:

The lesson I take from this for us is: if we want the players to be playing the game by typing in verb-noun commands, we should have them interact with the tutorial by typing verb-noun commands. Get them doing what you want.

I’d like to hear more about the “Fuck it” idea, though.

To start the game, type “START THE GAME”.

One of my all-time Twine favourites, Swan Hill, does an interesting thing to explain the two different kinds of links it contains. That kind of preamble-as-gameplay is a nice trick, but I’m not sure how it would work for a parser interface.

I always advocate things that I think will lead to the best possible result, but I don’t tell people to go there right away, or that they should even worry about it right away.

In some cases, the light tweaking you mention would be all that’s needed to customise Tutorial Mode for a game. I’m wary of dropping a vanilla one on different games for all the technical reasons Zarf has discussed. Most anecdotes in this topic, including yours, are about how it didn’t quite work out.

I see people in this topic are starting to talk about trying to solve this problem by technical means, which is good, but I’ll leave it to them. I think you’ve interpreted what I’m saying as being against the push to make an easier plug-in tutorial solution. The truth is I’ve sufficiently low personal interest in that project that I just have little to say on it. I don’t want to discourage, I’m just leaving it to the people who are into it.

I think it says what it says about specific in-game tutorials. I’ve said I see it as a big deal to add a custom tutorial, so yes, I believe there’s no point new authors killing themselves to build custom tutorials unless they think their game is going to be exposed to certain volumes or types of people who will benefit from it. It’s inherently better for any game if it’s got a custom tutorial - if the game’s up to it.

If an author is thinking about the unforseeable circumstances in which their game might be played in future, they’re already the type who’ll build a tutorial as soon as they’re up to it, out of some sense of their game’s own worth. Other folks here are positing universally covering everyone else to some minimum standard on the same front, but I’m not. I believe in universal health coverage and I have it, but I don’t believe in universal tutorial coverage.

Thinking on all the IF games I’ve played and reviewed, in most cases, if the game was a bit clunky, or raw, or actually a mess, a custom tutorial would’ve made no difference at all. To me, the person to pinch is the one who’s started making competent->good games and isn’t putting in tutorials.

The thing about a custom tutorial is that it’s going to be a direct reflection of the game quality itself because it’s generated by the same person with the same skills and means. I think authors should worry about: learning how to make a game in the first place, then about making a game as good as can be, and then a custom tutorial!

In the meantime, they can drop in a plugin that other people in this topic are variously discussing or developing. If an author drops it in, tries it, finds it a bit generic and says ‘I need to tweak this’, they’ll have headed towards where I think they should ultimately go anyway.

-Wade

I don’t think it’s a good idea to try to set the expectation (via review or voting policies, for example) that every comp entry should have a tutorial mode. I suspect that many comp entries are written mostly with the comp voters/reviewers in mind, i.e. connoisseurs, and I don’t think that’s a bad thing. Not every IF game needs to be accessible to a wide audience, just like not every film, novel, song, play, or any other work of art needs to have accessibility in mind, or even as a desired attribute.

However, one idea that Nick Montfort has suggested a few times is to have some sort of “label” or publishing entity that puts out (or simply endorses) IF games with a certain editorial bent or curation goal. I think “IF that is accessible to novices” would be a great idea for such a label, and it could require that any IF game it publishes/endorses have a custom tutorial. This could be as simple as a list that someone maintains somewhere (e.g. IFWiki), or it could involve coming to agreements with each author about whether their game is endorsed or (re)published somehow, or it could go as far as commissioning games a la the IF Fund. However it’s done, this would benefit novice players, who would know where to look to find accessible IF games to start with, but as the label got more well-known it would also benefit authors who make accessible games, as their games would get more exposure by being associated with this label.

A side note about the “X ME” convention: I think a natural question for a player to want to ask when starting a new game is “who am I?” It may be that this question should always be answered in the introductory text, since looking at yourself is often not a natural way to figure out who you are. (Or maybe more games should have a mirror in the starting location.) But I think this is more than just a shibboleth convention, as zarf suggests. (That role is filled by XYZZY, of course.)

With regard to review/voting policies and big competitions, there’s the consideration that not every parser IF author is a member of this forum, or taking part in this conversation.

I like this idea.

I think it’s a good idea to set it via the competition entry guidelines.

I disagree strongly.

The majority of parser games are released in competitions, and competitions (particularly IFComp) are when non-connoisseurs pay the most attention to parser games.

People are more likely to try out the IFComp winners than any other parser games*. This is exactly the situation where tutorials are needed.

[size=85]*With the possible exception of large-scale releases like Counterfeit Monkey and Hadean Lands.[/size]

…I wouldn’t suggest tutorials in competitions with a limited writing window, though. Writing a game in a tight window is hard enough as-is, whether it’s three hours or two weeks. And no one really expects maximum polish out of those games anyway.

I think a general extension would be useful, even if it doesn’t come with many built in hints. A good tutorial extension would schedule suggestions based on several factors:

  • Notice when the player is floundering or whether they are consistently producing valid commands, to give less frequent suggestions when they player is doing well
  • A rough hierarchy of commands (as suggested previously, along the lines of look -> examine -> take -> inventory)
  • Whether a command has been tried and then forgotten (a la space repetition). For example if the player stops examining things, in a subsequent room they can suggest a new prominent item to examine. Such a system could even always be on, but each use of a verb delays future tutorial suggestions such that it in practice never gets suggested again.

To do this well would need some fairly involved code, which is why a common extension would be valuable. But to work it would need to be author customised, to suggest half a dozen prominent items to examine or collect, and to give other verbs to teach. Ideally it would also be easy to change the narrative voice of the suggester too. It would be possible for the extension to share (for Glulx at least) a common data file, so that confident players wouldn’t have Examine suggested to them each game, but could still be prompted about game specific verbs.

PS: Is there a better verb than inventory? I think it makes sense to list possessions if they player examines themselves, but that too is not an obvious command. Should “What do I have/what am I carrying?” be supported by default?