Hello Emily,
You don’t know me. I read your blog and I actively use Adrift to experiment with make IF games and have tinkered with Twine also. I know you are super busy so i will get right down to the point, least i start rambling about IF.
In a brief summary this is about an idea (that may have already been once given to the IF community) of setting up a crowd funding for a prize pool for a IF Creator/Engine competition.
Some might say the best IF creator out there is Inform, i did try it in the past but couldn’t get into it, i tried Quest and that was confusing to use after getting used to using Adrift. I have been tinkering with Adrift on and off for about six years and it has come along way, but falls short in some areas due to only one Dev who adds new features and fixes bugs in his spare time. Adrift does have the ability to use expressions that are close to programming and it is over the last year or so i have learned quite a bit with expressions. I think Adrift is often overlooked (the ability it has with being able to create custom properties for locations, objects and characters. And the ability to create modules to add to your library or share. It still needs lots of polishing).
I was thinking to myself today, why hasn’t there been a kickstarter (add in other crowd funding options here) on creating the ultimate IF Creator/Engine (that could handle CYOA style games, point and click, IF or all of the above in one game). But then there would be many opinions of what that might be or look like and how it would be internally structured, visually look etc no one would never agree on things. And of course the parser. So what about the next best option; crowd fund a prize pool for 1st, 2nd and 3rd place for an Interactive Fiction Creator/Engine competition with defined criteria for judging, such as UI, Parser, multimedia support etc you get the idea. I do not know how big the funding would get to make a decent prize pool worthy to garner attention from programmers around the world. Obviously the bigger the prize pool the more attention and interest in it. I am not a programmer so i do not know what would be a realistic deadline 12 months? 15 Months? for at least a working prototype. Programmers outside the IF world would be at a disadvantage, but could catch up quick reading a number of articles written about IF its weaknesses and strengths with what is currently available to us as tools as well as free content that can be played to see the best of the current crop of IF games in the last ten years. Maybe fresh eyes (programmers outside of the IF community) on the scene might help?
This approach could see some really ingenious ideas that may not win the prize but spark some new ideas to improve on or the winner might have something few didn’t think of that he/she goes on to finish and releases either for free or profit. People tend to be more interested in being in control of their own project and are motivated to be ambitious or think outside the box more this way. I am sure there would be many failed or unfinished entries, but hopefully there might be a small number of really well implemented ideas…
[Cut for length — ed.]
Sorry if this is turning into a ramble. I believe a decent prize pool would get people (those with the know how and interest) serious enough about creating something special. Ideally something that pushes the envelope a little in terms of what you can create with it. However often complex software has a steep learning curve, so i think a healthy balance of user friendliness and power could be an important judging criteria. Maybe there will be a select group of judges as well as the IF community that can have a go and creating something with the prototypes. Obviously a guide for those outside of the IF community, of the core basics an engine should have.
In closing. We have powerful computers now, even smart phones and tablets, its a shame IF hasn’t moved more forwards. So i thought to much a suggestion that may or may not be worthy of further thought. One thing i have noticed as that some people can be very gifted at programming but aren’t very good at story telling and the other way round. I think the person who would be successful in the competition would be someone who understands both.
I think there are several different issues that make this quite a challenging problem.
For one thing, getting enough money to make a difference. Building and then maintaining a new IF tool is a huge amount of work: most of the current ones represent many person-years of labor. (Inform, for instance, has been in development for two decades, and includes the efforts of many contributors besides Graham Nelson.)
I suspect a project to build a more sophisticated-yet-user-friendly parser tool, being developed at a commercial studio, would need to be funded at >$1 million. That assumes that such a tool would on the one hand build on a lot of existing knowledge about world modeling and parser development (so no new R&D there), but would on the other hand need to bring in multiple coders, testers, UX designers, and documentation writers, as well as some commissioned authors to experimentally build things with the new tool and verify that it is useful for purpose.
A solo, non-studio project obviously has a lot less overhead, but as soon as you start paying someone on the project, it becomes ethically and socially sticky not to pay everyone — and most existing IF tools have benefited from many years of donated testing, design, and documentation labor from people who are not the original creators. So given all that, the prospect of possibly winning a prize of a few tens of thousands of dollars (which I suspect is the realistic maximum for such a fundraising effort even if it goes well), divided over the amount of time required to work on the project and the number of people involved, would not make a very strong incentive after all. (That puts aside the point that most people who are skilled enough coders to make a significant advance over what we already have are also skilled enough coders to be paid way more money in a day job.)
Meanwhile, there’s not actually any lack of new IF development systems popping up. Some are academic projects (IDtension, CiF, IRIS and others), many of which the mainstream IF community never even hears about. Some are community projects (Raconteur/Undum, Ramus, Texture, Seltani, Guncho, FyreVM). And of them are commercial or partially commercial projects (Amazon’s new tool for writing games for Alexa; Wunderverse, ink, multiple tools named Yarn, StoryStylus, StoryNexus, Storyspace 3, Storycentric Worlds, Earplay, VoiceMap, Massively, Sequel, whatever drives Episodes, the tool underlying Top Secret, and more others than I can count). Varytale and Versu have also come and mostly gone in this space. StoryNexus games are still available to play, but Failbetter isn’t really supporting the system any further. And then there are many more older-but-still-in-use toolsets listed on this IF tools spreadsheet.
Within that ecology, people are trying loads of interesting ways to drive the field forward: new ways to do story generation and character agents, new ways to do narrative modeling, experiments with audio presentation, hooks for various kinds of multimedia embellishment, improvement to authoring tools, different new input styles, and a lot else.
But you probably haven’t heard of a lot of those, or they’re not accessible for one reason or another, or you’ve never seen a compelling game written with them. For a lot of new IF dev systems, what’s missing is that iteration and refinement that gets a system to a state where it’s really usable for authors and enjoyable for players, where there are at least a few games that showcase that tool and start building a community.
In other words, it’s not that there’s no one to build the tool, and it’s not that there are no ideas about what a cooler tool might look like. It’s that there aren’t enough people using the tool seriously in its alpha or beta state. The piece of this you suggest having done on a volunteer basis, namely the “a select group of judges as well as the IF community that can have a go and creating something with the prototypes”, is the piece that’s in really short supply. I receive far more requests to look at and give feedback on new IF systems than I can possibly meet, myself — it’s really time consuming work, too, since you have to come up with a project idea and make a serious go at implementing it on a system that might be broken, unfinished, or under-documented. There’s no way I could afford to take on the judging responsibility here.
So a couple of things that do exist to try to address some of these various problems:
The IF Tech Foundation ( http://iftechfoundation.org/ ) exists to crowdfund support for technology maintenance, which includes bug fixes and updates for tools. Right now, the first tool it’s looking to support is Twine. IFTF is a nonprofit, which means that donations are tax deductible and there’s a bit more transparency and legal support than for the average crowdfunding setup.
The Oxford/London Meetup periodically does tool meetups where we get together, look at a series of presentations on new creative tools, and offer feedback. That’s a very small contribution to a very big problem, but it is (I hope) useful to some creators.
Academic conferences also look at and give some feedback on these technologies, and some academic conferences recently have started reaching out to non-academic users to invite showcase contributions, such as ACM Hypertext this year. (As I recall that was an invitation for finished works rather than creative tools, but offering a work made with a particular tool might get some useful feedback.)
But this is something I think about a lot, because there’s considerably more need than is currently being met.
*
[Background: I sometimes print letters I’ve received and what I wrote in response, especially when they’re looking for a detailed reply and I think other people might also benefit from seeing the answer. I am experimenting with doing this in a more formal way. Reprinted letters may be edited for length, as this one was. I do not do this without the permission of the letter-writer, so if you write to me and would be open to seeing your email appear as a blog post, feel free to mention that fact. As a rule, if a question requires a long and detailed reply, it’s easier for me to make the time if I can also share the results with other readers. On the other hand, I do not guarantee to print every letter that grants this permission.]
Emily Short's Interactive Storytelling 
In 21 years of observing the IF community, the quest for the “ultimate” IF creation tool is as misguided as it is common. My very first post to rec.arts.int-fiction was a brash, “What features do people want in an IF language?”-type question. I mistakenly assumed that no one else was approaching the question of IF-development intelligently (ha!), and I hoped that by fixing a few fundamental (yet somehow still undiscovered, c. 1995) flaws in the tools, IF implementation could be rendered essentially trivial, leaving folks to engage in creativity unsullied by practical concerns.
Ah, how wrong I was! I eventually learned that any attempt to contain the combinatorial explosion necessarily constrains the solution to a certain context — often to a single game (but not always). Implementing such constraints is rarely trivial. The default libraries of traditional IF systems are essentially collections of such implementations, hard-won through years of implementing specific games. Practical concerns will rule the day for as long as we want to give the player any significant agency.
I’ve always wondered if the apparent outward simplicity of IF particularly attracts people who want to indulge in a fantasy of painless creation. I’d guess so.
My rule-of-envelope-scribble (after watching the evolution of Inform 6 and 7, TADS 2 and 3, Hugo, and so on) is that building a solid, usable parser IF tool takes about four years of development: two years of work by the tool developer, and two years of a group of game developers writing games and kicking the boundaries from all sides. These can overlap! They *have* to overlap; it’s a cycle of evolving features and capabilities. In a highly-energized community (such as we had in the late 90s) it might get done in two years of calendar time. But all those elements are necessary.
Building a solid, usable choice-based IF tool is *much* easier. But you still need that cycle, as Emily describes.
I like how well you handled this. It’s really easy for experienced developers to adopt a scoffing attitude when we hear things like this. I admit my first instinct as the letter was something like: “Better parsers? Learn to code before you lecture everyone else on how they ought to do it. Then maybe you’ll understand why natural language processing on any level above “verb+noun” is actually really friggin’ hard!” Add in a snarky smirk when he says he uses Adrift for an example of just how un-helpful and annoying I would have been.
That’s counter-productive when really projects like Twine, Texture and, to a lesser extent, Inform 7 are trying to abstract away as much of the underlying complexity as possible so that people like the letter writer can tell their stories. It’s especially counter-productive when the entire reason to write software isn’t to feel superior because we put in our time learning how to make these insanely complex machines bend to our wills. It’s so that we can make these insanely complex machines bend to other people’s wills, preferably without them even realizing how hard it is. Because, you really shouldn’t have to dedicate your life to software development just to tell a story.
TBH I don’t think it’s so much that non-“verb+noun” structures are tremendously difficult for machines to parse on a *grammatical* level — that capability already exists out there in many places, albeit not to perfection, and many of them are open-source — as it is that it would require *the writer* to actually account for all of those combinations. Either that or be able to develop some kind of… algorithm…. thing…. that can automate the production *semantically* appropriate responses to parsed complex text, and that is definitely beyond us right now, even with massive fancy corporate-level resources backing the effort.
…there’s a missing “of” after “production” and I wish this commenting system doohickey actually let people edit comments.
I spoke loosely, but point taken.
I think a more useful approach than focusing on tools and more tools, might be a project looking at interoperability. Fundamentally, each tool provides the user with a channel of input and a channel of output. (With some complicated stuff in-between). A reasonably simple IF middleware would be an awesome thing. Why can’t a click on a twine link kick off an Inform ‘After going’ rule?
Just a thought.
Mike.
The one thing that’s always interested me is removing the virtual machine and making a componentized platform. Just break all the major pieces out and build them as separate components and then have common interfaces in between. This would include the engine (not necessarily a VM), the parser, the world model (or to me, database), language service (a common language service and then English, French, Swedish, etc implementations), a text stream service to handle merging text into readable form, and a default response service to handle default responses, and of course, removing any semblance of adherence to legacy user interfaces. No assumptions about screens, status lines, or anything of the like. No assumptions about layout either. Provided a layout service, the author could implement their own (and standard layouts created for out of the box usage).
Honestly, this is still something that draws my attention like a moth to flame.
Then again, I want to get back to just telling stories, so it’s likely to just burn in the back of my imagination.
Well, if we assume a simple verb-noun style parser (rather than the more complex full syntactic parse which would require the author to manually create a LOT of different possible responses, per above), there doesn’t really need to be a “language service” per se so much as sets of default responses for each language; i.e., submodules of the “default response service” if anything. In the end it’s still the author who defines the significance of each noun and verb, so for all the thing cares, you could have a completely made-up language where you maheraati zibetli qusvanat (>Maheraati zibetli qusvanatsen.)*
Now if the computing language with which the author must encode their work is partly based on natural language, a la Inform 7, then of course separate language modules for compiling that into Inform 6 code must exist. But that — and the anglocentrism of most programming languages — is another story.
Thank you for including StoryStylus on your spreadsheet. I was wondering if you wouldn’t mind updating our entry?
StoryStylus
—————
Website: http://storystylus.com/
Last Updated: 10/1/2016
User Interface: Graphical, Menu-Driven
Scripting Language: Lua, visual
IDE: Silverlight, web
Game File Format: Flash
Complexity: Low to Medium
Can Self-Publish Titles: Yes (can share links to titles), costs $20/year to use authoring system
Thanks again for the inclusion,
Blair Leggett
One More Story Games
It’s not actually my spreadsheet, and I don’t have access to edit it. :) But I’m happy to let your comment update stand. As I recall, the spreadsheet’s creator has sometimes appeared at the intfiction forum, so you might try posting there. (http://www.intfiction.org/forum)