IFTF has published its Transparency Report for 2018 as an eight-page PDF. It summarizes IFTF’s activity from January 2018 through December 2018, including a high-level accounting of the organization’s financial income and expenditures.

As a public-service organization that many people entrust with their time, attention, and money, IFTF presents this annual report in an effort to show how it has applied its community’s investments over the past calendar year.

IFTF president Jason McIntosh wrote most of it this year, so it also contains at least one extremely dry joke. Please give it a look at your own convenience.

The registration page for NarraScope 2019 is now open.

Really we opened it up on Friday — you may have seen the tweets. But we were quiet about it through the weekend in case any last-minute problems turned up. Maybe they still will, but now it’s time to shout about it!

While we’re shouting, here’s some more things you should know:

The event is limited to 500 attendees. The venue rooms only hold so many people.

We expect registration to sell out well before June. There will be no at-the-door registration! We’ll post regularly to let people know how fast the tickets are selling.

We want NarraScope to be accessible to everyone interested in narrative games, regardless of their background. Therefore, we have several classes of ticket available.

  • The standard membership costs $85. This gives you access to the entire conference; it also includes lunch Saturday and Sunday.

  • If you can’t justify the cost of the standard membership, we also have a restricted-budget membership for $35. This gives you access to the entire conference, including lunch Saturday and Sunday. That is, it’s exactly the same as a standard membership — it just costs $50 less.

  • To counterbalance this, we offer a community supporter membership for $135. This is, again, exactly the same as a standard membership — it just costs $50 more. The extra money goes to support one restricted-budget membership.

  • Current MIT students may register for free. Our thanks to MIT for giving us affordable function space on campus! The MIT student membership gives access to the entire conference, but does not include lunch. Sorry about that.

  • If you are a confirmed speaker, we have emailed you a complimentary registration code. Check your inbox.

By the way, the restricted-budget and community-supporter memberships are entirely on the honor system. Pay what you can afford. We hope and expect that it will all balance out in the end.

Also: we’re aware that Boston is an expensive city, and a $50 discount on membership doesn’t go far towards the cost of travel and housing. We apologize that we can’t do more. We’ll see how it works out this time, and we’ll consider every option to make NarraScope more accessible and affordable in the future.

(If you are interested in sponsoring NarraScope, please contact us!)

Beginning in December 2018, we debuted Twine News. It’s a roundup of Twine game releases, educational resources, events, and pretty much anything else that people in the Twine community would be interested in. If there’s something Twine-related you’d like to get the word out about, please submit a suggestion using the site’s online form. If you’d like to follow the Twine community more closely, there’s also a Subreddit and Discord, too.

IFTF plans to publish its third annual transparency report by the end of March. This is a little later than last year’s publication date, due in part to my own coming up to speed with the authorship task after former board member Flourish Klink handed the job over to me. I thank the board and the community for its patience, and will of course update this blog with a link once the report goes public.

I also have the privilege of overseeing the IFTF Accessibility Testing Committee’s report, which — after a rather longer delay! — looks on-target to appear later this year. The accessibility program successfully concluded the testing exercise it began in January, with its public call for more participants resulting in a tidy doubling of the initial tester-pool. (We also extended the testing period by a week to better accomodate these later arrivals.) The committee now possesses accessibility survey responses from several dozen players with disabilities, including both IF veterans and those new to the form. We now turn our attention to transforming this data into a meaningful report, and I very much look forward to presenting it to the community.

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!