Emily Short -- Down with Parsers!

Authoring General Design Discussions
46

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

47

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

48

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

49

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

50

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

51

The crash happened in IE8 running in Windows 7.

52

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.

53

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.

54

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

55

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.

56

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.

57

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.

58

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).

59

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

60

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.

61

Does that mean your HTML extensions are also like to have number rather than string IDs?

62

That was the original plan from a year ago. (Although that assumed some language support so that the I7 end user wouldn’t be writing code with numbers.)

63

cool. Both this discussion and the linked ones, many good points from both parser advocates, parser detractors and trolls.

sounded like “Super Smash IF Authors Mellee” :laughing:

I have a smartphone now. Although zippy is an interpreter for zcode by Google itself for Android, it sadly does not support the swype virtual keyboard input method. Swype is nothing short of amazing and I can quickly write with it lots of text here and in other forums with ease by swyping over letters to form words rather than type them. So, as far as zippy is concerned, it’s not quite as joyful to play IF on mobile as it is to click on choices given by CYAO works. Parchments works fine with swype though, it’s just lacking some screen adjustment: you often have to scroll new text down yourself and even scroll right.

I like the parser and I like command lines. What I don’t quite like is the limited common set of verbs every IF has. Not only are they limited and limit gameplay to essentially collect and unlock things and explore around in cardinal directions but also further, those verbs really don’t handle natural language: how many times have you seen things like “take the bus”, “get out”, “take shower” lamely failing for the parser inability to handle NL ambiguities and the author not programming replies to such sensible actions? I know you can create new verbs in Inform 7, but making them handle ambiguities of NL is still a pain.

Sometimes when I’m sketching some IF idea, I do something like:

quiet|calm down|tranquilize dude|fellow|guy
You try your best at shredding his fears.

I think a parser programmable via regular expressions would be great at handling complex human actions rather than strict one-shot verbs building and aliasing.

64

I’ve played IF on the Kindle and phone, and I think mobile platforms have the potential to open up IF to a new audience. What Em is saying is important to take into consideration. I think typing a noun (or on the phone touching the noun), and getting a list of applicable verbs would be an excellent solution for beginning players. But not spoilery (for lack of a better word) as to how they could solve puzzles (for example you still have to choose what to cut with the knife, or jimmy with the crowbar, etc). There is also the benefit of teaching the players to play traditional IF (once they’ve played one of these games through they will know what verbs to use, how to move around, how to examine things, how to think about puzzle solving). Especially if you have the parser retype the command in the proper order (eg. they select ‘sword,’ ‘kill,’ and ‘orc’ but it appears as ‘kill orc with sword’ in the game).

I’ve recently played a game (not sure if I should mention which, as it’s still in Beta-testing on the Kindle platform), but it has a drop down menu with “think about goals” (you can also type ‘think’) which is a useful addition to any long IF for beginning players (heck, even for experienced players). It doesn’t tell you how to achieve those goals, but just as a reminder (oh, yeah, I forgot about that dude, hmmm, I really should go and ask him about xxxx, kill him, ask for his daughter’s hand in marriage, etc).

I think including a map of (at least most) places in the game would also be beneficial for games intended for mobile platforms (like the kindle, but also ipad/pod, android tablets, etc), as you are not going to be at a desk with paper and pen to hand for making maps, and tbh, even as an experienced IF player I can rarely be bothered (games with large environments that require mapping just don’t get much playtime from me), expecting a new player to work out that they need to map, and making them want to, would be even harder. Of course you can still have secret passageways, and doors, etc - as long as the writer doesn’t go overboard the player should be able to remember where they are.

Just a few ways that IF could be made more accessible. I think Em’s idea of the drop down menu of verbs is a good one (though have no idea how hard it would be to code for this). If it can be made to work it will definitely make games more accessible, and I don’t really see how it will ‘ruin’ games. Sure, being able to type bizarre stuff and get a response is awesome, but not necessary for the enjoyment of most games I’ve played.

65

Oops, beaten to the punch. Said better too. Such a good way to teach newbies how to play.