So, what are you looking for ?
- Story (Choice)
- Gamebook (PnC)
- Puzzle (Parser)
- Simulation (VN)
Note: There’s a humongous overlap between each style. There’s no right or wrong in personal preference.
I hear that, I totally bounced off ChoiceScript when I got to “Use a separate text editor OF YOUR CHOICE and then run it through the compiler” I was like whoa, back up, this is some serious investment here!
1 Like
Yeah, this is how I feel about it too. I think a lot of younger people love IF, just not the part where you fight with the parser. Especially with a lot of LGBTQ game devs, where Twine/Ink/Visual Novels are really popular because it allows them to talk about their experiences and feelings without having to struggle with the other expensive parts of video games like music and graphics. Or at least that’s been my experience with other game devs and as someone under 40
1 Like
Interesting. I think about it quite differently. More like a self-publishing book author writing their text in whatever editor or word-processor they prefer and then using other tools to create ePub or PDF or whatever. So my response is more like “What do you mean I can’t use an editor of my choice but have to put up instead with the whatever restrictive interface you choose to give me?” Hence my preference for an IF language rather than an authoring system in the strict meaning of the word.
I suppose it is down to the fact that these days you can feel at home with computers without actually looking “under the hood” of things. A bit like car drivers mostly don’t know what’s under the bonnet. Wasn’t true for my generation!
3 Likes
None of the above. Parser, yes, but with emphasis on exploration rather than puzzles. My ideal IF game would treat puzzles mostly as obstacles to make exploration more difficult and thereby more rewarding. Feel free to add a story line, just don’t make it too linear.
My approach to video games is similar. I love open worlds they can give me, but I am really not interested in either grinding or boss-battles.
6 Likes
So, I classify that under Simulation (Parser). I think I may have confused the message with the medium.
Medium: Choice, VN, PnC, Parser.
Message: Story, Gamebook, RPG, Simulation.
I try to order these by complexity, but the overlap is such, that I’m convinced it’s not linear but matrix of MediumxMessage.
Edit: and now that we know we can implement ScottKit (parser) with Twine(Choice), maybe the matrix idea is the correct one.
I can’t speak for @HanonO , but for me it was taking the output of one program and feeding it into another one that gave me the heebies. I now know that computers do this all the time, but back then I was a windows user. I used Word and Excel, and had no notion of how things worked under the hood. It was all “magic” as far as I was concerned. I’d never wanted to code before, but I was fascinated by the idea of being able to use a computer to tell stories. Unfortunately I was never interested in telling the sort of stories where you have to escape from a room using a postage stamp, a piece of smoked fish and a pamphlet on pyorrhea.
Link based engines, like Twine, organize the story space by offering branch points at significant plot points. Parser engines organize it by creating a fictional geography and then populating it with actors, which I find much more interesting. Unfortunately, while link engines have solved the problem of “stuckness,” it seems to be inherent in parser games, because the moment that the author and the player have different visualizations of the story it creates an unintentional puzzle.
e.g. the author intends the player to stand on the table and look out of the window, which reveals the key to the jackdaw’s cage hanging from a hook screwed into the frame. With a link game, the possible actions are explicit in the text, so it doesn’t matter if the author fails to clearly explain that the table is beneath the window, but in the equivalent parser game the lack of clarity in the room description can make the game unplayable without a walkthrough. Because the “puzzle” of what to do is unplanned, it’s also un-clued.
But I think two things might help. The first is making the objects that can be interacted with more obvious by making them into links would cut out much of the blind man’s buff of parser play that people seem to dislike*. The second is to help put authors in the player’s shoes. I really like the way that Dialog’s interactive debugger lets authors play through their game and add responses on the fly. This should greatly reduce the number of times that players get stonewalled by the default “You can’t do that!” response.
*Offering touchable links rather than requiring typing skills would help too, but is a separate matter.
3 Likes
Heh… me neither! And I heartily dislike that kind of IF. Nothing unfortunate about that.
But I disagree that the problem of “stuckness” is either inherent in or restricted to parser games. While a particular implementation may make it more or less likely, the real issue, I think is with the author’s mind-set.
Though I’ve only ever published two games (and both of them unapologetic Adventure expansions), over years I have seen hundreds or even thousands of player logs of my games and they were most instructive! Some players breezed through what I thought would be hard problems, but got stuck on supposedly simple ones. Some tried to do things which the game should have handled but that had never occurred to me – and that despite the limitations of verb/noun commands. Overall it taught me to have more respect for players and to look for ways of assisting them. Hence my preference for intelligent defaulting, forgiving parsers, automatic abbreviations and typo corrections. In short, I agree that doing one’s best to think like a player is crucial.
I take your point entirely about giving indication what objects can or cannot be manipulated. But I feel that making them into a sort-of link is not the way I would like to go. I have come up with two approaches to this issue. One is to give an option of listing game’s vocabulary – verbs and objects that perhaps could be manipulated and have been encountered by the player. The other was scenery matching. If a command word cannot be found in the vocabulary, look for it in text that the game produced since the last change of player’s location and if found, tell the player it’s just scenery. That originally proved troublesome, until I (a) switched off approximate and abbreviation matching for scenery word and (b) ignored all scenery words shorter that 4 characters.
3 Likes
I understand that. I think for some the actual appeal of parser is reading a description and sussing out which objects mentioned are valuable to interact with. Others want to know exactly what’s in play. It’s sort of like graphic games that have a “glint” on collectibles so the player doesn’t need to randomly click scenic debris hoping for interaction.
4 Likes
This.
Not the only appeal, certainly, but prioritizing objects in the description, building what-if images in my head about them and being surprised when an object that I had dismissed turns out to respond to interaction is a part of my enjoyment of parser games.
8 Likes
I firmly believe that we need to develop a categorization system to be able to meaningfully discuss IF, because the general category is so broad and inclusive that it obscures the reality that the things people want are much more specific.
Unfortunately, enough people have been conditioned with the reflex to reject anything ‘exclusionary’ as a matter of course; I lay the blame on the human capacity of non-self-awareness.
I intend to think the matter over a bit, then start a new thread about this.
4 Likes
There have been wrangles in the IF community that were rejected as exclusionary because they were exclusionary. It wasn’t great.
I think you will do better if you talk about the various elements which games are composed of, rather than trying to categorize the games themselves. Any specific game does several things.
7 Likes
I think that a story can be narrated well with a parser, especially if one can avoid guess-verbing…
… whose led me to an interesting proposal: what about a “ZarfSheetComp” ? that is, a competition based on using only the verbs in Zarf’s IF cheat sheet (albeit I think that lack TASTE 
)
(sorry for the bad joke, but I always think about that questionable cruel-grade marzipan cone in the DM, tasting it at least downgrade the marzipan to merciful…)
Best regards from Italy,
dott. Piergiorgio.
Yes. Personally I like carefully reading scene descriptions, X-ing scenery to get more info and slowly putting together an impression of the location. I like this sort of exploration. But I get that this is partly because to me, typing is a transparent activity: to me, wanting to look at the cherub and typing “x cherub” involves almost no effort, because I’m a keyboard basher. But that’s because I’ve spent thousands of hours hammering the keyboard. To someone who normally uses the mouse (or their fingertip) to navigate it’s not transparent. They want to explore the world, not this weird QWERTY thing (why aren’t the damn’ keys in alphabetical order so people can find them???)
That’s why I’ve suggested using links: they function as a form of emphasized text so that players don’t have to play blind man’s buff with the room description, and also as an alternative interface which requires no typing. Combine them with a scrollable “Verb strip” down one side of the page (which would also reveal the available verbs, as has been suggested elsewhere), and you have (most of) a parser’s functionality.
Of course there are a bunch of tweaks that would need to be added, e.g. how would a player conveniently use a peeler in their inventory to PEEL FRUIT WITH PEELER, but that’s the sort of thing that gets worked out as people use the MK1 interface.
The IF community has worked hard over the years to produce a more intelligent parser, so that the computer’s literal-mindedness about e.g. opening doors with the correct key gets airbrushed out once the puzzle has been solved, and we now take for granted things like implicit actions and smart disambiguation (e.g. “prefer held”) for granted.
I think it’s now time we turned our collective attention to the playing interface, that’s all. There’s already been a deal of good, quiet work there, so that players no longer need to download a half dozen different standalone 'terps, but the assumption is still that input is via keyboard. For the new generation of would-be IFers, this seems no longer to be their go-to interface.
Yes, particularly when I’ve gotten stuck, I’ve found it useful in games which displayed interact-able objects in a separate window: “Oh, right; the only things implemented in this jail cell are the door and the air vent, so I’ve been wasting my time using the chili paste on the window bars.” (As Mythbusters fans know, that was a jailbreak technique in real life.) Sort of a meta-hint, I guess.
2 Likes
Well, for me it was unfortunate, in that IF languages are geared towards creating games which center on manipulating inanimate objects in cunning ways. I was interested in telling stories, and stories have characters – which implies being able to code NPCs. I found the DM4 in particular wasn’t helpful about this.
TADS documentation was better, and T3 in particular had a lot of support for NPCs but I seem to have a non-TADS brain. My fault. Or perhaps IF’s version of the Windows/Apple divide! 
But yeah: all I really meant was that had I wanted to produce an Adventure or puzzle type game I would have been working with the grain of the languages.
Yes, that was what I was trying to say with the standing on the table example earlier. To the author, this was not intended to be a puzzle, it was game-world verisimilitude for looking out of a high window. But because the author and the player had differently imagined the relations of objects in that location, in a parser game it created an unintentional puzzle (the author’s fault for not explaining clearly enough, or not teaching the player about climbing up onto things.) In a Twine game, that lack of clarity would not create an unintentional puzzle, because the option of climbing up onto the table must be explicitly there, in the text, as a link. (If the link’s not there, it’s an unambiguous bug, rather than the more subtle sort of fail we’re discussing.) That was what I meant by this problem being inherent to parser games. But I agree, it’s not restricted to them.
Re: scenery matching, in inform 6, adding vocab words to a room results in the parser responding to any of those words with “There is no need to refer to the overmantel during the course of this game.” This is economical in its use of memory and processor time, a necessary consideration for z5 and z8 games.
In I7, the sentence “The overmantel, the ornate mirror and the aspidistra are scenery.” is valid code, and will (okay, should, that code is untested) create scenery objects which respond with bland defaults to all the usual verbs. This is more expensive, but not a problem on a modern machine.
So I think that objects being mentioned in the room description but not implemented (even in this perfunctory manner) is really a symptom of author fatigue.
I’m not sure that matching all the recent text would increase the illusion of parser intelligence though. Imagine:
You’re struck by the throne room’s air of faded grandeur. Sun browned tapestries flank the ancient throne, now revealed as iron hard oak beneath the peeling gold leaf.
> X LEAF
(should be synonym of the throne)
\X TAPESTRIES
You see nothing special about the tapestries.
(From scenery matching, and a fair enough response.)
But:
> X GRANDEUR
You see nothing special about the grandeur.
Hm. But on the other hand, it’s essentially free, and relying on the notion that players are trying things in good faith is a good principle. Storing the output of the last LOOK action, filtered by a lengthy stop-list to strip out “the” etc., would make it unnecessary for authors to implement routine scenery objects at all. It’s not quite free: the cost would be the lack of synonyms, alternate British/American/mis- spelling and so forth, but as a last resort before the generic “I didn’t understand that” response, it could be a good catch.
Okay! You’ve convinced me! 
1 Like
Well, that a first!! 
1 Like
Actually, that might be a neat feature of parsers in the future: In graphical games interactable objects often get a glint or a shimmer or a halo effect to notify the player, either always on, or off by default and the player can “ping” to highlight objects in their radius.
Since many like experimenting on the text, it would be neat if parsers had a hotkey that could temporarily highlight important words/objects in the current room description without spoiling with a list. That would probably require an advanced interpreter similar to Vorple.
3 Likes
That is a fantastic idea.
1 Like
There was a long discussion of having such a hotkey in a different thread https://intfiction.org/t/strengths-of-various-forms-of-interactive-storytelling/44348/38 a while ago.
(Sorry that link jumps you to my contribution, that’s how I found my way back to it.)
1 Like
Oh no, not exclusion!
That’s what categories are for - inclusion implies exclusion. They wouldn’t be useful, otherwise.
Any specific game does several things
That’s wrong. Many ‘games’ accepted as IF do only one thing. And they aren’t even all games.
1 Like