Can we make a better parser tutorial?

If your game is actively hostile to if-newbies, I guess it could be a good idea to say “don’t play this game - play these instead” to them. That’s how I’d interpret your suggestion. Or I’d ignore it. (Putting suggestions at the end of a game could be a nice tough though, but would do nothing for the subject of this thread.)

Basically, what Peter Piers said goes for me too. If I’m in the tutorial of a game, that tutorial should facilitate my playing that game, not other ones.

It has been some time since we last visited this issue, but past consensus about making help/tutorial content on by default in Inform was that it would create more grief than it resolved. The only thing worse than the lack of help in a game is inaccurate help – help written for the general case that recommends verbs not actually implemented in this particular game, for instance, which might throw off both novices and adept players, and would certainly add that extra sense of broken-ness.

By making some options available but requiring the author to opt in intentionally (the idea went) we made it more likely that people would double-check the text of any included helps or tutorial features to make sure that they were actually a good fit for the game in question.

It sounds like there’s a general consensus that

a) parser games already exist with really fantastic tutorials;
b) the best tutorials provide a hand-holding walkthrough for IF basics (teaching LOOK, EXAMINE, TAKE, INVENTORY, and movement);
c) very few parser games include a tutorial at all, let alone a good one;
d) we don’t want to send new players to a different game to learn the basics.

(If we’re not in consensus on these points, someone should object and correct me.)

Based on this list, I see two things that we can do as a community to improve the new player experience.

  1. Make it easy for authors to create good walkthrough-style tutorials.
    I’m imagining a set of easy-to-use extensions for the major parser authoring systems, with excellent documentation. For the most part, they should be plug-and-play, but have enough flexibility for modification in the case of nonstandard mechanics. And then…

  2. Hold authors responsible for including tutorials in their games.
    For the most part, we expect every parser game to be beta-tested (apart from speedIF). Some people hold the public policy that they won’t play or review major competition games that haven’t been beta tested. I think this has gone a long way to help improve beta testing frequency.
    What if, as a community, we applied the same standards for tutorials? I think the incidence of tutorials would skyrocket. And the more games have tutorials, the more this would be a clear community standard, and the more authors would put tutorials in.

To be clear, I don’t suggest holding authors responsible until the above extensions exist. Or boycotting older games that don’t have tutorials. Because that would be unreasonable (and also, no one would play any of my games ever again).

But if we could make plug-and-play extensions for new player walkthroughs, and their existence is well enough publicized so that new authors can easily find them - then it would be a reasonable requirement. It would be another barrier to authoring, but not a very high one.

I think that mock transcripts are a wonderful way to demonstrate how to play parser IF, except for the (huge?) flaw that they’re not interactive. “Non-interactive” might be all that’s needed to be said against them, but I’m pretty sure that’s how I first learned how to play these games. Infocom’s, as far as I remember, also demonstrated genre, and the types of action that were fruitful in a particular game, but you could do more and write a transcript to act as a prologue, or the backstory of an NPC, or something else to add to the worldbuilding. So I guess the question is, is the fact that it’s just a blob of inert text a dealbreaker? I think for some players it would be, but maybe not all. (One technique is to make the transcript really funny and just enjoyable to just read.)

By this do you mean interactive tutorials? Maybe in general they are the best kind, or maybe not, I don’t know. But I don’t know if they’d suit every game or every player, at least not in isolation. People differ in their approaches to learning things. Some people do like to dive in, some may want to “read the manual” first, some people may want to type lots of different things instead of whatever the tutorial currently wants them to type. Some people may prefer to have something they can look back on, for reference.

It’d be good to make it as easy as possible for game authors to include tutorials. But I’m wondering, assuming game authors do want to include some kind of help, what are the reasons the existing extensions aren’t getting used (if they aren’t)? That would be helpful to know when putting together new ones. For example, Emily Short’s tutorial extension that matt w mentioned looks like it already does most of the things Dan recommended, as far as introducing the basic actions. Is it just that it’s not possible to have a plug-and-play tutorial that’s also interactive?

Sorry, matt w - somehow, I missed your post previously. (Thanks for calling it out, bg!)

I tried out Emily Short’s Tutorial Mode, and it actually looks fantastic. (It’s not updated for I7 yet, but it’s a one-line fix - initialize the temporary variable way with “let way be north;” at the top of the teach compass directions rule.)

It is, in fact, pretty plug-and-play. The source code below will run a basic tutorial, including LOOK, EXAMINE, TAKE, INVENTORY, DROP, and movement by compass directions.

Here’s example source code (mine, not Emily’s - I wanted to see how it would adapt to a different environment.)

[spoiler]“Test Chamber”

Include Tutorial Mode by Emily Short.

Test Chamber is a room. “Pale walls, cold air, underexciting. The lobby is to the north.”

Lobby is north of Test Chamber. “Wholly unimpressive and forgettable. The test chamber is back to the south.”

The silver ovoid is a thing in Test Chamber. The description of the ovoid is “You gaze at your distorted reflection.”[/spoiler]

Here’s the resulting transcript. (All the instructions are actually in italics, but I didn’t italicize them here.)

[spoiler]Test Chamber
An Interactive Fiction
Release 1 / Serial number 150603 / Inform 7 build 6L38 (I6/v6.33 lib 6/12N) SD

Test Chamber
Pale walls, cold air, underexciting. The lobby is to the north.

You can see a silver ovoid here.

You can review your surroundings at any time by typing LOOK. Try it – type LOOK now. (Or, if you don’t need instructions, you can turn the tutorial off by typing TUTORIAL MODE OFF.)

look
Excellent – LOOK will print a description of your environment, like so:

Test Chamber
Pale walls, cold air, underexciting. The lobby is to the north.

You can see a silver ovoid here.

Individual objects have descriptions, too. You can find out more by examining them, as in EXAMINE THE SILVER OVOID.

examine silver ovoid
Very good. Since you’re likely to examine things frequently, you can also abbreviate this command as X, as in X the silver ovoid.

You gaze at your distorted reflection.

You can pick things up when you see them, like this: TAKE SILVER OVOID.

take silver ovoid
Well done. Now you’ll get a message to tell you whether you succeeded in picking up something:

Taken.

Now, it turns out that you’re holding something. To find out what, try typing INVENTORY.

inventory
Right! In the future, you can also shorten this command to INV or just I. As you see, it will print out a description of what you’ve got:

You are carrying:
a silver ovoid

If you want to get rid of something that you’re holding you can always drop it, like this: DROP THE SILVER OVOID.

drop silver ovoid
Dropping things will move them into your environment, like this:

Dropped.

To move from place to place, you can use the compass directions (NORTH, SOUTH, EAST, WEST, as well as NORTHEAST, NORTHWEST, etc.)

From here, try NORTH.

north
Good! Like other often-used instructions, compass directions can be abbreviated down to N, S, E, W, NE, NW, and so on. UP and DOWN are also possible – keep an eye on room descriptions in order to learn more about where you can go and when.

As soon as you enter a new room, you’ll get a description of what’s there, like this:

Lobby
Wholly unimpressive and forgettable. The test chamber is back to the south.

And that covers most of what you need to know! There are lots of other verbs you can type as you go along, but you’ll likely be able to guess them from context. Don’t be afraid to experiment with new actions.

To stop the game, type QUIT; to save your current position, type SAVE. RESTORE allows you to bring back a game you have previously saved, and RESTART starts the game over again at the beginning.

[/spoiler]

Some observations:

  • It automatically begins in tutorial mode with a TUTORIAL MODE OFF command for people who don’t need it. I’m torn about this decision - I’d generally prefer a starting question (something like “would you like new player help?”) because it feels unattractive to me. However, it will ensure the people who need help most get help, and may be the best decision for that reason.

  • It requires all commands in full, and rejects commands based on input. (So “EXAMINE OVOID” was not acceptable in the example above - it had to be “EXAMINE SILVER OVOID”). That’s a little annoying.

  • The structure for adding new commands might be a bit intimidating to some authors… but authors who are intimidated by that system probably aren’t adding many new commands.

“2) Hold authors responsible for including tutorials in their games.”

This might be a bit tricky because definitions of “tutorial” may differ. Is a list of available commands good enough? Does it need to be adaptive? Do we now judge the game based on the quality of the tutorial? I would prefer the ability to experiment with how to present a tutorial without players dismissing me out of hand because it doesn’t follow the recipe.

Neil

I was unaware of the Tutorial Mode extension, but it’s pretty much exactly what I was thinking of in terms of a good parser tutorial. A good automated tutorial should 1. have a list of skills the player is expected to demonstrate, and 2. prompt the player every turn until those skills have been demonstrated.

One thing it is missing, however, is some way of informing the player that they can use verbs with two nouns (CUT THE BREAD WITH THE KNIFE), and that the parser recognises a wide range of English verbs. This would require some author intervention, though not a lot of it, to ensure that a game has something to do in that area early on. And I think we can’t really say a game has a successful tutorial until those two necessary skills are conveyed to the player.

Also, I’m not sure how easy that kind of introspection into player actions (“has the player performed an action with two nouns yet? has the player used a nonstandard verb yet?”) is in I7.

It turns out that Tutorial mode is updated for 6L38 and is in the Public Library. (This confusion is my fault–I linked the old version.) And the new version solves one of the big issues with the old one–it now reacts to actions rather than texts, so that “TAKE OVOID” will be accepted even if it asked you for “TAKE THE SILVER OVOID.” (Which is an important lesson to teach, I think–at least we don’t want to be teaching players that if you don’t put every ‘the’ exactly where it’s expected, your command won’t be understood.)

One thing that arises here that I think didn’t arise with the older version is that parser errors print their normal messages. It might be nice to have the messages modified by default for the tutorial to something slightly more explanatory.

I also agree that it’d be good to remark on the tutorialiness of works–not to say that every game must have a tutorial as such (as Neil said about definitions of “tutorial”), but to at least talk about whether the game has anything that facilitates comprehension for novices. I don’t even think every game needs this–some games want to be Starseed Pilgrim–but it’s worth remarking on, and since reviewers tend to be experienced IFers it’s something we might not pick up on.

“Does your game provide clear, immediate guidance for new players, without requiring them to go look for it? Is the guidance sufficient to let a parser novice play your game successfully?”

Since a plug-and-play tutorial exists for I7 - it seems reasonable to expect games to provide either that level of help, or to provide something that is superior but tailored to that specific game - if there is a movement to adopt new-player-friendliness as a general community standard.

In Hypothetical World, where everyone has easy access to a tutorial extension in their chosen development system, I can see three valid reasons not to provide new player help.

  1. There’s a tight time constraint (such as speedIF).
  2. The game doesn’t use standard parser mechanics (such as Pong or This Is A Real Thing That Happened.)
  3. For whatever reason, the author actively wants to discourage new parser players from trying their game. (I have no examples, though I’m sure they exist.) In that case, it would be reasonable to give a disclaimer at the front and some options for good alternate starter games.

Are there any other good arguments for leaving a tutorial off?

(I do know we are not in Hypothetical World. I somehow entirely missed the existence of Emily Short’s extension, and I can’t be the only one. But if we were there.)

  • Extension might interfere with game logic in ways too tedious to track down.
  • Extension might trip up the intended pacing of the opening scene. (This could presumably be adjusted by customizing the extension, but again, this might be too tedious.)
  • Author might disagree about the effectiveness or approach of the extension.

(Not intending to be a downer about this.)

All valid arguments - if I were exclusively suggesting use of the extension.

But see the same part of my post where I suggested that a good measure of tutorial existence would be

My point re: the tutorial extension is that it makes adding an interactive tutorial easy. Not that it should be exclusively used.

Largely agreeing with zarf, but I think the basis of comparison would have to be something like “Does the game provide at least the level of help you’d get if you just plugged the extension into this particular game, with maybe a little more tweaking?” For example, in Terminator the extension would be pretty much useless. (Though this probably falls under “non-standard parser,” and of course I had to roll my own tutorial because the mechanics of the game would’ve been incomprehensible to everyone without one.) Or if you have a one-room game where inventory isn’t important, like Tea and Toast or Engima, Tutorial Mode only gets you look, examine, and the metacommands. And a game like Moonbase Indigo where the fun is mostly in the nonstandard commands won’t work that well in tutorial mode, though maybe it supplies its own tutorial…

…it’s not that I’m arguing against the general idea, that people should use the extension or come up with their own tutorial. Just that even if the extension is well known, it won’t be the case that everyone will have it or a similar tutorial unless they Just. Don’t. Care. On the other hand, testing has become a generally accepted norm, and that requires a fair amount of effort, so we might think that most authors should be willing to put in at least the fraction of effort that goes into testing into making the tutorial work.

For a cautionary tale, I tried putting Tutorial Mode into the one project of mine in which it might be expected to work (Faithful Companion–this is 6G60 so I had to use the old version). The first thing that happened was that it told me to LOOK and then told me I was done. I don’t usually Bracket Every Notable Thing in room descriptions, and apparently this meant Tutorial Mode didn’t detect that there were examinable things around. I hastily threw in a bracket and got this (emphasis added):

The old version of Tutorial Mode picked out a random visible thing for further examining… and this time it happened to grab a dummy (and privately-named) thing I’d put in there in case the player sees something on the bench and types “x something.” The new version replaces this with LOOK AT ME (and mentions that you might want to look at other visible things), which is much nicer.

And then:

Anyway, it seems as though you may need to hammer out some quirks when dropping this into your game. Which is something worth doing!

Yyyeah. The thing with adopting any standard in the parser-IF world is that it has always been a community with at least as many malcontents, experimentalists and oddballs with weird unorthodox concerns as Exemplars of Accepted Good Practice, however that has been constituted at any given time. This is one of the big things I value about it, but it does make make intentional movement in any unified direction rather difficult.

But I think the “Hey, everybody, have your game tested!” movement did work very well, to the extent that mini-comps now build in a mandatory testing window.* Perhaps we can come at least a little closer to attaining consensus here–maybe building in a tutorial window, or maybe saying “Hey! Part of the purpose of the testing window is to get your tutorial going!” (This was in fact when I did my tutorial.)

Yes, I just switched sides in the argument.

*Maybe only the two ShuffleComps and ParserComp.

If offering help were adopted as an informal community expectation, I’d be inclined to be flexible about the form of help offered: whether the main source of help is a tutorial integrated into the game or whether it’s the IF postcard released along with the game, whether the in-game help is offered up-front or only in response to the HELP command. (I do think most games could reasonably be expected to have a response to the HELP command, and this is another area where a new extension could come in handy.)

In terms of encouraging more tutorials, I’d want to focus on making it appealing and easy for authors,* even authors who aren’t fans of Tutorial Mode for one reason or another. Take Caleb’s suggestion, for instance. It’d be neat to see a game that offered a mock transcript in the HELP section. Get some community involvement, have a Mock Transcript Comp to select a handful of winning mock transcripts to go into an extension. I’m just throwing out ideas, but my point is to give game authors helpful tools along with room to exercise their own judgment about what kind of help is appropriate for their game.

*As opposed to some of the more punitive approaches I associate with the “credited beta-testers” community standards. Not as opposed to other forms of positive encouragement.

Yeah. Other intentional changes include cover art, which was facilitated by tech (IFDB) and community events (the IF Art Cover Drive), and a lot of the principles of the mimesis and Player’s Bill of Rights manifestos (a lot of which seems dated now, largely because the good bits are now things we take for granted).

(So, perhaps a IF Tutorial Drive? How might that work?)

I can’t take credit for this one - as far as I know it was first employed in Apollo 18+20.

But for some games, it will genuinely not be easy. Is what I meant. Telling people “you should do a lot of work for this goal” is not the same as telling them “just drop in this extension and that’ll cover it.” And no extension will work for everybody, so…

(Mind you, we could wind up with a couple of different extensions.)

I like the idea of adopting this goal as a community thing. It has the very desirable attribute of achieving positive value without universal adoption; if even half the parser entries in next year’s Comp have tutorial elements that will be a huge accessibility win.

(Thus also a problem of the commons – maybe everybody waits for everyone else to carry the load. But we’re a small enough group to avoid that, hopefully.)