In a blog blog post http://emshort.wordpress.com/2010/06/07/so-do-we-need-this-parser-thing-anyway/, Emily Short talks about the question of whether or not natural language parsers and the difficulties associated with both writing and playing these games. She suggests that the freedom associated with natural language requires a large amount of effort to cover all the weird stuff people might try to do, and the difficulty of figuring out how to do the simplest of tasks might be turning away people who are totally new to these types of games.
I agree with her to the extent that for most situations, the natural language parsers we have available today are more than sufficient and that the writers should help cue the players and guide them toward making better word choices, but that there is some value for a certain amount of menu listings where the language might become a little less obvious.
What I think might work, would be, for these parts, a list of responses that would be listed in menu fashion, but there could be some options that aren’t listed. These would not have to be parsable choices either. One advantage of this, would be that we could actually incorporate subtlety or complexity that is just too difficult to capture using the normal TADS parser.
Has anyone given much thought about this? If so, have you come to any conclusions for or against it, and do you have any suggestions about how to best approach setting up the choice systems? I have some ideas, but they will require adding some callbacks into the parser (though, that looks to be setup pretty nicely…thanks MRoberts! ) If anyone knows of some ways that I have overlooked that are already functional, that would be great.
If you give players a menu of choices, many of them will fail to realize that the menu is not exhaustive. They’re likely to miss anything that you don’t put in the menu. If it’s important to the game, you’ve just created an unfair puzzle. If it’s not important to the game, you’ve put a lot of effort into something that few of your players will ever see.
I’m with Jim on this. Hybrid input is probably not a great or elegant way to go, although there could be exceptions if the ‘choice’ situations are sharply contextually differentiated from the parsed situations. Plus, I feel that people who really want to provide as fun an experience as possible rather than just express themselves while saving themselves work, would probably choose to create a fully parsered game, because It’s just more fun to play, when done well.
Is it harder to program? Yes it’s way harder to reach general competence at it and that is never going to change – Emily’s totally right on that score – but it’s not pointlessly difficult. It’s more difficult because that’s what it takes to create an open-ended-feeling experience. The difficulty is not in the system but in the goal, which Emily also pointed out. But it isn’t just parser games: many, many types of games set the goal for themselves of pretending to a kind of player freedom that is actually a lie. It’s not the parser; it is setting up a lot of smoke & mirrors that makes things difficult, not any particular system or input. But the smoke & mirrors are there for a reason; without them you can see the gears turn, and that just makes the game element feel much, much weaker. Open-ended-feeling experiences are just more fun in my book: so for a game designer (if not for a literary author), I feel they are simply a worthier goal, whether achieved by parsed input or 3D modelling.
[EDITED TO ADD: An interesting comparison. I’m sure a 3D modeller’s job would be so much easier if they could just have people click whole buildings to enter and enemies to attack or interact with, and dispense with all the inch-by-inch simulation and all the letting players run into walls and whatnot. But they don’t dispense with this. In fact, the more epic games employ legions of beta-testers to run into walls over and over to make sure the ‘running into walls’ effect never glitches. Why go to all the trouble? Why not just provide three arrows that lead down three halls and have the player click them, all the faster to get to the cinematic cut scenes? The answer to that is the same answer as to why I prefer to put my design efforts toward parser-based games.]
Although please note I am not saying that CYOA isn’t fun b/c it definitely can be, but it seems systemically underpowered in that department, and tends more toward the artistically expressive side than the ‘fun’ side, at least judging from the examples I’ve seen which are by no means exhaustive.
Yeah. I guess the only way hidden options might work should be to have a very clear syntax for the commands. So, maybe the explicit options might be the two main, most obvious choices, but a clever player might try changing the command slightly.
And by non-parsable, I just mean examples like my telephone inquiry. Call bob is only parsable if Bob is in scope. But, in general, if bob is in scope, I wouldn’t need to call him. And once I do have the call established, I’m looking at doing some crazy stuff to simulate a satellite network of sorts:) If I could just present a menu when you clicked on the phone that said: Call Bob or Call Bettie, then I could be mostly done with it (well, assuming that I establish the communication stuff). A clever player might also be able to Call Horatio, but only if they have found his telephone number (i.e. Call Horatio First adding Horatio to your contacts. Calling Horatio). The idea being that the menu was presented to the player as a menu from the phone.
Other types of options might be a little less suitable for hidden options, since the choices could be so varied. What if you are carrying a weapon, and there are three of you trying to make it out of some war torn place and you encounter enemies. You could let the player shoot at one or two enemies and then run, but to me, it might be more interesting to have options such as:
Run
Hold them off as long as you can
KILL THEM ALL!
I think these have more interesting meaning than “shoot at enemy” or whatever that would be. I mean, TADS isn’t really designed for some types of interaction, and I think you could handle the scene with more text than interaction once you established how the player wanted to proceed. Or maybe people would prefer typing the same command in 3 times and then typing run?
You could do this with a conversation node, I guess. But there are probably times when there wouldn’t be an actor to talk to when I could imagine it would make sense.
There is an existing “menus with additional non-visible inputs” system, called Adventure Book (by Jon Ingold). You could either pick one of the choices displayed, type the name of an object in inventory to try to use the object, or type a magic word, and if the situation was appropriate, the magic word or item would be an additional choice.
I’m not sure if the original Adventure Book system is available anymore, but there are both Inform 7 and (I think) TADS extensions written to provide the same functionality.
That is a perfect situation for a menu in a parsered game – one in which the main character is actually looking at a menu. However, I still kinda prefer to type the command because – well I don’t know how to describe it but there is a kind of ‘decision cost’ to frequently changing the input paradigm you are aiming at in your mind. So I think double input styles would work best if they were entered into different windows – for example, a clickable map window beside the text window, as in Quarterstaff. Then they become clearly compartmentalised in your mind: you will never click in Window A, and you will never type in Window B. You could maybe achieve a minimal kind of compartmentalisation with coloured text.
All three of those strategies are easily achievable in parser form, by 1) picking an exit, 2) typing ‘parry’ or ‘block’ repeatedly, 3) typing ‘kill’ repeatedly. In my opinion it’s better to express emotions in the text responses to the player’s lego-like assembly of different practical choices, rather than inserting emotions into the choices themselves, but there is a definite school of thought that disagrees. This could be the crux of the CYOA/parser debate.
What I prefer is to assemble a strategy tactic by tactic, and have the game pick up on it, rather than choosing the overarching strategy and having the game fill in the details.
The above being said, I don’t yet know whether using Versu’s conversation nodes for combat etc. would work for me, because I’m not familiar with their technical capabilities.
P.S. I tend to make sure my main NPCs are always in scope, anyway, regardless of whether they are actually in the room, so that I can make error messages more intelligent.
) If anyone knows of some ways that I have overlooked that are already functional, that would be great.