IF Tool Development in general

I get a fair amount of email from people asking me to review their new IF creation tool and give feedback. Unfortunately, I’m usually not able to do extensive IF tool critiques for free. It’s work that overlaps with the type of work that I do on a paid basis; on average, most new tools people send my way are pretty buggy and under-documented and also not as powerful as existing tools, because they’re the early stages of an alpha project; and doing a thorough critique and feedback on a tool is hours, days, or even weeks of work, depending on how finished and how sophisticated the system happens to be.

However, here are some general pieces of advice I can give in this space:

— know your unique selling points relative to other IF tools. There are a lot of existing hypertext and choose your own adventure-style tools out there already, both online and to download, targeting mobile and browser.

If your tool is more off the beaten path in structure, you can get away with doing less to compete on ease of use, ease of distribution, size of existing community, and so on. Tools for quality-based narrative, for instance, aren’t all that common.

I’d recommend at a minimum looking at ink, ChoiceScript, Texture, and Twine as comparison points. These engines have been used for a significant amount of creative work and in most cases to drive commercial products on multiple platforms. They also have significant user communities. This is not to say it’s impossible to do better, especially in some specific niche area, but it’s worth being aware and not duplicate effort.

— if you are reaching out for a user base, know what those selling points are and highlight them in your pitch. If you’re asking people to use/test your tool for free, understand you’re asking them to do a lot of learning and also work in a system that doesn’t yet have proven stability; investing a game you care about in a platform that might not be up in six months is itself a bit daring. So think about the incentives and guarantees you’re able to offer.

— having several complete and sizable example stories in your tool is critical, both to prove out the tool itself and to attract users in the future. I tend to tell people that until they have at least one good story, the tool is not finished.

And by “good,” I mean it should both display the tool’s capacities and actually be a quality piece of writing that someone would enjoy playing/reading. It’s very hard to attract serious users to a tool without a few stories in that app that attract their attention and make them want to emulate it. And it’s very hard to be sure the tool is capable if the only thing written in it was written to observe the limits of the tool, rather than to be good in itself.

— some other resources include

This missing tools post on tools and what people want. This is a few years old, predates ink/Unity, and is growing outdated, but the discussion may still contain some useful hints and suggestions, particularly about what kinds of concerns authors from the IF community consider when picking a tool.

This deck is a slide deck I used for a talk at Northeastern a couple years ago about tool design for writing IF, and what the goals could/should be.

This post on narrative structures talks about some narrative structures that aren’t always well-supported by tools, if you’re looking for ideas. There are MANY hypertext and CYOA engines; there are fewer salience/QBN engines.

This Pinterest board has screenshots of a lot of interactive fiction interfaces from different systems, which may suggest interface approaches that you want to borrow, learn from, or on the other hand avoid.

The Oxford/London IF Meetup sometimes does live meetings about new tools, in which tool creators pitch to and take questions from writers; if you live in the UK, that might be an option