I think we can keep expectations in line with the tools on hand.
We have maybe not spelled out exactly what it is that a tutorial is trying to accomplish. (We’re talking about a “best possible tutorial” and a “good-enough tutorial” without saying what it’s good at.)
The problem (I perceive) is a player facing a prompt without knowing what kinds of command to try. This is not the same as failing to perceive available nouns and verbs in the current situation. Rather, I imagine someone who doesn’t realize that an IF command is made up of a verb plus nouns in the first place.
(The “WHAT AM I SUPPOSED TO DO?” problem.)
This is the problem that the IF postcard directly tackles. One of the postcard’s features is that it’s not game-specific; in fact it’s out-of-band, a static document or a literal printed postcard. This conveys that it is not a set of instructions to follow but a template for options to consider. This is, to coin a phrase, deliberate.
Parser-IF fans generally feel that the postcard is a good idea, and I think this is because we grasp that the problem I’m describing is important.
I wouldn’t claim it’s the only problem. There are, separately, the skills of reading IF output and picking out (a) the important objects (b) the implied possible actions © the implied logic connecting your actions to the reactions of the game world. Those are harder to get into a tutorial. I tried to put them in Dreamhold (with the early game locations heavily influenced by the desire to teach these skills!)
I really didn’t put them in Hadean Lands at all. HL’s tutorial is a half-assed compromise between the original problem (demonstrate basic IF command structure) and the problem of teaching alchemical procedure, which is completely game-specific. (The opening question, “have you played IF before”, is a mess. I should have made it a three-value question: are you a complete newbie, an IF fan who’s new to HL, or do you want to be thrown into the deep end with no help at all? But that is already too much question for newbies.)
It’s also important not to confuse the problem “player doesn’t know what to type” with the problem “player types things that don’t work”. These are completely different directions! I respect the work Aaron Reed did for New Player Experience, but I worry that it confused these. (Or, if you like, focussed on the part that I’m not so concerned about.)
So, for another example: when Emily and others observed that new players typed “LOOK LAMP” a lot, they argued for accepting that syntax as a synonym for “LOOK AT LAMP”. In HL, I instead generate a message explaining that “LOOK AT LAMP” or “EXAMINE LAMP” will work. You can say, geez, if you know what the player means why not accept it – but I don’t necessarily buy accept every newbie command as a figure of merit. IF inputs have lots of mandatory prepositions, and they’re mandatory according to an English-like structure, not a what-people-have-ever-tried-typing structure.
Of course Aaron and Emily did playtesting research for this stuff, and I’m basically making it all up out of my head. So there’s that.
I agree with Zarf here, but would add that providing a modern user experience can be helpful as well.
Instead of a “>” and a blinking cursor, there are many things we can do to help the user move forward without panicking. We’ve started looking at these things (I’ve been at it for nearly a decade). Sadly, no one has really solved this problem…yes.
David C.
plover.net/~dave/blog
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.