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:
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?
If by good you mean effective, I’d have the game print
“DEAL, SUCKER!”
-Wade
I think by “good” I meant something more like “graceful”. The tutorial curtseys and glides off-stage?
I think we’re getting a bit ahead of ourselves here, with mandatory tutorials and whatnot. Making a tutorial is hard, and it’s easier to get it wrong than it is to get it right. It’s by nature something that can’t be solved without feedback from newbies, and it’s very hard to find those (and once you’ve found them they’re basically useful exactly once because the quality of the feedback drops immediately after they’ve learned how the thing works.)
So I would prefer that there was some kind of well-designed and researched guidelines before pressuring authors into making something that nobody really knows how to do well. And yes, I agree with Doug in that “people familiar with IF” is a valid target audience and everyone should be free to choose it without being scoffed at.
If something were to be made mandatory I’d much rather see accessibility be that thing. Even the best tutorial is worth nothing if you can’t play the game in the first place.
I think it’s worth revisiting a question Caleb asked earlier: Is lack of interactivity a dealbreaker? The way I see it, static instructions could fit Carolyn’s list of ideals and not be overwhelming for the average author (the Basic Help Menu extension, for instance, plus an opening prompt asking players if they want help). There’s a big difference between expecting authors to include instructions, and expecting them to include a tutorial mode.
And what “expectations” means also makes a big difference. Are we talking “You are encouraged to include a tutorial” or “You are strongly encouraged to include a tutorial (and if you don’t, you can expect people to react unfavorably to your game)” or “You are required to include a tutorial” or “You are required to include a tutorial and it must meet all of these ideals”?
Inventory is a bad verb–but “what am I carrying” would create an immense guess-the-syntax problem if it weren’t suggested explicitly, and if it were suggested explicitly would create misleading expectations about the kind of command that’s understood. I think it’d be better to think of a new verb that’s a verb, or just swallow hard and explicitly suggest “inventory.”
“Congratulations, you have now completed your adventurer’s training! Type (whatever) to close the tutorial.”
I personally dislike the Basic Help Menu, because the menu navigation feels very clunky to me. But I don’t think that’s a common opinion.
I’ve been advocating for an interactive tutorial because, in my professional experience, they’re much more effective than static instructions. (This is verifiably true for graphical games, and I don’t see why it would be different for parser.)
But - I’ve reconsidered my original position, and I have to agree that not every game will work well with an interactive tutorial, from a design perspective. I think static instructions could be okay, as long as they’re offered proactively and include all the tools that a new player needs to play the game in question.
(But an interactive tutorial would still be better.)
I was thinking “You are strongly encouraged to include a tutorial (and, if you don’t, you can expect some people to react unfavorably to your game).” It seemed to work well for encouraging people to beta test.
That was my original idea for this thread - a community effort toward researching and designing what a better parser tutorial would look like.
But the overall opinion (or, at least, the one I perceived) was that we already know how to make the best possible parser tutorials, and that there are several examples of games with such tutorials. And when I suggested creating an extension, the response appeared to be that we already have an excellent tutorial extension, so that would be reinventing the wheel.
If this isn’t the overall opinion, then yes, I’m all in favor of dropping back a step.
Good morning! The problem I have with the above is that beta-testing makes for a better game. Tutorials, as agreed, don’t fit every game design and have a totally different function. I would personally not like to see games reacted to unfavorably because they didn’t include a decent tutorial.
I agree about the menu navigation. I’d like to see an extension that offers concise instructions in response to HELP without relying on that style of menu navigation (or menus at all). It’d be something easy to drop in that could also be used in addition to a tutorial mode–it wouldn’t necessarily have to be either-or.
I definitely think there’s room for other extensions, but there’s a question of, how similar would a new one be to an existing one, and if it’s very similar, would it make more sense to modify the existing one. But it’d be nice to have a range of options. I like’s Emerald’s idea of a more minimalist tutorial.
My problem with it is that it’s just not true, or at minimum extremely misleading.
Actually, I think a lot of people dislike menu navigation. I certainly do – but when basic help menu was first written, that kind of menu was nonetheless a pretty common feature of IF games. I’d much, MUCH rather see some kind of native-feeling menu at the level of the app or appended in the browser in some way.
Which makes me wonder, what if we’re trying to solve this problem in the wrong place? What if there were a standard frame for Parchment that included a help menu/help text outside of the parser navigation box entirely? This might a) look better; b) be easier to make conform to accessibility needs; c) allow the player to leave a help text/pop-up open while they play rather than constantly needing to type HELP again and lose the thread of their transcript?
This wouldn’t replace a built-in interactive tutorial, but I think it would be better for the external-text approach. (And then we might also consider whether there are other features we might want for this. A “Comment on this game” option? “Review this” link to IFDB?)
To continue this train of thought…
there’s also a question of, if it’s not being used, what does that say about its ability to meet the needs of authors? If it’s too difficult or involved or time consuming for at least some authors to use, then maybe it’d be good to have other options.
Would this help text be custom, or built-in?
It might be diegetically (Or, rather, nondiegetically) better, actually, if the help text was a bubble or widget that floated over the text rather than part of the flow of text itself. It would also make it visually more recognisable as a tutorial message, and would supply an obvious place to put a “dismiss tutorials” button. Definitely a thing to consider in Quixe/Parchment.
Leon Lin’s “The One That Got Away” has an example of what I was talking about, a non-interactive transcript that’s sort of halfway between an external help file (which would be annoying) and an interactive tutorial (which I agree would be awesome, but feels sort of out of my grasp design/coding-wise.)
Basically, if you type HELP, the game tells you about an instruction pamphlet you’re carrying. You can then READ THE PAMPHLET to get a nice little transcript. I suspect Lin included this because the game has a lot of complicated fishing-related actions people probably weren’t expecting, and he also had the advantage that fishing poles might theoretically actually have instruction manuals, but I’ll bet something like this could be adapted to be show more basic commands and to fit other settings.
(In my game “Six Gray Rats” the player could read a passage of their Gothic novel which illustrates how to play, etc…)
Juhana - sorry, I was a bit confused by this.
Do you mean it’s not true that it worked well for beta testing? Or that it’s not true that people would react unfavorably to such a game? Or that it’s not true that encouraging tutorials would improve game quality/accessibility?
I’m imagining something with an overridable default. I mean, in fact it’s already possible to tell Inform to bundle up the postcard or a default manual as part of one’s exported Parchment-running website – or to attach a custom help text file or PDF of one’s own devising – but it might be a good idea to revisit this and perhaps rework it into something where the help is both more prominent and more elegantly laid out.