@mattlaschneider writes: I’d love to see a series of posts geared towards people who are interested in learning to write parser IF in a post-Twine era… I could be totally off base, but I do think that parser IF has a lot to offer people who would normally otherwise be attracted to Twine.
We then had a long Twitter-thread argument about whether it was even appropriate to try to recruit people to writing parser IF, especially because I think many people who come to IF because of Twine have motives or needs for which parser IF is a terrible fit.
So let’s start with the reasons not to write parser IF, and we can come back to the question of how to write it if somehow none of my persuasions work on you.
Should I write parser IF? To which my answer would be almost always no. Let me inflect that a little, though.
If you want to write a game that you have a reasonable prospect to sell for money, you should not write parser IF. There is a commercial IF scene that makes money, but essentially none of it is parser-based.
If you want to write something quickly and easily, you should not write parser IF.
If you want to create something that will have a large built-in audience, you should not write parser IF. Likewise if you’re hoping to get a lot of feedback on your work. This is an area I’m sad about. When I came up, in the late 90’s/early 2000s, the parser IF critical community was still very active, and a game submitted to IF Comp could look forward to dozens of responses from people very experienced in the form. Now admittedly those responses could be extremely curt or harsh if a game was perceived as not-up-to-snuff, and the definition of IF was a lot narrower than now. But an ambitious and experimental game could get a lot of really thoughtful engagement, too. That is less true now.
If you want your parents to play what you build, you should not write parser IF. (My mom plays parser IF. She introduced me to it. But lots of people find it challenging to get into, even when created by loved ones.)
If you want something to put on your portfolio that will look snappy to potential employers, or that they will even know how to play, again, do not go to parser IF.
If you’re curious about natural language processing, parser IF is still not for you. What you can learn from parser interactive fiction is how to wield tools from the 1970s for a very particular craft purpose. That’s fine. I like old things. But what you learn here doesn’t always completely translate to the modern version of that domain. (It’s not totally useless either, as I’ve found — but if this is your goal, there are more direct ways to go.)
You should write parser IF only if you have goals outside those categories. Perhaps you are nostalgic for Infocom; perhaps you think parser is just so cool; perhaps you have a game concept that really fits parser and there’s just no better place to do it. Possibly you are tickled by a medium where you can spend half your time writing responses to commands like LICK PARROT. Maybe there’s something you aspire to learn about game design that you think parser IF could teach you.
I played parser IF as a child and always wanted to write it. I would have wanted to write it even if there was no one to play what I wrote. I’ve stopped because it doesn’t serve other goals that are now more important to me, but if those considerations went away, I’d probably go back to it. I finished the last of Counterfeit Monkey next a pool in Hawaii, and The Mary Jane of Tomorrow on a hillside in Yorkshire. It’s a self-indulgence.
Okay. If that’s you, then yes, you should write parser IF.
What special things do you find a lot in parser IF that are not represented as much elsewhere in interactive fiction?
I’ve written before about the process of mapping narrative to a space, on which parser IF thrives.
Puzzle design is another. Puzzles not just as a locking mechanism to pace bits of the plot, but puzzles that explained the world and puzzles that communicated character and puzzles that required the reader really understood the plot. Games with a choice of puzzle difficulty. Dynamic hinting. Puzzle-jokes, where the solution was the punchline.
Wordplay, language games, and pieces where the manipulation of the text itself is core to the experience, or where the precise phrasing of a command matters. Linked with that, games that involve interacting with abstract concepts or other constructs that could really only be represented in text rather than through graphics. Games that noticed which words you used to refer to particular objects, and subtly changed as a result.
Exploration and easter eggs. Most hypertext and choice-based IF surface their affordances, which makes them more playable in some ways, but also means there’s less to discover. There is hypertext where the links are not explicitly marked, which reintroduces this challenge; and Texture does the interesting intermediate trick of not showing you link points until you’ve picked a verb to use. But parser IF is full of this kind of thing, games with possibilities you wouldn’t even have guessed at initially.
A particular kind of control over prose. If you’re writing for parser IF, you have to know where you’re placing every noun, because every object you name to the player is a promise of future interactivity. So you learn to be sparing and thoughtful.
A conversational push-pull exchange with the player. Ryan Veeder is expert in this. The text hints at something to do, notices when you try it, redirects you when you go the wrong way. Or, conversely, the game intentionally misleads you about its own goals, and it’s only after the fact that you realize where and how you went wrong; see various works of Adam Cadre.
Mood communicated through setting. Sometimes that’s a game where horrific foreboding comes through in every room description, or where the landscape feels inexpressibly lonely.
Extremely intricate simulation of particular tools, spaces, or objects. TADS 3 is the tool that carried this to its greatest height, with lots of abstract classes to represent concepts like “a barrier through which odors pass, but not light or sound” or “something that looks like an exit, but that you can’t actually move through.” Return to Ditch Day is a game by TADS 3’s creator that shows off some of the cooler or flashier aspects of this. And Adam Cadre has a great review of simulation being used in aid of participatory comedy in Fine-Tuned.
Do I have to use a parser to do those things?
No, you don’t. Not all of them, anyway.
Some of the wordplay and conversational interactions I just mentioned are tricky to do without textual input.
On the other hand, the spatial presentation of narrative, the detailed world model, the puzzles and exploration are possible to do in other formats. They’re simply less common for reasons of genre and available world model tools (which is to say, it takes more work to code a puzzle in Twine). All else being equal, if you can offer people an accessible format they can play in their browser and where they never have to guess the verb, you will get a lot more players than you can get from a parser IF publication.
But people have done those things with home-grown tools: for instance, Robin Johnson’s Detectiveland and Draculaland. (If you’re local and you’re interested in how he did those, we’re having a London IF Meetup May 31 that will feature him presenting his toolset.)
Meanwhile, Glulx-compatible Vorple means you could write a world model and puzzles in Inform and surface them to the player via generated hyperlinks. Juhana will be talking about Vorple at the May 31 Meetup too.
Some ambitious writers have bolted sophisticated features onto Twine, as well. Alcyone is a QBN-style narrative system executed with a lot of code and display features on top of standard Twine, and SPY INTRIGUE does narrative node mapping as part of the play experience.
Finally, Quest provides a way to drive some or all of a parser narrative via hyperlinks. In practice, that often results in hybrid projects, but in theory one could do something that was mostly link-based.
I’ve also written before about various experiments that incorporate alternative user interfaces or change the way the parser is being used. The parser v choice and user interface categories on this site contain more articles on these topics.
I’m determined, despite your warnings. Can I learn to write parser IF?
Sure. And you don’t need me now to write you a bunch of new articles about how to do it, because people have already spent decades doing so.
This is an art form loved and developed by extremely verbose people who wrote an epic amount of instructional material, tutorials, and criticism. Inform comes with hundreds of built-in examples to help with the code perspective. Aaron Reed published an additional book as a companion to Inform. The IF Theory Reader contains a whole bunch of received wisdom from the early 2000s, and some of it is out of date, but there is a load of information in there about puzzle design, geography, writing room descriptions, characterizing protagonists, and a lot else. There are the craft discussions and postmortems linked at ifwiki, while this index points to topic-by-topic Usenet archives from about 1990 to the early 2000s.
I’ve collected a bunch of other links in my Writing IF page, and a lot of my craft articles, especially the older ones, are about parser IF craft.
I ignored your advice and I wrote some parser IF and now I am sad that I can’t get money or attention for it. Could you help?
Um. Well, honestly, probably not much. I’m so sorry. I tried to warn you. I don’t have time to cover everything people ask me to cover; long-form parser games are especially hard to budget time for.
But if you want, you can contribute to the culture of covering parser IF by writing some reviews for IFDB or opening a discussion thread on the intfiction forum.