What people said about the Missing Tools (and some that aren’t missing at all)

A few days ago I asked people in several forums to tell me what IF tools they wished existed. Here is a collation of the major themes. (This misses out a handful of very specific requests about what specific existing systems should do — it’s more an attempt to put together some general patterns.) I also got some interesting feedback about tools that do exist but aren’t widely known or used, so I’ve written that up too.

An IF creation system that runs well on a tablet (multiple mentions, plus related requests on the I7 suggestion tracker). This is the most often expressed single wish. Some requesters wanted to be able to use Inform, some wanted a mobile-compatible browser-based version of Twine, some didn’t express much concern about what the system was so long as they had one. I was surprised by the strength of the interest here because I don’t have a keyboard for my iPad, assumed other people typically don’t have keyboards either, and concluded that mobile IF creation would be a miserable exercise in touchpad typing. But apparently I was totally wrong! Lots of people do want this.

I don’t know of any IF-creation tools that exist as native tablet apps, but there are quite a few that run in browsers that might be accessible to a tablet. I did some experiments on my iPad 3 and found that:

inklewriter as browsed on an iPad

inklewriter is usable, if rather sluggish, when running in browser from my iPad. The problem here is mostly the animations where the text moves from place to place, which I imagine inkle could choose to turn off in a mobile version of the site if they were so inclined. I also couldn’t figure out how to bring up a map of the passages I’d written so far. Overall, though, inklewriter is such an accessible, get-started-right-away system, and with such luscious images, that it feels like a pretty natural fit for a tablet.

Twine 2.0 is a bit faster, but when I open a node to edit the text, the input text is white on a white background, so I can’t see what I’m typing. Clearly a dealbreaker. In addition, a lot of macro work in Twine requires pasting in long chunks of javascript from sites that provide it; I’m not sure how easy that would be to manipulate on a tablet. Possibly doable, though. (ETA: this is working better now. See comments.)

With Quest’s online creation page, I got as far as signing in and filling out forms for my proposed game’s title and format, but repeated pressing of the Create button didn’t take me anywhere.

Playfic (as a front end to Inform) works well on a tiny test project: typing speed is fine. I have to tap the “Save & Test” button a couple of times in order to get it to run, and the run cycle is longer than it would be in the desktop IDE, but it does come up. I would guess, though, that as the games get longer, Parchment running on the iPad will become sluggish, so this may not be a viable way to write games of any size. Speeding up Inform games’ performance on Parchment is probably the key to making this work better.

To the best of my knowledge, TADS and Adrift do not provide any online or mobile app options.

Still, there were more options for at least attempting this than I had initially thought.

A system that produces choice-based games but is backed by a domain-specific programming language (that is to say, not raw javascript). There were two major branches to this discussion:

— Twine macros (multiple commenters). Commenters discussed wanting to have a way to tweak Twine’s behavior without having to rely on people contributing javascript macros to extend the functionality (especially since these macros are distributed and documented in different places all over the web, making it sometimes challenging for authors even to know what functionality is available). The proposal was basically that Twine should have a small programming language allowing authors to specify link behavior without having to drop all the javascript in.

Jon Ingold’s The Colder Light

— choice-output Inform (multiple commenters). Commenters mentioned wanting access to many of Inform’s features but the ability to compile an Inform project with a point-and-click interface. Though there are a number of examples of specific games that have done this, it always requires a fair bit of customization and effort. One commenter expressed a desire for the system underlying The Colder Light to be made generally available. Another pointed out that the Inform extension Glulx Input Loops does allow for creating pure hyperlink pieces in Inform. So there are some steps towards this, but it would be interesting to imagine what could be done if Inform had a choice-based output mode as a core part of its functionality.

Better audio and multimedia support; more attractive typography.

One person asked for “Default Twine output that looks as good as Undum”: I assume this is a matter of someone providing additional templates for Twine and designing some sexy CSS, but I haven’t looked into it.

There were several prongs to this when it came to Inform: that Inform’s multimedia is not supported the same way across all interpreters; that interpreters aren’t up to date; that multimedia is difficult to do online; that the built-in Inform libraries provide minimal support for things like audio fades; that the methods currently provided (including Erik Temple’s ambitious Glimmr project) don’t allow authors to include multimedia formats that they’re used to. For instance, animation has to be handled in a fairly close-to-the-metal way, and one can’t just drop in a movie file in one of the standard formats. Another commenter remarked that typography for parser systems is traditionally poor and that it would be nice to produce games that look more attractive.

Guilded Youth, Jim Munroe’s Vorple game

The best solution to this I know of so far is Vorple, which has been used successfully with Guilded Youth and Starborn. To my eye, this is a pretty satisfying answer to concerns about typography, customizable output, and the use of images and web-standard types of video file.

However, one serious issue is that it works only with the Z-Machine at the moment, while Inform 7 increasingly uses up a big enough footprint that only very tiny games can escape being compiled to Glulx. To address Glulx, Vorple’s currently waiting on the next version of the Glulx spec — and even then, large Glulx games often have poor performance in Parchment, which is needed to run Vorple. So this kind of shifts the problem from “we need a way to display pretty things” (which I think Vorple handsomely handles) to “we need to optimize the performance of Inform games quite a bit”.

Which was also a request one commenter made separately.

A system supporting multiplayer IF, especially something resembling the Twine MMO Naked Shades. Andi McClure mentioned that she is working on a relevant toolset. There are also a few other extant multiplayer options: Guncho is an open-source MUD allowing for multiplayer Inform games, while Fallen London offers some features for social interaction between players. There’s also The Yawhg, a 1-to-4-player CYOA that came out recently (Windows only, alas, so I haven’t had a chance to play it yet). However, I think it’s fair to say that there aren’t any toolsets that are in very widespread use for this.

Tools for collaborative distributed IF creation. One commenter phrased this as wanting something that would let both collaborators edit as though the file were a Google Docs file. That seems to presume a web-based tool like Twine 2.0 or Playfic, with the addition of multiuser functionality. I don’t know of anything that currently does this. (Maybe it’s possible to share a single Playfic login, but then presumably only one of you can be editing at a time? I’m not sure.)

Tools for more systematic, simulationist, or procedural games. IF games have mostly not done much with procedurally generated worlds and maps, autonomous character behavior, and RPG-like features. There are a few exceptions. Hunter, in Darkness randomly generates cave descriptions. Kerkerkruip builds a cave of randomly-placed locations and NPCs. Olivia’s Orphanorium is sort of an IF replica of a time management game. But even these games work with a relatively constrained template of options, compared with the non-text games in similar genres. We know that the issue isn’t that people don’t want to write these types of games, or that they’re not trying: there are many questions about how to implement these kinds of thing on the intfiction forum, for instance… but very few finished games. The tools aren’t in the right place — but it seems like they might be, so people get started but don’t finish.

There are a lot of different issues that play into this.

One is text generation: we need to be able to describe the situations that the simulation brings into play. If we’re procedurally generating rooms with semi-randomized features, then we need a way to generate text describing the room with the features [snowy], [mountainous], [inhabited by dwarves], and (ideally) have that be a more interesting description than just “You are on a snowy mountainside. Dwarves live here.” If we’re simulating characters who move and act autonomously, we need a way to collate and report their behavior in a way that looks good, rather than having a long string of one-liner reports like “Alice goes north. Fred goes north. Susan goes east.”

For parser-based games, heavy simulation or randomization also means that the parser has to be more sophisticated about how it interprets noun phrases. Inform gets part of the way there by being able to understand object properties as part of the object’s name, but overall, this needs to be able to track exactly with whatever text generation tricks we’re doing. If we’re calling any short, wide object “stumpy”, then the parser needs to know to read “stumpy” as referring to short wide things. Moreover, the bigger and more complicated the text simulation work we’re doing, the more important that the author doesn’t have to write gazillions of lines of code of the form “Understand “stumpy” as a thing if it is short and wide.” — that becomes unmaintainable. We need, in other words, a more systematic and high-level way of expressing these ideas.

For Inform specifically to handle the back-end simulations well, it would likely need dynamic object generation (a long-running request, with an impressive 65 votes on the Uservoice tracker).

Finally, Inform would probably need improved performance generally to support games with a large amount of NPC autonomy.

In the parser domain, some of these issues are addressed by TADS; my impression is that it can handle dynamic object creation and that it’s got better facilities than Inform for generating collated reports from NPC action.

A possibly related request is for a tool that could create javascript text games like Candybox and A Dark Room.

Tools for text displayed on a canvas that can be scrolled, dragged, or zoomed. Ex Nihilo does the draggable canvas, to rather cool effect. One commenter pointed out the Zoomooz.js library, which might support this kind of thing more generally.

Various suggestions for hybrid choice/parser interfaces, including automatic menus of standardly used verbs; a choice-based presentation that also offered a parser entry field as a final choice; a point-and-click interface allowing the player to select objects from the game’s output text and recombine them to create parser-like input (rather than typing).

Screenshot of the verb selection menu from Dreamhold on the iPhone

Many of these things exist at least as examples somewhere, as IF has a long history of experimenting with hybrid interfaces. There’s even a game, Ferrous Ring, that allows the player to select one of four interaction styles, including the standard parser mode but also a “nominal mode” that allows interacting by naming nouns, a menu-based mode, and (the ultimate for stuck people) a “walkthrough mode” that feeds the correct next move into the command prompt each turn, so that you can “play” just by hitting ENTER over and over again.

Some of these features are available in a consistent way, if one is using the right system. Anyone can make use of zarf’s iOS Glulx package, for instance, to create a standalone app that shares those selectable menu features.

There was also a suggestion for “a tool to write whole games in the style of the “path of love” in Blue Lacuna’s opening chapter, where the player can type anything in response to prompts, and the game can try to pattern match your responses against pre-canned answers, but if it doesn’t understand you, the text tries to “fake it,” misleading the player into thinking that the input was understood. It’d be a choice-based parser game, but the game would never say “I didn’t understand that.”” This sounded a bit reminiscent of another suggestion that popped up on the intfiction board not long ago for “conversational” IF (though not in the Alabaster/Galatea sense of the term). Possibly this could be done with a parser extension to one of the existing IF systems, but an alternate plausible approach would be to play with extending a chatbot system such as Bruce Wilcox’s ChatScript to handle more of a world model.

Improved parser behavior, including tolerance of typos. There’s a somewhat effective typo correction extension for Inform 7, and there’s Jon Ingold’s Interactive Parsing extension that’s designed to give live feedback about whether the parser is understanding what you’re typing, as you’re typing it. Poor Man’s Mistype isn’t able to correct all typos, though.

Versu. Sorry.

Several ideas to make authoring faster, easier, or more systematic: a Twine-like creation interface for Ren’Py; a transcript-to-code tool, which would take a sample transcript as input and attempt to extrapolate code from it; a tool for Inform or other parser systems, perhaps a bit akin to Object Response Tests, that would present the author with a list of possible conversation subjects so that they could fill in dialogue about those topics systematically.

It didn’t come up this time, but in the past people have also mentioned wanting to be able to draw the game map with nodes and then have it spit out the appropriate code. The Inform team has several times rejected this request as a feature of the IDE, partly because of the technical difficulty of making it work and partly because it would break the overall paradigm of Inform.

One commenter suggested an IF program that tied into WordNet. This was a fairly vague suggestion, so I’m not sure what all the implications would be, but it might be used for things like generating object synonyms.

---

What didn’t come up: no one in any of these threads said anything about commercial concerns. No one mentioned wanting to have more ways to easily sell games or ways of monetizing existing types of game. Possibly this is because of the audience answering, or perhaps because of the way I framed the question, but there were zero references to money.