intfiction.org

The Interactive Fiction Community Forum
It is currently Wed Nov 22, 2017 8:03 am

All times are UTC - 6 hours [ DST ]




Post new topic Reply to topic  [ 21 posts ]  Go to page Previous  1, 2, 3  Next
Author Message
PostPosted: Fri Jun 05, 2015 5:02 pm 
Offline

Joined: Sun Apr 18, 2010 3:58 pm
Posts: 770
matt w wrote:
I'm a little inclined to make it an option rather than a default, because there are a lot of games that use the first "look" as the second half of the introduction.

In fact, I think it'd make more sense to have the default be that the teach looking rule happen a few turns in (if the initial looking action is on) rather than right away--usually the purpose of LOOK is "I've been doing stuff for a few turns and what's the room description again?" so it makes sense to teach it when a little time has elapsed after the room description has been printed. What do you (or anyone else) think?


It's hard to know when the player needs to re-describe a room. By introducing "look" right away, you don't have to solve that problem at all; the player is in complete control.

_________________
At Choice of Games, we sell long-form choice-based interactive fiction games. We're looking for writers, paid in advance.


Top
 Profile Send private message  
Reply with quote  
PostPosted: Fri Jun 05, 2015 5:55 pm 
Offline

Joined: Sun Apr 18, 2010 3:58 pm
Posts: 770
More broadly, my claim is that "examine" can teach you all the commands you need via object descriptions, except for one-word commands, especially "look," "inventory," "help," "save/restore/undo", and perhaps "wait."

That means the tutorial has a special responsibility to teach one-word commands, especially "look," because then the room description can teach "examine."

The next hard one-word command is "inventory." The easy path is where the player examines something portable, where the description suggests that you "take" it. Then "take" can teach "inventory."

But some games have important inventory before you take anything; in those games, "inventory" needs to be brought up randomly, probably a few turns in. (Maybe suggest "examine myself" so it's not such an unfamiliar command.)

The tutorial should certainly suggest "inventory" when players take something or examine themselves, and should probably just blurt out "inventory" or "examine me" after a number of turns.

So! "Look" and "help" first. "Look" teaches "examine." "Examine" teaches all other commands, including "go" and "take," and hopefully eventually "inventory."

"Help" should remind the player of "look," "examine," and "inventory," and introduce the other one-word commands: "save/restore/undo" and "wait."

_________________
At Choice of Games, we sell long-form choice-based interactive fiction games. We're looking for writers, paid in advance.


Top
 Profile Send private message  
Reply with quote  
PostPosted: Fri Jun 05, 2015 10:28 pm 
Offline

Joined: Tue Mar 09, 2010 2:34 pm
Posts: 5116
Location: Burlington, VT
dfabulich wrote:
More broadly, my claim is that "examine" can teach you all the commands you need via object descriptions, except for one-word commands, especially "look," "inventory," "help," "save/restore/undo", and perhaps "wait."


That's a different approach than the one I envision for Tutorial Mode, though. I'd like Tutorial Mode to be something that has a semi-decent chance of working OK with a relatively small amount of tweaking when the author puts it into a game that they've already written without especially intending to gear it toward newbie-friendliness. If I put special emphasis on "LOOK" in Tutorial Mode and directed the author "You should make the description of takeable objects indicate that you can TAKE them," that would be the opposite of that--it'd require a whole lot of tweaking of descriptions.

(I would say that navigation commands are much more important to teach than any of the ones you mention, by the way.)

Quote:
That means the tutorial has a special responsibility to teach one-word commands, especially "look," because then the room description can teach "examine."


The problem with this idea is that if the first thing we do is teach you how to look, it makes it seem like looking is super important, and it isn't. It's kind of a relic of the days of BRIEF mode, when moving to a previously visited room didn't print a description, and you had to LOOK to remind yourself of the description. Reminding yourself of the description can still be important--especially in Gargoyle with that awful scrollback--but it's hardly a core mechanism of most games. Examining everything is, and that seems like a good thing to teach first.

Also there's the "making the author tweak the room description" angle. Also also putting tutorial commands in the room description seems like a bad idea for much the same reason as putting narration in the room description--the player will be stuck with it every time they LOOK or reenter the room. And if you're going to write something so it only prints the hint about examining the first time, or until you've examined successfully, you may as well just have a special tutorial rule to tell you about LOOK.

Quote:
The next hard one-word command is "inventory." The easy path is where the player examines something portable, where the description suggests that you "take" it. Then "take" can teach "inventory.

But some games have important inventory before you take anything; in those games, "inventory" needs to be brought up randomly, probably a few turns in.

(Maybe suggest "examine myself" so it's not such an unfamiliar command.)

The tutorial should certainly suggest "inventory" when players take something or examine themselves, and should probably just blurt out "inventory" or "examine me" after a number of turns.


Emily's already taken care of this! The extension as it is already suggests "inventory" if you're holding something, even if it's in your initial inventory. And it suggests "Look at me" immediately after you first examine something else. I think it makes the most sense to cue just plain "look" immediately after cuing "look at," though I definitely intend to include the Hadean Lands version (no initial description, "Look" prompted first) either as a use option or as something that I give code for in the documentation.

Quote:
So! "Look" and "help" first. "Look" teaches "examine." "Examine" teaches all other commands, including "go" and "take," and hopefully eventually "inventory."

"Help" should remind the player of "look," "examine," and "inventory," and introduce the other one-word commands: "save/restore/undo" and "wait."


I'm not sure whether you're saying that this is what the extension should do or this is what the game should do--does the description of the object teach all other commands, or are you saying that examining should unlock the tutorial bit for other commands?

If you're saying that the author should've written a response to "look" that prompts examining (in the room description or an after looking rule), and also that prompts you to GO WEST if applicable, and that item descriptions should explicitly suggest the other verbs, etc.--well, if the author has already structured their game that way, then there are about two things for the tutorial to do, and they can probably code them themselves just as easily as including the extension.

I'm not really trying to make something for authors who've already structured their game around a tutorial or other help--the stuff they've done already will be more useful than any extension. This is more intended as something that can help authors who haven't already designed a tutorial or anything similar.

I'm also a bit leery of putting rules for HELP in the tutorial extension--well, actually, I can't, because any actual rules I write need to be keyed to actions that are already defined, and HELP isn't a standard action. (Defining it in the extension would be a very bad idea; authors will have their own ideas about how HELP should work.) It'd be worth including as an example in the documentation, though.

Also you're definitely right that the line for teaching metacommands should include "undo." "Wait" is a tricky one--it's often completely useless, but if it's useful it doesn't have an obvious hook, so I think the thing to do is include it as a suggestion (or maybe as a rule that doesn't get activated unless a flag is triggered? Actually that seems like a good idea).

And I guess the parser error message, or some parser error messages, can teach "oops."


Top
 Profile Send private message  
Reply with quote  
PostPosted: Fri Jun 05, 2015 11:28 pm 
Offline

Joined: Sun Apr 18, 2010 3:58 pm
Posts: 770
Quote:
I'm not sure whether you're saying that this is what the extension should do or this is what the game should do--does the description of the object teach all other commands, or are you saying that examining should unlock the tutorial bit for other commands?


A little of both. Let me explain.

I claim that the tutorial should at least cover these cases:

  • When you examine a portable object, suggest: [You could try taking it by typing, "TAKE KEY".]
  • When you examine a closed door or container, suggest: [You could try opening it by typing, "OPEN DOOR".]
  • When you examine an exit, suggest: [It's to the west, so you could try going that way by typing, "GO WEST".]

Authors should be able to add their own. Ideally I could write a description of an apple and be able to write something like, "If tutorial mode is on, suggest eating it."

Maybe the author wouldn't do that for every edible object, (maybe it's a puzzle that you can eat the flower,) but the documentation should recommend that all/most of the relevant verbs of the game need to be either explicitly suggested by the tutorial or hinted at in the text.

Quote:
(I would say that navigation commands are much more important to teach than any of the ones you mention, by the way.)


Oh, they're critical! But we can ask/expect the player to learn about them by examining an exit.

_________________
At Choice of Games, we sell long-form choice-based interactive fiction games. We're looking for writers, paid in advance.


Top
 Profile Send private message  
Reply with quote  
PostPosted: Sat Jun 06, 2015 6:10 am 
Offline

Joined: Tue Mar 09, 2010 2:34 pm
Posts: 5116
Location: Burlington, VT
dfabulich wrote:
Quote:
I'm not sure whether you're saying that this is what the extension should do or this is what the game should do--does the description of the object teach all other commands, or are you saying that examining should unlock the tutorial bit for other commands?


A little of both. Let me explain.

I claim that the tutorial should at least cover these cases:

  • When you examine a portable object, suggest: [You could try taking it by typing, "TAKE KEY".]
  • When you examine a closed door or container, suggest: [You could try opening it by typing, "OPEN DOOR".]
  • When you examine an exit, suggest: [It's to the west, so you could try going that way by typing, "GO WEST".]


OK, this makes sense--with the caveat that usually exits aren't things (unless they're doors) so there isn't a hook for examining an exit. It might be a good idea to include a prompt for examining a direction, though.

I'm also a little unsure about the proper order here. Do we want to teach "look at this--now you can take this--now you can do inventory--now you can drop it, if you like--oh by the way you can also look at yourself and other things" or "look at this--now look at that, because you can look at lots of things--now that first thing you looked at is something you can take"? I lean toward the latter, though both should be made easy.

Code:
Authors should be able to add their own. Ideally I could write a description of an apple and be able to write something like, "If tutorial mode is on, suggest eating it."


This is a great idea. There's definitely going to be a hook to test "if tutorial mode is on"; maybe I could make it easier to suggest eating by writing a phrase to run one of the teaching rules.

...after a quick attempt, this will be a little tricky--I probably have to set up some variables that allow the author to force a favored thing (as it is, there's no way to tell it that we want it to specifically suggest taking the rock). I'd also need to include a hook for telling it "Skip the checks and make this suggestion anyway."

Code:
Maybe the author wouldn't do that for every edible object, (maybe it's a puzzle that you can eat the flower,) but the documentation should recommend that all/most of the relevant verbs of the game need to be either explicitly suggested by the tutorial or hinted at in the text.


Hmm, I think this is an aesthetic choice. Authors might want to try to set up an understanding that you should be able to type an obvious verb for something--set up an expectation that if you see a button you can push it, if you see a pie you can eat it, if you see a roulette wheel you can spin it. The first problem is teaching the verb-noun syntax.

Quote:
Quote:
(I would say that navigation commands are much more important to teach than any of the ones you mention, by the way.)


Oh, they're critical! But we can ask/expect the player to learn about them by examining an exit.


Well, there's the issue here that there usually isn't an in-game exit object to examine. One thing that seems like it might be useful is to include an option (on or off by default?) to have mentioned adjacent rooms be examinable and suggest going, unless they're excluded.


Top
 Profile Send private message  
Reply with quote  
PostPosted: Sat Jun 06, 2015 9:52 pm 
Offline

Joined: Wed Nov 24, 2010 9:55 pm
Posts: 616
All of this has to run as a global, every turn rule, because it should be able to prioritise and not overwhelm the player. This is undesirable:

Code:
> examine pierogi
The pierogi looks much like other pierogis you have known.

[You could pick it up by writing TAKE PIEROGI]
[You could eat it by writing EAT PIEROGI]
[You can see what you're carrying by writing INVENTORY]


It should also be able to delay hints to be deployed later, after more urgent hints, and just generally pace the tutorial. It's probably also desirable to introspect the player's commands to make inferences about how the player is going; if the player is clearly exploring the game by themself, producing well-formed commands, it might be desirable for the tutorial to shut up for a while.


Top
 Profile Send private message  
Reply with quote  
PostPosted: Sun Jun 07, 2015 8:09 am 
Offline

Joined: Tue Mar 09, 2010 2:34 pm
Posts: 5116
Location: Burlington, VT
Sequitur wrote:
All of this has to run as a global, every turn rule, because it should be able to prioritise and not overwhelm the player. This is undesirable:

Code:
> examine pierogi
The pierogi looks much like other pierogis you have known.

[You could pick it up by writing TAKE PIEROGI]
[You could eat it by writing EAT PIEROGI]
[You can see what you're carrying by writing INVENTORY]


It should also be able to delay hints to be deployed later, after more urgent hints, and just generally pace the tutorial. It's probably also desirable to introspect the player's commands to make inferences about how the player is going; if the player is clearly exploring the game by themself, producing well-formed commands, it might be desirable for the tutorial to shut up for a while.


I agree--as it stands the Tutorial rules run as a separate rulebook rather than an every turn rule and you put "rule succeeds" when one prints its tutorial, so only one of those runs a turn.

(Maybe it'd make sense to give them default option success, so that when one doesn't apply you write "make no decision" but otherwise you just let it go? Or maybe the author should specify "rule succeeds" themselves? Not sure. Changing this would break backwards compatibility, but I'm not too worried about backwards compatibility unless someone requests it, since it's not clear that anyone's using the old version.)

It also orders hints. One thing that I want to do is give more hooks for having tutorial rules run and not run, which would help with pacing. A sort of "teach compass directions once the player has pushed the button" thing. Introspecting commands might be desirable but difficult, and also tricky to customize. I don't want to overwhelm the author--it's important that this be something that can fit into games with a relatively small amount of customization that can be adapted from examples, or it'll just wind up being as much work as rolling your own tutorial. Also I think

Handling parser errors will be very important, though. The player who is typing "what do I do now" is the one we really need to reach. (I was going to say something about "You're my only friend in this awful town but she was doing fine with the syntax, the problem was more having a big map to wander with one puzzle to advance and getting brickwalled on the puzzle. One for the "Don't start people on Anchorhead" files.)


Top
 Profile Send private message  
Reply with quote  
PostPosted: Wed Jul 22, 2015 4:34 pm 
Offline

Joined: Wed Jul 22, 2015 4:25 pm
Posts: 1
I have a nit-pick with Tutorial Mode and the take-worthy adjective.

The rule, in version 5, ends up suggesting (during play) that the player attempt to pick up a worn item. It's not the end of the world, but is probably not what was originally intended. As per documentation 3.20, carried and worn are not the same.

Unfortunately, the composition of the take-worthy definition makes it hard to add an additional clause to it.

So adding,

if it is worn by someone:
no;

would be great, at would reformulating the rule to be more extensible.

My temporary workaround is to ensure that inventory is taught first, so at least the player will have seen the item suggested to be taken.


Top
 Profile Send private message  
Reply with quote  
PostPosted: Wed Jul 22, 2015 8:46 pm 
Offline

Joined: Tue Mar 09, 2010 2:34 pm
Posts: 5116
Location: Burlington, VT
Thanks for the suggestion. I am way behind on getting started on updating this--I need to learn to Github so I can have it up in a reasonable way--but I will definitely add that clause as part of the first update.

(Plan: The first update will just fix a few easily-fixed bugs--the opening doors one and the initial look bug that I've mentioned. That should be doable very soon after I get this rolling. Then I'll work on doing some reordering of hints, like pushing the suggest looking rule later on, and then maybe try to work up some more examples. Then probably some stuff that involves refactoring the rules so the author can force prompting specific actions with specific things.)


Top
 Profile Send private message  
Reply with quote  
PostPosted: Tue Nov 17, 2015 8:23 am 
Offline

Joined: Tue Aug 12, 2014 7:56 pm
Posts: 1668
Nit-picking, which actualyl came up when I was trying to use the extension.

I have more than one PC in my WIP, so right at the start of the game I removed "yourself" from play and set the player to be, let's say, John.

When I fired up Tutorial mode, it would stick on "There are other things around here that you can look at too, if you like. You can check out other things in your surroundings, or LOOK AT ME to see yourself.". And *it would not let go* even after X ME many times.

Diving into the extension I quickly realised what happened - you use "yourself" a couple of times. Maybe you'd want to use "player" instead?


Top
 Profile Send private message  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 21 posts ]  Go to page Previous  1, 2, 3  Next

All times are UTC - 6 hours [ DST ]


Who is online

Users browsing this forum: No registered users and 2 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group