A couple of clarifications on the last post, because there was a lot there, and some of the discussion is arguing against things I mentioned in passing rather than against my actual conclusions. So, to sum up:
- The answer to the question I posed in the title is yes. I do still want a parser. Something else would not be close enough to IF as I know it.
- In fact, I still want players to type. Clicking buttons or using drop-down menus (a) encourages a design with too few verbs and (b) removes the textual give-and-take. I also consider that an important part of IF. I also dislike the cluttered look of interfaces with a lot of menu and button stuff around the body of text.
- Indeed, I still want to accept standard-form commands such as OPEN DOOR, in that order.
- But the command prompt doesn’t give enough information to help players negotiate the command space. I think this a real defect in the current parser interface, as a matter of interface design.
- Therefore I think we should give the player a way to interrogate the game directly about what his options are. One way to do that would be the textual equivalent of clicking on something and bringing up a radial menu: that is, letting the player type a noun name and find out about his options for manipulating it.
Emily Short's Interactive Storytelling 
One thing I use a lot on the command line in Linux is the tab-key. If I type a few letters and hit tab, it tries to auto-complete the command.
Maybe this would help IF – type your verb and hit tab to find out what you can use it with. Some objects might need flagging with a ‘do not list’ option (if “push[ing] the sixth book” opens a secret door, you might not want to advertise that)
The reverse is harder, but you might just give them a generic verb like ‘use’ and let it return a list of possible (obvious) ways to use the object.
What about an autocompletion feature at the prompt ?. This feature will be sensible to all the objects in the player’s scope and the possible actions.
Also another solution could be the famous ‘Did you mean… ?’. The IF-system can try to match the player’s input to the DataBase and provide close suggestions that can achieve something in the world. The DataBase can also have stored common player’s input to the adventure, obtained from previous beta-testing and a common knowledge DataBase.
Using the autocompletion and the ‘did you mean…?’ any player input will trigger a meaningful response from the IF-system.
Some responses to your ideas in the discussion:
1) Yes, of course, some games do not apply to some of the proposed interfaces (Spider and Web, or yes we can? the verbal commands for the radio device are well defined in the instructions of the device, so an point and click interface would allow in Spider and Web to do: radio device -> talk to -> roger. And the marvellous puzzle would remain the same, because the word is not something the player must invent, it is an already well used command).
2) You keep saying that the parser has a problem of design as an interface. However, I didn’t seen (correct me if I’m wrong) any serious study in the matter using some of the solutions at hand (Dreamhold, or some of your efforts). Maybe you should try in the next PAX East?.
3) You said:
“After you’ve been through a tutorial and maybe learned the dozens of verbs that are standard in all IF, what happens if you forget some of them? What is there in the interface to remind you?”
I built a beginner system in the Spanish version of the programming example “the toyshop”. It was an early effort, and I don’t remember if I addressed that, but that it is true, my tester, from one play to another, they absolutely forget all the commands. So, it is a good idea to “restart” de tutorial after restore.
Me personally I did not detect any problem in the actual parser (although it is not powerful for PNJ interaction as the old good parser of level9 games); for me, any interface, if homogenic and well documented, it is ok as is.
4) The Spanish game shared before, I think it has the perfect interface for building phrases and actions, for mobile devices. However, that interface allow to build scenery objects, so the “lick moon” problem remains. It depends of the deep implementation of the model world made by the author. If the author decides to not to have scenery objects, an interface like this would work smooth. But… we have already seem parsers that has not scenery objects and works quite well. For example, level9’s ones: in games like Red Moon, there is a defined vocabulary, so if you do not define some scenery but the word exists in the dictionary, the parser answers like “That is not important for complete the adventure.” You could like it or dislike it, but as a design approach for a parser interface it is perfect.
5) You said:
“But the command prompt doesn’t give enough information to help players negotiate the command space. I think this a real defect in the current parser interface, as a matter of interface design.”
Well, there are multiples kinds of parser in the history. Actually, our parser tell if it has not understand a verb, or a noun, etc.
So, could you elaborate?, what kind of negative feedback our parser should gives the player in case the input is wrong? What examples of did you find of lacking in the responses of the parser?
Regards,
“But the command prompt doesn’t give enough information to help players negotiate the command space. I think this a real defect in the current parser interface, as a matter of interface design.”
Well, there are multiples kinds of parser in the history. Actually, our parser tell if it has not understand a verb, or a noun, etc.
So, could you elaborate?, what kind of negative feedback our parser should gives the player in case the input is wrong? What examples of did you find of lacking in the responses of the parser?
I think specifying not-understood nouns and verbs is fine — I actually think IF languages have mostly done well in developing feedback that indicates what part of the sentence is not understood. But that often leaves the player wondering what he should do instead. There’s the guess the verb problem — does the parser not know about *this particular* verb, or is the action itself just not in the world model? And then there’s the larger problem of working out where to start, how to make the game go forward, which can feel pretty bewildering to a player unless there’s both a very clear goal to accomplish and a clear (ideally short) set of known verbs to start out with.
For those of us that are programmers only of the core game, and not the infrastructure, I wonder if including a list of Essential Verbs for Completion, plus a list of Generally Recognized Verbs would be good for most works. Sort of like including an in-game map. Hard core players wouldn’t have to use it, and we wouldn’t have to train players to a new thing; it would just be something you could have open, or print out.
Alternately, I can imagine something like a extra description:
>INVESTIGATE DOOR
“You could push or pull the tarnished copper door, prop something under its handle, or polish it. That’s all you can think of at the moment.”
However, I can’t quite figure out the coding for automatically doing this. Some actions you’d want let the author elide, either until a certain stage of the game, or just for kicks – maybe the player can also PROP OPEN DOOR, but not until Act 2, when she has the mallet and the wedge.
This is clearly much more work than providing a list of verbs, though.
I’d definitely play with an extension, if it were out there.
I like the idea in theory, but it seems like it’d interfere a bit with puzzle solving: “OK, why haven’t I used the verb TURN yet?” Whether that’s an issue is up to you.
I’m imagining two scenarios when the player might want this:
– when they’re just beginning to learn the possibilities of the parser
– when they’re stuck
I imagine most players might skim the list for nonstandard commands, like PONTIFICATE, but most of the experienced people would just bumble through for as long as we could.
For stuck players . . . eh, if they want to look at a verb list before going to hints, I’m not too bothered. I mean, between that and the umpteen thousandth “I don’t understand the verb you’re using” responses, I’ll take a hint any day.
Besides, if the verb use is flexible enough, it could be possible to get away with using standard commands. Or, if the author feels pressured, an easier puzzle with a similar requirement (you have to TOUCH LIGHT SWITCH at some point before you TOUCH GOD.)
Clearly, it’s not right for all games, but I don’t think it would detract much from the majority of them.
I agree with your first three bullet points, and understand the concerns raised in the last two. I’m not so sure about the proposed interface, though that’s not to say it wouldn’t be worth experimenting with. (My principal concerns are that it might look a bit cluttered if there were many actions that could apply to a particular object, and that under some circumstances it might accidentally give away the solution to a puzzle, but maybe these concerns are both addressable.
I’m experimenting with a somewhat different (and probably rather more conventional) approach in my current WIP (which is progressing rather slower than snail’s pace at the moment due to work commitments), namely to attempt to track how many commands the parser is rejecting and then step in with a hand-holding tutorial once a certain error threshold is crossed (this is basically a development of the system Jim Aikin and I used in Mrs Pepper’s Nasty Secret). I appreciate that you mentioned this kind of approach in your original post (at least, I seem to recall you did), but I do think it’s another approach to the problem that is at least worth exploring a bit further. One potential advantage, at least to my taste, is that it doesn’t involve any departure from the command-line interface at all, so may give a more consistent look to the game. In it’s current iteration it also tries to give fairly clear instruction (by example) of what forms of command
are likely to prove productive.
– Whatever it is would likely have to be completely metagame. Someone in the other thread mentions that few real people actually look at, say, a dictionary (first thing at hand) and think “Hmm. I can LOOK at this, or I can READ it, or possibly THROW IT AT SOMEONE…” And I can’t think of a single way (granted, I haven’t thought hard) to put this into a voice that isn’t of that obsessive over-analytic character type.
– On a related note, I think it’d help to have more strict delineation for what’s metagame and what’s not. Right now, parser error messages and default responses get dumped into the same place as story text, and I think that’s the source of a lot of player confusion. Especially when they’re new or the story uses an unfamiliar extension, they don’t know whether a “I don’t understand that” command is the result of bad syntax or something they just can’t do or what.
– And then the other thing — quite a few of the default verbs apply to quite a few objects, and just leaving them out of the automatic list for clarity either runs the risk of spoiling (“hey, why is HIT in this list?”) or limiting player interaction. Because let’s face it: when presented with a list like that, people aren’t going to be as likely to realize there might be other options. It’s like that old puzzle about having two coins, one of which is not a nickel.
The character voice thing is troubling.
I don’t know. I generally feel like the verb thing isn’t a biggie; if it is, it’s a fault of poor design/writing choices. Usually I have the right verbs, but can’t figure out that they’re appropriate. Why is “You can open the dictionary, throw it, or look up a word.” better than “The dictionary weighs heavily in your hand, practically bursting with words you can’t spell.”?
Poor writing aside: the description hints at options that may not be possible, like SPELL. It may not adequately hint at options that are possible, like THROW. The first is easily tested; the second could emerge later. (Does everyone reread object descriptions when stuck, or is it just me?)
I’ve never looked at a book and considered all the verbs I could do to it, but when we’re desperate, we do brainstorm and cast around for things; while I might not consider throwing a dictionary under normal circumstances, once the centipede emerges from under my monitor, if I look at the dictionary, I’m not going to think “Hey, I should look up the definition of ‘venomous’!”
In short, I think a lot of these issues could be solved by stronger writing, a sense of being in the character’s head, and in-game smoothing of the rough edges. But if people would find it helpful, it’s worth considering. After all, better writing and changing gameplay states are hard.
Bah, I hate it when I press “Submit” too soon.
The other issue with this is that it’s inextricably tied to objects, whereas not all commands are. This rules out Spider and Web, where the pivotal command takes no object, at least not the way I tried it. It’d rule out other things, as well.
Great discussion!
How about something like this:
> manipulate book
The book is a small lightweight object that can be picked up, thrown, dropped, or put into a container.
Is it also a text, and can be opened, read, and written on.
>manipulate window
The window is a functional part of the structure of the room, and can be opened or closed.
It is also made of glass, and can be looked through or broken.
The idea here is that the objects in the game are classified with like objects, or like materials, which all have the same associated commands. A beginning player will only need to check out a handful of objects before getting a clear idea of the commands associated with the common classes of objects. The word “manipulate” could be replaced with “consider” or “check” or maybe wrapped up into “x book”. It may sound a bit code-y, but in the hands of a skilled writer I think it could work and work well, and besides, it’s the way us real people operate in the world, albeit unconsciously.
“Hmm, this is a pretty small object. I bet I could GET it, DROP it, THROW it AT something, or PUT it INTO my bag. It’s also got something written on it, so I can READ it, or WRITE something ON it.”
With 10 or 12 of these standard responses, plus more for different materials, I bet you could cover the majority of objects.
Two thoughts:
I don’t think anyone has mentioned this yet, but the parser can be pre-filled. Can this be used to our advantage, perhaps to suggest an action, but while still leaving it possible to do something else entirely?
I felt that the hinting in Alabaster was done on the whole very well. I played/read it with a friend who hasn’t done much IF and they were quite comfortable with it. While knowing what actions are possible may be hard, (“I can see items but don’t know how to manipulate them”) I think the bigger problem is not knowing how this fits with making the story progress, and trying everything is of course, boring! So my unfounded theory would be that a hinting-interactive-walkthrough thingy would be of the most help. Perhaps with the first few moves being put in the parser buffer automatically.
This feels way too rose-colored, hardcore for me. If the goal is to make IF broader (correct me if I’m wrong), then the parser IS the problem. People need training to reach the comfort level we have. And while it’s natural to type sentences, the parser doesn’t actually handle sentences very well. It’s a specialized language, that as Emily points out, is actually pretty tricky to fill out enough that it doesn’t betray the user’s expectation/intentions. And IF is often betraying the user intentions (but not always!)
The best demonstration I saw of this was with Facade, which was a new parser that everyone was unfamiliar with. People would try things, it would try to respond, people would get a response that betrayed their expectation, repeat 3x times, walk away.
It’s fine to stick with the parser. It’s definitely a unique interface. But the parser itself is the limitation. It has little training ramp. What affordances it has (typing) are first-time applied wrongly and don’t lend themselves to learning the right way. And as you pointed out Emily, the right way is itself somewhat primitive and arcane. Think of how much automation has gone into the parser over the years to remove the tedium of it, and that’s only removed the simple stuff.
I say this to be encouraging. The parser is what makes IF, at least right now, unique. The parser is a crappy interface, but all interfaces are crappy, and only some are unique. Embracing your constraints is what allows you to push past them. What Emily is proposing, I think, is a new level of parser automation. But to design and target that automation it feels important to understand what that automation is trying to solve. It’s trying to be affordant, without being comprehensive.
A little late to the show, but I have a new post at my site with some mock-ups of interactive story interfaces without a command line. The next step would be to make a working example story, I’m hoping for input from the community.