I’ll be giving a short presentation about IFTF at the monthly Providence Geeks meetup at 6:30 on Wednesday, February 20, at the AS220 art space downtown. (IFTF’s connection with Providence extends only so far as the fact that its current president happens to live there — but he does, so there you have it.) This will happen at the AS220 main stage at 115 Empire Street.

I plan to host a group play-through of Admiral Jota’s well worn crowd-pleaser Lost Pig starting at 5:30, to entertain the early-birds. We’ll likely have examples of other modern IF on-hand to sample after the talk; I’m taking a cue from how the Boston IF crowd offers demonstrations at the local indie-games festival every year.

Because AS220 has closed its restaurant for renovations, visitors should plan to dine before or after the event, or bring their own take-out to enjoy on-premises. Providence Geeks will provide a pop-up bar.

IFTF is pleased to announce that we are now in the process of adopting the IF community forum at intfiction.org.

I should say: the forum moderator team are pleased to announce this, in collaboration with IFTF! They already posted the news last weekend.

The forum is a long-standing center of IF community discussion. It’s been continuously active since August of 2006. Mike Snyder, who has hosted the server since the early days, is now stepping down as maintainer. Our very great thanks to Mike for the years, effort, and financial support he’s put into the system!

So now the forum will pass into the IFTF domain. It’s important to make clear what this means.

  • IFTF now has a IntFiction Forum Committee. If you look at that page, you’ll see five people listed as moderators, led by Dannii Willis. These are the same people who have been moderating the forum for the past few years.
  • You’ll also see my name and Chris Klimas on the committee. We are not forum moderators, and we will not be directly involved in moderation decisions or policy. We’re there to advise and to act as liaisons between the mods and IFTF.
  • IFTF will own the intfiction.org domain, run the server, and pay for hosting costs. (Supported by your donations, of course.)
  • The mod team will continue to maintain the software and deal with the day-to-day work of running the forum. As their post notes, they are considering switching from phpBB to Discourse. That was their decision, and they’re making all the decisions about how the new server will be organized.
  • The committee chooses its own members (as long as there’s at least one board liaison). So the committee, including both moderators and board liaisons, decides who gets to be a moderator.
  • IFTF will provide oversight, stability, and support as needed. Since the server itself is run by IFTF, it is protected by IFTF’s status as a registered nonprofit with legal resources and so on. The forum also gains the benefit of being operated by an organization, rather than one volunteer’s web hosting account.
  • The IFTF board has the ability to overrule the mod team. However, we intend to use that authority only for emergency situations. For example, if the mod team breaks down and is unable to make decisions; or if the moderators make decisions which put the forum in legal jeopardy.
  • The mod team has the ability and authority to run the forum software — banning or editing messages if necessary, and so on. The IFTF board liaisons do not have that authority.
  • To be clear: I set up the Linode instance, so I have root access to the machine, so in theory I have absolute power. However, I would not use that power unless the mods request it or if it’s required for emergency server maintenance.
  • The forum has a code of conduct, and IFTF has terms of service. (Including a privacy policy.) All will apply. They should be compatible (we’re checking with our lawyer to make sure).
  • Beyond the guidelines of the COC and TOS documents, IFTF’s policy is to not dictate the shape of forum discussion. Think of this as editorial independence. The forum will be an IFTF project, but the “owners” do not decide what’s on-topic for the forum, or how topics are organized, or what counts as interactive fiction. The moderators decide that. They should not need IFTF’s input unless they’re seriously deadlocked.

This last point is subtle. We’ve had quite a bit of discussion about who “owns” the new forum. But not the way you might think! I came into the discussion assuming that the mod team would be the “real owners”; they came in assuming that IFTF would be. It’s been a bit of a “you first” “no you first” situation.

My (personal) conclusion is that “ownership” is a terrible way to approach community resources in the first place. That’s why I’ve avoided the word in most of the above discussion. (Except for the domain; there’s a clear notion of who owns a given domain name.) Spelling out our explicit areas of responsibility is much more useful.

Ultimately, this is a joint project on behalf of the IF community. It exists because the mod team approached us and we saw that we could help. If it turns out that we can’t work together, the solution is not for the “owner” to force a decision on the “subordinate”; the solution would be to amicably separate.

Why am I going on at such length? I could have just said “IFTF is taking over the forum, yay, party hats for all.” Why all this introspection?

The forum is the first IFTF project which has really had to grapple with this question. After all, when IFTF adopted IFComp, the Comp was run by Jason McIntosh — IFTF’s president. When the IF Archive came on board, I was the director. When Twine got IFTF support, the association was managed by Chris Klimas, Twine’s creator, who is also on the IFTF board. It was taken for granted that each project would continue to operate within IFTF with the same values and vision as it started with.

The forum is IFTF’s first outside project, in that sense. Some of us board members have participated in the forum — I’m an active poster — but we didn’t build it. It’s important that IFTF be able to support the forum without changing what the forum is.

Look at it this way: IFTF now operates a bunch of IF community resources. (Most of the resources I thought of as crucial in the 1990s… although of course IF is a far bigger pond today.) This centralization is a strength; we have nonprofit status and a shared donation stream. But it could also become a problem. Any observer of centralized social networks knows how sour they can go.

IFTF has authority over the resources that it operates. This is necessary for a bunch of reasons, including simple legal liability and the kinds of emergencies I described earlier. However, we want each of these projects to continue thriving in its own way, according to its own values. For the forum, that means a policy of editorial independence.

The problem is not centralization, but dominion. If IFTF were consolidating power — if it were even perceived as consolidating power — it would lose the community’s trust. So we have to be careful to avoid that.

Even dictating the definition of “interactive fiction”, across all our services, would be a fatal mistake. We’re not the people who decide that. You are.

So yes: party hats for all. This is a good move. The moderators now have the opportunity to update the forum. We think you’ll like the upgrades. But at heart, we trust, the forum will remain the community center it has always been.

I’m pleased to announce that the IFTF accessibility testing program has at last commenced its testing exercise. We would like to extend our gratitude to the AbleGamers Player Panels program for helping to gather more than two dozen players with disabilities willing to play our specially prepared test games and report on their experience.

And, of course, our deepest thanks go out to the testers themselves! We’ll collect their feedback over the rest of January, turning that into a report that we’ll present to the IF community later this year. Testers will receive modest gift cards for their participation, so this work also comes to you via IFTF’s financial donors — a special group of people which, as I never tire of reminding y’all, anyone can join at any time, and to any degree.

We have an interesting gap in our present disability coverage that we’d like to fill, though! While many of the initial group identify as vision-impaired — and we absolutely value their input — very few refer to themselves as fully blind. Recognizing the historically special place that text-based games have among the community of blind gamers, we’d like to invite more self-identified blind IF fans with some time to spare this month to help us with this project. If this interests you, please drop me a note.

I also bear a special request from AbleGamers president (and IFTF accessibility committee member) Mark Barlet: if you are a blind IF fan interested in helping video games of all kinds improve their accessibility, Player Panels would love your help! You can learn more about the program here, including information on joining the effort. According to Mark, Player Panels seeks to improve the number of blind gamers within its ranks, and he hopes that this partership with IFTF — AbleGamers’ first foray into interactive fiction — can help with that.

I took some time over the holiday to improve the IF Archive setup. This isn’t fancy stuff, but it’s worth mentioning.

First, the directory URLs no longer have capital X in them. You might remember directory URLs like https://ifarchive.org/indexes/if-archiveXgamesXcompetition2018.html. That was an old hack. We’ve transitioned to sensible-looking URLs like https://ifarchive.org/indexes/if-archive/games/competition2018/. (The old ones will still work, though!)

The Archive has been running on a Linode virtual Linux instance with 20 GB of storage. We have 14 GB of IF-related files these days, which is getting close to almost being a squeeze. So I upgraded the instance to 50 GB of storage.

(I realize that 14 GB is fishbait these days. One AAA game or one season of streamed television is larger than that. But when you’re talking about hand-crafted text adventure game files, a gigabyte is really a lot.)

I’ve also put the server on the Cloudflare caching and distribution network. Cloudflare is a popular (and cost-efficient) CDN, and plenty of web sites use it without making a big deal of it. So why do I bring it up?

Roll out the history machine…

Back in, hmm, 2000 or so, when we were first updating the IF Archive to be a web service, the Web wasn’t that big. Bandwidth came in small buckets. We had permission to host the server at CMU and rely on their network, but we didn’t want to use a lot of their network.

So we asked around for volunteers to host copies of the Archive. The mirror maintainers got permission to copy the Archive files through a private rsync channel. In return, they agreed to make those files available on their own web servers. The address http://mirror.ifarchive.org/ was configured to redirect to a randomly-chosen mirror server. So we were able to distribute load over a bunch of servers and donated bandwidth.

This worked pretty well over the years… but not perfectly. We never really had procedures for monitoring the mirrors — making sure they stayed in sync, notifying hosts when they stopped working, finding replacements if they stayed offline.

Cloudflare now takes up the job which those volunteer mirrors handled. It’s done for money rather than love, and in that sense, it’s the end of an era for the IF Archive. But it’s not a lot of money and it works really well.

(And you can now express your love with money! Donations to IFTF help support the Archive and all our other programs.)

The most current mirror list remains visible on the IF Archive web site. It doesn’t include everyone who volunteered over the years, and it’s already out of date. We’re not going to continue updating it. Nonetheless, please take a peek and say “thank you” to everybody who has helped support Archive operations over the years. We’re grateful.

Hi, I’m Dan Cox. I’ve been creating tutorials, videos, and other guides for Twine for over six years. I’m also the managing editor of the Twine Cookbook project.

Soon after joining the Interactive Fiction Technology Foundation’s Twine committee last year, I started talking with other members about wanting to collect examples of Twine code into a central place. I learned that there had already been a proposal to create a Twine Cookbook along the lines of the Inform Recipe Book or [Ren’Py Cookbook][renpy-cookbook]. The proposal was similar to what I was thinking of, but also involved covering many of the common problems in Twine.

After discussing different ways it might be done, Chris Klimas proposed looking into using GitBook as the format and to host it on GitHub. Iterating through different possible designs and layouts, we settled on grouping by topic the solutions for each story format that is built into Twine. After starting with over a dozen initial entries, we planned to have rolling updates every few months where parts could be updated and new examples added as needed.

As of late 2018, we are celebrating our first full year of running the Twine Cookbook. It is officially at version 1.0, but the current version represents multiple updates by a half-dozen contributors and hundreds of hours of work in creating and maintaining different topic areas across now over 130 pages of content.

Lessons

I often use the terms “running” and “managing” to describe my role with the Twine Cookbook. I set its rolling deadlines and try very hard to meet them. I do a full editing pass on all content, and I often prompt or ask other people to contribute code, documentation, and their ideas for how to improve it. The content itself has come from many different regular contributors like Greyelf, Chris Klimas, and Thomas Michael Edwards who provide their own feedback on its content and how it might be improved.

1) Open means open.

As an editor on the Twine Cookbook, I try to be transparent about its changes, deadlines, and how I handle code commits. Everything is done in the open, and that means that anyone can propose any changes to any section. Those suggestions are still filtered through other users, and I ultimately make a decision about how feedback is included, but the openness of the Twine Cookbook means that we listen to everyone.

2) Compromise.

While listening to feedback from different sources can be helpful, balancing that feedback against present and future content demands is another important challenge. As an editor, I have to remind myself that I cannot make everyone happy—including myself. Often, I will want to keep picking at entries to try to make things as perfect as possible. Others, I know, will often propose solutions that are more efficient or optimized for certain problems.

All of these, including my own opinions, have to be balanced against the overall needs of the project. While I am “running” the project, I am highly open to what others tell me and how they would approach different topics. I don’t always use their feedback, but I always try to listen to both what they are telling me and what theme or message might be behind it. Solving these problems is as much a part of being an editor as trying to clean up code and fix punctuation.

3) Don’t try to cover everything.

Early on in the Twine Cookbook project, the committee had conversations about what should—and should not—be in the Cookbook. These conversations revolved around what were considered common solutions on the one hand, and not trying to include hundreds of lines of code on the other. In the end, we reached a compromise that examples would go into the Cookbook as long as they were to solutions to frequent problems and were something someone would think to find in the book. Then, of course, people stated asking for more complex and advanced examples.

One of the constant struggles of writing tutorials and documentation for Twine—and this comes from doing this for years now—is that what many consider “simple,” just as many do not. The general assumption of the Twine Cookbook is that anyone reading an entry does not have advanced knowledge of CSS and JavaScript. They are looking for a solution or inspiration for a future project. They might not know what functionality does, or even that it exists at all.

At the same time, there is a strong pull to try to cover many of the things that browsers can do that Twine can support through JavaScript. The general reply I give when people ask what Twine can do is “anything a web browser can do,” which to an extent is true. As long as it is supported in JavaScript, Twine can do it. However, that does not mean that advanced functionality like gamepad support and virtual reality that have APIs in modern web browsers need Twine Cookbook entries. While people can use those in their projects, not that many Twine users would be interested, and other libraries exist to simplify many of the issues that would bloat the Cookbook to explain in detail, such as cross-browser support and differences in API.

4) Be open to change.

While being open and willing to compromise may seem to cover many of the challenges of being an editor for an open-source project, one of the most important lessons to learn is to be open to change. Finding a compromise can be important, but so is a willingness to change previously-established rules.

When the Cookbook first started, there was an unwritten rule that every topic area would include three examples: one for each built-in story format. For whatever the topic was, it would be covered in every story format. For about six months, this lasted as the rule. And then special cases started to develop.

Some problems are much harder to solve in one story format and others. Integrating anything using JavaScript, for example, is significantly harder in Harlowe than Snowman. And solutions that rely on macros and built-in functionality for styling code are far easier in SugarCube and Harlowe than Snowman. The idiosyncracies of each story format make it complicated to develop universal solutions. Some solutions, we finally decided, simply can’t exist in all story formats.

The same can be said of individual example credit. Looking back on the very first release of the Twine Cookbook, the original plan was that many different contributors would write their own versions of solutions which would be compiled together and linked by topic. This proved to be wildly ambitious and completely wrong. Some people have and continue to contribute code and feedback, but the vast majority of the users of Twine and the Cookbook have become what I call the “silent” community.

I have learned from talking to people both in person and through private online conversations that many people appreciate that the Cookbook exists, but they are often at a loss at what they could individually contribute. Educators especially, a group I claim as my own, often have suggestions for how their students might use the resource, but have to create their own specialized notes for their courses. They can give advice and feedback, but not code or work on the documentation itself.

In trying to decipher how best to work with this “silent” community, I have turned to existing resources: the Q&A, Twine Twitter account, and the Twine Discord server. I try to look through what people are discussing, problems they might be having, and what they ask about. I then make a list of topics that should be covered and try to determine what other topics are dependencies on them. For example, if people are discussing using an external library with Twine, I know that we need sets of examples on both using JavaScript and another set on using external resources and then to link them together.

Looking at what people are using means also shifting away from individual scenarios into examples that build upon each other. The original planning was that other developers would add code, but it turns out that the best changes came not from other authors, but those first learning Twine. By watching what people were struggling with, I was better able to adapt the Cookbook to that audience. Although talking with them would be the best way, I have not always been in a position to do that. Often, I work through what people ask about and how they discuss their issues, playing the role of an ethnographic researcher to my own group and community.

The NarraScope planning process continues! We’ve just posted a call for proposals for talks and panels.

The details are all on the web site, but to sum up: we’re looking for cutting-edge discussions about adventure games, narrative design, interactive fiction, and anything else that falls under our umbrella. We hope to represent a wide range of viewpoints — indies, academics, communities outside the gaming mainstream.

NarraScope 2019 will take place at MIT (Cambridge, Massachusetts, USA) from June 14-16, 2019.

Proposals are due by January 18th. We expect to have one-hour talks and panel discussions, plus probably a session of lightning talks (five to ten minutes).

We regret we are unable to cover travel expenses for speakers this year.

Thanks in advance!

IFTF is pleased to announce that the Treaty of Babel document is now under a Creative Commons License.

“Hang on, the what?” I hear you ask. Yeah. I know.

When I made this change to the web site, our benevolent president Jmac asked “Is this worth a blog post?” And I said “No.” It’s housekeeping. It’s a line that I forgot to add when we brought the IF Archive site on board last year. It’s one small step towards creating an open, nicely-organized repository of IF specifications, but it’s not exciting in its own right.

But Jmac pointed out that this was a good opportunity to mention the Treaty of Babel. It’s a funny bit of IF infrastructure which has existed for more than a decade. Some of Babel’s ideas are in common use, but the spec doesn’t get a lot of attention. It’s worth a blog post.


Graham Nelson came up with the idea for the Treaty of Babel back in 2006. He was working on the beta version of Inform 7, and he wanted bibliographic data to be a first-class part of the ecosystem. An author writing an Inform game should be able to specify title, author, release date, and other such information in a way which could easily be extracted. That way, if you had a library of Inform games, you could wave a tool over them and generate a library-style catalog.

But as soon as you say that, you realize that it should really work for all IF systems, not just Inform.

Graham contacted a bunch of IF tool developers — Mike Roberts for TADS, Kent Tessman for Hugo, and so on. (Twine didn’t exist yet!) I was involved as an IF Archive maintainer, and also as the maintainer of Blorb, the IF packaging spec which Inform used. We hammered out the details, and then L. Ross Raszewski wrote it up as a document. It was announced as the Treaty of Babel — thank Graham for the slightly self-deprecating name. You can see the original announcement on Usenet, which was the IF community medium at the time.

(Just a few days later, Graham posted the first public beta announcement for Inform 7.)

So what is Babel good for? The web site gives the original intent:

  • ISBN-like unique ID numbers for story files, old and new, produced by commercial or non-commercial compilers living and dead;
  • a standard format for cover art and bibliographic data;
  • a web server able to provide these for a given ID number;
  • a command-line tool able to identify and extract data from story files in any format;
  • reference software providing a format-neutral API for reading story files, and removing “wrappers”.

Of these, the ID numbers (“IFIDs”) and the standard format (“iFiction”) are now well-established. You can see IFIDs listed on game pages at IFDB. The iFiction format is less visible, but it’s embedded as an XML snippet in every Inform game, and other story formats as well.

The web server plan never got off the ground. This is entirely my responsibility; it was intended to be an IF Archive feature, and I just never built it. My excuse is that IFDB launched in 2007, and that covered most of the indexing and cataloging work which the Babel site was intended to serve.

The final Babel goals were software. Like most reference implementations, they are not themselves widely used, but their existence was necessary to create and validate other tools in the Babel ecosystem. Zoom, for example, was the first “modern” IF interpreter, supporting several story formats and a Babel-driven catalog of the user’s IF collection.


And now?

As we move into the new year, we are considering possible updates for the IF Archive. These are not urgent — after all, the Archive works, as it has worked for over 25 years.

But I’ve never entirely given up on the idea of Babel-indexed metadata. It might mean something different than we imagined in 2006. We don’t have to build everything out of CGI scripts, for one thing; the Net now teems with cheap web service tools. We also need to think about IFDB, which has its own database with its own indexing system. Perhaps we should pull IFDB keys into the Archive’s data collection and connect them to IFIDs.

As I said above, we also have the notion of a community repository for IF specifications and standards. IFTF now holds the community specification of the Z-machine under a Creative Commons license. Other documents are stored on the IF Archive, but with no consistent licensing, ownership, or findability. (For example, the Glulx spec is readable and CC-licensed, but it’s owned by me personally rather than by IFTF. And you have to know where to look.)

Over the next year we intend to regularize this stuff, make a tidy index page, and invite other spec maintainers to contribute documents.

Look for more ideas and announcements in the coming year.

IFDB, the Interactive Fiction Database, is a web service which collects information about published IF. IFDB was created by Mike Roberts; he continues to maintain it for the benefit of the IF community. All information stored on IFDB is contributed and edited by IF community members.

Since its launch in 2007, IFDB has become an indispensible resource for the community.

Last year, we took a look at IFDB and asked ourselves, “How is this going?” The answer, of course, is that we shouldn’t be asking ourselves — we should be asking the community, the people who use IFDB. So we set up a survey and passed it around.

To be clear: we did this as friends of IFDB. Mike Roberts did not commission this survey, and he has not committed to any particular work based on the results. When the results were in, we collated them and sent a copy off to Mike. And then… we kind of let the whole project slide. Oops. (It’s been a busy year.)

We didn’t intend to keep the results secret; we just forgot to post them anywhere. That oversight is now fixed. So here you go: the results of the 2017 IFDB survey.

So now what?

As the page says, IFDB is not an IFTF service. We can’t hack the server and make changes. However, we can act as community organizers, and think about ways that the IFDB user community could better serve themselves.

Interested in contributing time to IFDB editing or documentation? Drop us a line.

After working with the IFTF, I’m pleased that the Undum website and documentation is now available again, at GitHub.

It has powered a number of games, occasionally pops up among IFComp entries, but has never been as widely used as other tools. If you are unfamiliar, allow me to introduce it. Undum is a choose-your-own-adventure interactive fiction tool, with a couple of very specific design goals. One aesthetic and one technical.

I have a passion for the texture of books. I wanted to create a tool where the works exude physicality and play has the feeling of reading prose. The visual design is unashamedly skeuomorphic: from before the time we learned to distrust such things. It begins with letterpress titles and marbled paper, and opens to cream textured background and off black ink. My hobby is bookbinding, this was a virtual version. When I created it in 2009, CYOA games were structured like the original books: read a paragraph, make a choice, the screen clears and new text appears. In Undum, the choices fade, disappear, and the surrounding text rearranges to form a resulting narrative. It looks somewhat old now to my eyes, but the basic idea I think is sound. Many other recent titles – inkle’s games for example – use a similar effect, at least for small sections of text.

Technically, both Undum and the games that target it, are written in JavaScript. I hoped this would make it accessible for a wider range of dabblers, requiring transferable skills rather than learning a new language. It also made it achievable to write and document over a few weekends: I didn’t have to worry about parsing, or creating a complete runtime. But the best benefit, and in some ways the one least exploited in practice, is the ability to use Undum as part of a bigger game. I imagined a strategy game with CYOA elements, or a piece of interactive fiction using natural language generation to be different each time.

Between the first and second release, I fell in love with Alexis Kennedy’s quality-based narrative structure, as used in Fallen London (at the time named Echo Bazaar). Rather than specifying explicit options, a random selection can be drawn from a database, based on criteria that represent the choices made so far: this choice is allowed if ‘fear’ is greater than three, for example, that one if the ‘met the monster’ flag is set. This approach allows a choice to easily affect things much later in the story. And crucially, it allows new sections to be written and added, without manually rewiring the flow. In Undum, explicit and implicit choices are both supported, and interchangeable from moment to moment.

I left working on Undum to develop Varytale, a short lived commercial IF endeavour that shared a lot of the same aesthetic and narrative structure. And then I retired, and it lay fallow, aside from email help requests that still drip into my inbox. If you are curious, I think it is particularly suitable for writerly programmers, especially those who want to push the boundaries: hook up web sockets for multiplayer IF, send new content from a web server, break out of the narrative to play a mini game, or add rich media and video. I hope, with the encouragement of IFTF, it continues its afterlife powering interesting and form-challenging games.

Six months ago, we waved around the idea of hosting an interactive fiction conference in Boston. Then — six months of silence.

Surprise! We still exist!

…Apologies for the delay. Nailing down a venue turned out to be a more protracted and painful process than we expected. It’s still not entirely nailed down, I’m sorry to say. But it’s solid enough for us to announce:

NarraScope 2019
Celebrating Narrative Games
June 14-16, 2019 — Boston, MA

The focus of the conference is not just “interactive fiction”. IF is a broad-ranging term these days, but not everyone uses it or thinks of themselves as “interactive fiction authors”. NarraScope will aim to cover the spectrum of narrative-focused games and interactive design: adventure games, Twine, hypertext, choice-based and parser-based IF, visual novels, procedurally generated narrative… Each of these forms has evolved into a community of practice. We want to create a space for these communities to come together, talk, exchange ideas, and discover ways to collaborate.

We are still finalizing the details of the venue and schedule. We expect to be in Cambridge, in coordination with MIT’s Comparative Media Studies and Writing department.

A call for speakers and talk proposals will be posted soon! Watch for news on our mailing list (join!) and on our web site.

Who are we? The Interactive Fiction Technology Foundation is a 501(c)(3) nonprofit organization which supports the tools, services, and community resources of interactive fiction and narrative games. NarraScope is IFTF’s first major public event. Here’s our conference committee.

Inclusivity statement: NarraScope celebrates the diverse voices of game design. We aim to create a safe, welcoming, and accountable space for all participants.