Emily Short -- Down with Parsers!

HA! It seems the IF community finally realizes what CYOA fans and programmers like us knew for ages, that parser-based systems are out of fashion! :unamused:

That’s why CYOA is the perfect bringer of the new IF style in my opinion, to give players all available options (choices) during gameplay instead of forcing the player to guess verbs. Text adventures should focus on the game experience itself and not on the boring process of verb guessing. That’s why I propagate CYOA since 2008! You all know about Node-X. You all know my policy. You know I’m right. :sunglasses:

This is so freaky. It reminds me of the 2002 scenario. For all of you who don’t know what this is… In 2002 a couple of techno music composers and especially I propagated on certain internet forums that Trance, which was very popular at that time, will get out of fashion and that Electro with all its subgenres (Electro House, Electro Pop) will become the new style in the techno scene. We made some enemies at that time and we were called trolls and whatnot.

But in the end we were right. We were alternative thinkers and had a vision. Everything happened as we have foreseen. Now you have Lady Gaga in the music charts making Electro Pop and mixing it with other styles (e.g. rock). You have DJ David Guetta playing Electro House in trendy clubs and all the party people going crazy about it.

The same will happen with CYOA and other alternative genres of Interactive Fiction. You will see…

Oh yes, they are. You want to argue with me again?

CYOAs are CYOAs. As their name says. Text adventures are text adventures. They’re related, but not the same. If they were the same, they wouldn’t need a different name.

I’m not trying to degrade CYOAs, mind you. Nor any other genre. I’m only saying that a “text adventure” is defined by its parser that’s accepting verbs and objects as input. Just because a CYOA uses text as its medium doesn’t make it a text adventure.

1 Like

Well, I can accept that. To be honest, it’s not that bad actually that CYOAs are not fully viewed as text adventures. Since the IF gaming scene is beginning to move on and the momentum is slowly switching, we should put CYOA under a different label. For instance, we could put it under AF (Alternative Fiction). People can coin another name for it. It doesn’t matter.

If you read what I actually wrote, I wasn’t advocating CYOA, in the end.

1 Like

Well, I’m new to genre and, as so, I think my two cents are worthwhile as someone that is not part of the community.

From what I’ve played so far, I think the parser isn’t the main issue. I was pretty much unaware of the IF convenctions (l to look at the room, x to examine, etc) when I started playing and, so far, I only felt the parser to be in the way when the game itself was poorly designed. Good examples:

Violet, by Jeremy Freese
It’s written in such a clever way! The hint system really works well and Violet herself is really good at pointing you in the right direction without serving you the solution to the puzzles. I think it’s a great game to start playing IF. I never felt the need to throw verbs at random and I never felt frustrated into giving up the game.

Blue Lacuna, by Aaron Reed
The way it handles the parser difficulty is brilliant! The different colors, the bold nouns, the suggestions when the player does nothing for a number of turns, etc, these are very inteligent tools that don’t get in the way of a veterane IF player, but that prevent the begginer from giving up. Also it does something that I found to be very clever: it takes the time it needs to hook the player without rushing him. What do I mean? Someone mentioned before that an IF work needs to hook the player in the first few lines - the game’s presentation, so to speak -, right before the player needs to write the first command and get frustrated, but blue lacuna proves this not so true. The first lines of the game won’t hook you, but the player is asked to give very simple commands at first, and the story breaks as slowly as the game’s mechanism. When one gets to the place where it has to solve complex situations, one is already familiar with the “way things work” - and hooked.

So, I think that what alienates new gamers is not the parser itself, but the way games are written - and most IF is written from and to people of the community, who share conventions that outsiders don’t know about; but if a writer want’s to, he can make an IF-traditional-parser-game that is non-IF-community-member friendly.

But such is not to say that the parser can’t be reinvented, and a funny example pops to mind:

Llama adventure, by John Cooney
The game itself has not seen the best of implementations, but I think it to be a nice (maybe something like what Emily Short had in mind?) way to handle the parser. Also, from what I’ve read in the commentaries, It has also been quite well accepted by non-IF players.

I would like to end this already long post with a note about verbs:
I don’t know all the verbs that a parser has stored for me - and I don’t need to or want to know! I expect the game to be natural enough so this isn’t a problem (even with not-so-common verbs!), and if it is I’ll surely give up*; but I think that a list of verbs, as in “Gateway”, can be as confusing as no list at all when the game is poorly constructed. Take graphic adventure games: some have a long list of verbs to click, and others only a few (or none, in some cases), and that doesn’t diminish the experience or the dificulty of the puzzle. I don’t have a stronger exploration experience just because I have twenty verbs at my disposal - mainly if only 18 give me an interesting feedback in 90% of the game. I don’t see why an immerse gaming experience, with tough puzzles, can’t be accomplished with a handfull of verbs. The exploration potencial must be in the scenery, not in the verbs; the dificulty of the puzzle must be in the puzzle itself, not in the way the player handles the game to solve it**.

[size=85]

  • As an example, I’ll use Short’s very own Savoir-Faire. The first time I tried the game, I gave up frustrated in the kitchen. Why? Because I downloaded the game, together with many others from IFDB, without reading much about it. I just started to play and I didn’t know that “linking” was a verb I could use. Only after playing other games and reading so much praise about S-F, I decided to read the feelies and then - only then! - I found out I could link objects. Then I noticed the “Type HELP even if you have played IF before” line. I didn’t see it before because it was in that “author, title, version” heading that I pay little atention to.

** Unless that is the objective of the author, as in Aisle: a game that lives (and very well!) of the player finding which commands result in resolutions for the plot.[/size]

Speaking as someone that is (at best) on the periphery of IF but would like to get more into both playing and writing, I have a couple of things to add:

  • I can say that the parser has been a huge turn off in my attempts to get more into the scene. There is nothing more frustrating than having solved a game puzzle long ago, only to have to then laboriously solve the “parser puzzle.” This is an interface problem for graphical games as well… really anything puzzle based.

  • I’m honestly surprised that the idea of a split-paned interface with separate command and output panes would be considered any one of: innovative, controversial or unusual. Maybe I spend too much time in text-based interfaces for programming but this kind of split between contextually aware command prompt/buffer and output buffer/pane has been around for a long time. I’m not trying to be critical, but this is exactly the interface I would have expected from a contemporary text-based game. Does this mean that I would have to code up my own interpreter to use this for my own games? Disappointing.

V

I feel the same disappointment, I think. The current authoring tools are strongly command-prompt-centric. The moment you envision a more 21st century UI, you’re pretty much on your own.

I’m a writer. I can’t draw. Any type of graphic enhancement of the UI is not going to happen in my next game, nor the one after that, unless (vanishingly unlikely) I happen to run into a graphic artist who has time to spare helping me implement my vision.

But I would happily embrace a more sophisticated text-only UI – something with the command prompt in one window, the output text in another window, maybe words in bold in the output text that can be clicked on, stuff like that.

Such a system is at least two steps away, I think. The first step would be an authoring system that allows me to set that up without too painful gymnastic gyrations. The second step would be an interpreter that can run the more modern UI in a seamless way. Both have to happen, and together. Either by itself is not useful.

TADS 3 has a nice hyperlink capability, for instance – but Zoom is not an HTML TADS interpreter, so in Zoom, a T3 game defaults back to text-only. The author does all that extra work, and then the player doesn’t even know it exists.

After trying a couple of games using Parchment, I’m drifting away from the idea that a browser-based interpreter is the right way to move forward. It’s just too darn slow! Imagine an FPS in which you pull the trigger and have to wait five seconds to see the result. Not good.

I’m starting to think that what’s needed is a new system that’s built from the ground up – a cross-platform interpreter with modern features, coupled with an authoring system that allows me to make full use of those features.

–JA

You can do all of these things right now with a Glulx game, and the results will be playable in both desktop interpreters and Quixe. Here’s a bare-bones demo with hyperlinks and dual-window I/O:

eblong.com/zarf/glulx/quixe/quix … Play+it%21

And here’s one that goes back and forth between single window and dual window I/O (type TURN ON TERMINAL):

eblong.com/zarf/glulx/quixe/quix … Play+it%21

–Erik

The latter game crashes. When I try turning on the terminal, I get this: “Quixe run: Error: Invalid argument. Invalid argument. Error -2147024809”.

I need to investigate Glulx further. My impression is that it’s rather primitive in some respects compared to a nice 21st century UI … and of course I’d need to work in I6, since the !@#$%^&* 6E72 release of Inform 7 IDE still doesn’t run on my Mac. (I emailed Andrew Hunter yesterday, asking about the status of this. Haven’t heard from him yet. But maybe he’s taking a well-deserved vacation.)

–JA

Could you give more details on your setup? I haven’t been able to make it crash in Firefox or Safari, so this is probably a bug in Quixe.

Thanks,
Erik

The crash happened in IE8 running in Windows 7.

I only recently (well, today actually) played “Ecdysis”, a 2007 game by Peter Nepstad:

ifdb.tads.org/viewgame?id=aqtol7ejlzadgnsz

I wasn’t aware of the way it presents itself. It’s almost identical to Walker & Silhouette, but you don’t click on keywords like in W&L, but on words and sentences. Clicking them executes actual meaningful commands. For example:

“Your side of the bed is soaked with sweat.”

Clicking on “soaked with sweat” results in an automatic FEEL THE BED. I like this approach. It takes absolutely nothing away from traditional IF. Yet new players don’t even have to understand the parser but can still experience it and, most importantly perhaps, learn about it. If they see the kind of commands generated by simple clicking, they soon figure out how to step in themselves from time to time if they feel like it.

In my opinion, it’s a very smart way to offer a full-blown parser yet unobtrusive ease of use at the same time.

Ecdysis was a big influence on me, but the issue I found with this style of game is that there seems to be a limited interest in supporting hyperlinks in interpreters (your QTADS is one of the exceptions). When I see a review of Ecdysis, I know it will fall into one of two camps: those who played it with hyperlinks and found it to be a smooth ride - and those who played it without hyperlinks and can’t understand why people are enjoying such a sparsely implemented, poorly clued game.

Assuming that you can jump that hurdle (e.g. by releasing the game through Quixe), I think you’re absolutely right. This is a great way to teach newbies how to form IF commands, while allowing them to progress through a game while they do so.

Pretty much all of the glulx interpreters support hyperlinks (aside from those designed for terminals). For typed keywords on any system, though, you could use the same interface used for supplying a inferred noun to show the player the whole command:

The new glulx feature that allows you to replace the text on the command line would be another option; perhaps something similar is also possible in TADS?

–Erik

I prefer how Ecdysis does this:

“Take plate” will appear on the statusline when the mouse is hovered over “plate”, so you don’t have to click first to know the command that will be generated.

It would be kind of cool if this happened as a tooltip in browser-based terps. I don’t know how hard that would be to generate, though.

Unfortunately, the hovering effect you describe is next to impossible with Glulx games: Hover behavior is not a feature of the VM, and even if your interpreter/Glk library shows a tooltip over the link on hover (as Zoom/CocoaGlk does), Glk represents the link as a number–and that number, which is pretty much useless to the player in nearly every situation, is what appears in the tooltip. It’s possible that with Quixe you could do better by using javascript to tack a title attribute on the elements as they are displayed, but I’m not familiar enough with Quixe’s internals (or the prospective javascript-game interface) to know how feasible this would be for the average game author at present.

This is actually not a feature of the TADS VM. It’s during output that the text gets parsed. For example, the above is achieved by the game by printing this:

<a href="Take the plate">plate</a>

The HTML Parser (and not the VM) will then print “plate” in the game window, make that word clickable, and generate a “Take the plate” command when the player clicks it and also show it in the statusline when the mouse is hovered over “plate.”

I suppose that to duplicate this with Inform, it would need to go into Glk (output layer), not Glulx (VM).

Well, the hyperlink system’s usability would be narrowed if the Glk layer insisted on treating links as texts to be entered on the command line. Currently, hyperlinks can represent anything that the author wants them to: the game just needs to convert the number returned into the appropriate value and do something with it. Most often authors do want a link to insert a given piece of text at the command line followed by a terminator–but certainly not always.

If hyperlink tooltips were added to Glk, one way it could be done is with an optional argument to glk_set_hyperlink that would display the tooltip on hover, while the absence of the argument would suppress the tooltip.

glk_set_hyperlink(12, "TAKE KUNG PAO CHICKEN"); glk_set_hyperlink(12, HyperlinkTip(12) );

This would have a minimal impact on the current functionality.

–Erik

Thanks for pointing out this aspect of the hyperlink model. I hadn’t thought about tooltips / visible targets.

Getting strings out through the API is a nuisance, but it’s clearly useful in more than one situation (arbitrary style names, for example). I will think more about this.