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

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

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

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.

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

  1. As the ultimate stuck player, I would be doomed if “walkthrough mode” came standard on more games! I would never have incentive to try to solve puzzles again.

    A lot of really interesting thoughts. Way back when I was coding Dead I6/I7 game (it was in development long enough that I ported it over, then gave up on the grounds that we’d be at I8 by the time I finished), I really wanted to include audio but was stymied by crossfades. But that’s a relatively minor desire.

  2. Regarding multiplayer IF, there’s Andrew Plotkin’s Seltani, which is a text based multiplayer CYOA engine: http://seltani.net

    I’ve also have a prototype project along the same lines, but with a very different aesthetic and, er, less workingness. (The test server is up intermittently and right now doesn’t work on very new versions of Chrome due to Python websocket library bugs.) Mine’s much-more programmer-centric and has full scriptability in a dialect of Basic, but right now it’s definitely a tech demo and not a useable system: https://cowlark.com/thickishstring

  3. I was about to mention Seltani, but David got there first. Thanks. :) (I just printed up a bunch of Seltani promo postcards. I doubt that a lack of postcards is the system’s most serious issue, but just in case…)

    Re money: People have managed to charge money for Twine games, Inform games, and so on. I think that if none of these options existed, there would be some clamor for them. But they do exist (even though they’re awkward). So people focus on getting games written, with the sense that if you finish something and decide to sell it, there will be some kind of avenue to do that.

    • Ah, yes, sorry. An oversight, not mentioning Seltani — though in my mental categorization, I think of it as a collaborative/shared world project rather than a tool. But maybe that’s wrong.

  4. I’m very focused on commercial concerns, but I didn’t even think of commercial features when you asked your question; it seemed out of scope.

    IMO, it is still surprisingly challenging to take an Inform/Twine game and make it available as an installable app for iOS, Android, Windows, Mac, and Linux, which IMO is a prerequisite for making reasonable money selling a game.

    Beyond that, adding even basic support for cross-platform in-app purchases (both consumable boosts and non-consumable entitlements) would cover the majority of what I think people would want to do in terms of monetization.

    But supposedly the core problem is demand for commercial IF, right? For us, our approach has just been to build up a base of followers, especially via email and not Twitter/Facebook/G+/RSS. A “subscribe” command for Inform games that would prompt the user for an email address and post it over HTTPS to an URL of the author’s choosing (e.g. MailChimp) would help a lot.

  5. > [I] 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 actually think you’re both right. It would be a miserable experience, but people don’t know that it would be miserable; they think/hope it would be easy and fun. So they want it, and it’s bad, and someone should give them what they want, because it’s what they deserve. ;-)

  6. FWIW, I’ll second liking the idea of better tools for collaboration. I would’ve loved having a GDocs-style shared editing version of Inklewriter last year with the middle school kids I worked with.

  7. I know I’ve never really produced anything people can actually use, but the foundation of FyreVM and some other code would enable many of the things people are asking for. Better sound capabilities, better fonts, etc. And there are other things that can be used to build better tools, such as AngularJS, Bootstrap, and other front-end frameworks.

    I’ve always said, I would love to build something useful, but I would prefer to do it in a collaborative setting. Building things in a vacuum isn’t really all that much fun and generally leads to unusable things anyway.

  8. This and the conversation threads that emerged from your initial tweet have made for some fascinating reading. My mind didn’t go to commercial concerns because I think of that more of a function of a marketplace, not a content creation tool — but dfabulich’s point that it’s hard to publish to app stores right now, in particular iOS and Google Play, is totally correct.

    If you don’t mind, would you create a bug over at https://bitbucket.org/klembot/twinejs/issues for the issue you saw with Twine 2? I haven’t seen that behavior before, but I’ve only tested on an iPad Air. Its tablet support is… in progress still, is the best way to put it, but providing decent support is a goal for the final 2.0 version.

    • I went to collect a screenshot for this purpose, and the font issue now seems to be working (yay!), and I was able to get far enough to play through a small sample game. It’s still suboptimal — what plays on a desktop browser as a smooth attractive transition between screens of a Twine piece is weirdly slow and overlapping on iPad Safari, and it’s not really convenient to type [[ ]] elements with the Safari touch keypad. But an attached keyboard might make that at least a lot better.

  9. Pingback: Oxford Tools Meetup | Emily Short's Interactive Storytelling

  10. Some great food for thought in this article, thanks for sharing Emily!

    I’d just like to mention a free interactive fiction / visual novel tool I released recently called Fungus. It’s an open source extension that works with the free version of Unity 3D. Lots more info about it here http://snozbot.com/fungus

  11. The problem with online tools is that you need to be online. At the times I have available to write, I tend not to have Internet access. And unfortunately the present batch of Android Browsers do not support local storage api’s. Add to this that running javascript in the browser tends to be resource hungry. This is no issue on a desktop system. But is an issue on a much leaner tablet device. Not only in terms of responsiveness but also for battery life.

    As to input method. Tablets have a few alternatives to displaying a qwerty keyboard. As an example I use a gesture based keypad called MessageEase, which along with a stylus combines to get me something pretty close to the same input speed as a full sized physical keyboard.

  12. I mean to weigh in when you first asked about this but I’ve been so busy the last couple of weeks, I forgot about it.

    My number one pie-in-the-sky wish for IF authoring systems is more/better support for alternative and experimental UIs. Better support for multimedia is a big part of this, but also things like having more control over design elements and typography; making it easier to open and write to new windows; having the ability to update elements that have already been printed to the screen; having easy to use, flexible hyperlink functionality; being able to turn the command prompt on and off, move it between windows, or have more than one command prompt available. Parser IF systems are still very much built around an assumption of a particular UI and input cycle (a single screen of text interspersed with command prompts for user input, plus a single status bar across the top). I know Inform is generally more flexible than TADS in this regard, and I know you can work around some of the existing limitations if you’re determined enough, but I’d like to see this kind of thing more readily available to people who want to try something new.

    I’d also like (and I know this is something we’d need a time machine to fully realise) to see IF authoring systems and tools designed from the start to be cross-platform, rather than designed natively for one operating system and then hopefully-if-you’re-lucky ported to and maintained for other operating systems. On the TADS side, Nikos Chantziaras has been fantastic about building and maintaining FrobTADS and QTADS, but the TADS Workbench is still Windows only. The various ports of Inform 7 all have their own feature sets and peculiar quirks to learn.

    Those are the two main things I’d wish for if I got a magic wand that only granted IF-related wishes!

  13. I wish there was a Twine-like tool aimed at programmers, with it’s own embedded DSL. It could work in a console-based environment (like say… Frotz) and also be able to compile stories to the equivalent HTML/JS. This is a bit of an odd request given that Twine’s main attractive seems to be ease of use and programmers already have excellent tools such as Inform.

  14. Thinking about it, it would actually be pretty easy to modify thickishstring to allow a realm to be downloaded and played locally as a standalone HTML+Javascript+local storage bundle. That way someone could build a realm online, get multiple people to playtest it online (possibly concurrently!), and then deploy it as a ‘finished’ game. The actual server logic is nigh trivial and should be easy to rewrite in Javascript. (I’d probably want to rewrite the server in Javascript as well for code commonality.)

    I wonder if this would actually be useful…

  15. Pingback: Procedural Text Generation in IF | Emily Short's Interactive Storytelling

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s