intfiction.org

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!

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.

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?

_________________
"An idea is like a virus. Resilient. Highly contagious. And the smallest seed of an idea can grow. It can grow to define... or destroy you."
INCEPTION Soundtrack - Dream is Collapsing

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.

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.

_________________
"An idea is like a virus. Resilient. Highly contagious. And the smallest seed of an idea can grow. It can grow to define... or destroy you."
INCEPTION Soundtrack - Dream is Collapsing

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

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


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

_________________
This is a block of text that can be added to posts you make. There is a 255 character limit.

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:

http://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):

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

--Erik

_________________
Glimmr: Advanced Graphics for I7
blog | download | bug-tracker

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

_________________
Glimmr: Advanced Graphics for I7
blog | download | bug-tracker