Bring Out Your Dead


Bring Out Your Dead is an event I am running over solstice, June 18 to June 25th. It is not exactly a jam and certainly not a competition, but rather an opportunity to purge old experiments and share what was interesting about them. For purposes of organizational convenience, though, it’s being treated as an jam. Here’s the text I’ve written for it:

Bring Out Your Dead is an event for sharing dead WIPs and experiments that you don’t expect to finish, but that you’d like to show to someone anyway. It’s a chance to cleanse your hard drive, move on from old ideas, and salvage some learning from things that didn’t work out. It’s also an opportunity for your community to learn from your mistakes — which can be just as useful as learning from a success. Ambitious follies, bizarre experiments, toys, and notions that in retrospect never had a chance — all are welcome.

You are also welcome, and indeed encouraged, to provide some context about your work. What were you trying to achieve? What do you think is most or least successful about what you did? Why did you ultimately decide to abandon the project? Are there things you think others could learn from the project?

There is no ranking in this jam: it’s not about competition and judgments. However, discussion is welcome, especially if you find something in someone’s entry that sparks your imagination.

To participate, you need only contribute items at the jam page during the time the jam is live. You are welcome to put in things that are not typical IF, if you wish.

I am mentioning this in advance because I know some people have already started thinking about what they want to contribute, but you do not have to put any special effort in, and indeed the initial point was to minimize special effort.

Not All Choice Interfaces Are Alike

I tend to write here about choice-based games as though they were all the same kind of thing, but that’s a perspective that very much comes from a history with parser IF and a tendency to distinguish clicking from typing. And I will freely admit that a few years ago I was pretty obtuse myself about the differences between types of interface option.

In fact there are many kinds of input methods for communicating the player’s decisions in a story, and many possible or actual variants, some of which allow the player to type a keyword from a set list, or search from among hidden choices by typing, or perform parser-like commands by pushing menu buttons. Seen in this light, the parser is part of a continuum with other input methods, not uniquely distinct from them.

Much has already been written, of course, about controllers and input for games. See for instance Tracy Fullerton’s Game Design Workshop for a detailed discussion of control design in general. And people continue to experiment, as in this alt controller jam. However, most of these focus on non-text-based or non-narrative games.

Here I’m going to discuss several input methods for text-based and/or highly narrative-focused games according to the following metrics:

How much effort is it? How expressive is it? How ambiguous is it? How discoverable is it? How much pressure is there? How much is the player required to embody the actions of the protagonist? 

This is not the same as studying the verb set of the resulting games.

Continue reading

Writing Interactive Fiction With Twine (Melissa Ford)

WritingInteractiveFictionA curious and fascinating thing about Melissa Ford’s Writing Interactive Fiction with Twine is how it combines hypertext craft advice and Twine syntax tutorials with design expectations largely derived from parser-based interactive fiction.

This is a 400 page book about Twine fiction whose index lists Anna Anthropy once (in a passage discussing how she did geographical description in one of her games) and Porpentine never — though it does refer, without attribution, to the tiny Twine jam Porpentine ran. Steve Meretzky and Brian Moriarty appear, but not Michael Lutz or Tom McHenry or A. DeNiro or Caelyn Sandel or Dietrich Squinkifer, nor Michael Joyce or Shelley Jackson or other luminaries from the literary hypertext tradition either. The book has early and prominent chapters about how to design puzzles, inventory, and a room layout; fonts, text transitions, and CSS effects come quite a bit later, despite being much more common than inventory systems in practice. The section on genres starts with a helpful definition of the word “genre,” then runs through bite-sized descriptions of some common fiction genres — rather than, say, trying to describe the range of genres represented in current Twine fiction. The section on story structure explains terms such as “climax” and “exposition” from scratch, assuming essentially no writing-workshop-style experience from the reader.

This writing style, along with the tendency to draw examples from Narnia and Harry Potter, suggests that the author intends the book to be accessible to younger users as well as adults. It would probably be a bit over the head of most young children, but I could picture a motivated tween handling it just fine. Possibly that accounts for a decision not to explore much of the most innovative content for which Twine has been used. If you’ve read Videogames for Humans, almost none of what you saw there is replicated or even mentioned in this book.

Continue reading

Plot-shaped Level Design

Periodically I find myself giving the same advice to new story-game designers, and I’ve been repeating it a good bit lately, so I’m writing it down here, though I’m sure many of my readers are already familiar with it:

Your job is to make it as hard as possible for the player to finish your game without understanding your story.

I don’t say “make it impossible” because you cannot control for a player who, say, is not completely fluent in the language of your story playing it on a glitchy mobile device three vodkas into a transatlantic flight. It’s possible for anything to be misunderstood. But the aim is for a person playing in good faith and with full capacity to be guaranteed a complete story.

This means that the player must encounter, and ideally make use of, every critical piece of information in the story. “Encounter” might mean “read on screen” or “hear in dialogue” or “see in a cut scene,” but encountering information is much less valuable in an interactive context than using information. So it’s best if the player needs to act on each of those critical beats.

To design for this, start by identifying critical beats. What are the facts the reader has to know in order to understand this story?

This is a subset, probably a very small subset, of all the facts the reader could know. Many world-building details and secondary character motivations can probably be omitted without ruining the experience. But if your story’s impact depends on the player learning the protagonist’s secret motives, then that information is vital.

If there are two (or more) possible endings to the story, each ending might require a different set of plot beats to work fully. (It’s long in the tooth now, but my 2006 game Floatpoint lets the player make an important diplomatic decision that can turn out any of a number of ways; however, in order to get the puzzle materials required to communicate a particular choice, the player has to experience vignettes that are relevant to that outcome. This was an attempt to guarantee that each ending hit all of its critical beats.)

Figure out which information is vital. Make a list. Be honest with yourself and keep the list as short as possible.

You might find yourself getting bogged down in minutiae that have nothing to do with your major themes and characters. (“I’ve worked out this really clever escape for the killer and there are 9 different fiddly things the player needs to understand in order to get it…”) If you find yourself in that situation, you need to streamline, find some emotional reason why those beats are interesting, or — if the whole fun of the thing really is an enormous logic puzzle — structure your game/story so it’s just that one puzzle. That can totally work — see Toby’s Nose, Oxygen, Orevore Courier, Rematch, and arguably Her Story. But don’t get precious. If something isn’t working, save it for next time.

Once you have your list of vital data, figure out dependencies. Which facts depend on other facts to make sense? Which facts have the greatest impact if they come after other facts? If learning the protagonist’s secret motive is more effective after we see them commit a crime, that provides a motivation for ordering. Turn your list into a dependency chart.

Next: this chart you made that looks strangely like a classic puzzle dependency chart or level design chart? It is one! Assign puzzles, geographical barriers, stat dependencies, or choice flows that match the shape of the plot chart. Theme accordingly. If your story requires the player to see the crime before learning the motive, gate the reveal of the motive with a puzzle that can only be solved with information from the crime, or place it in a room that can only be reached by passing through the space where the crime is committed.

This method still applies to choice-based narrative. For a nodal choice game, you have a lot more control over how the player moves through your story than you would in an open world game, for instance, but some of the same points apply when it comes to focusing player attention. If you have a key story beat, don’t just narrate it and move on. Players skim in interactive stories, especially in choice-based stories where they know they’ll be able to keep moving forward regardless of how well they learned the establishing details.

If you need the player to remember something, give them a choice about that thing. If you can’t let them choose whether the thing happens, you can still let them choose how it happens, or how the protagonist feels about it, or what they’re able to salvage from it.


Mid May Link Assortment

Based on feedback, I’m experimenting with a twice a month approach to link roundups. I’m hoping this will mean each individual post will be less overwhelmingly long, and time-sensitive things will be fresher.


This is only semi-IF-related, but there’s an event in San Francisco for enthusiasts of roguelikes, 6:30 PM, May 17. The talks include some discussion of procedural generation and narrative, so might be of interest to some here, though.

And, of course, Feral Vector is still upcoming: Hebden Bridge, Yorkshire, June 2-4. It will be fun. I will be talking.

If you liked the sound of Enter the Oubliette and you’re in range of Brixton, you’ll want to get tickets and go as soon as possible: the site is closing in another four weeks or so. Here’s Exit Games UK talking about the game and its closure, and a fuller discussion of why they’re closing over on their Kickstarter page. The short version is that their landlord has changed his mind about letting them renew the lease, and they don’t have a good place lined up to move to. Which is a shame — it’s a really fun experience. Here’s hoping they find another venue.

New releases

Bard Jam in April produced six works of Shakespeare-related IF. I haven’t had time to check them all out, but I was amused by David T. Marchand’s Armando the Bardo, which among other things uses some real-time effects that I don’t typically associate with Twine: for instance, there’s a guard character you have to sneak past when he’s described as looking the other way.

From Ryan Veeder, we got An Evening at the Ransom Woodingdean Museum House, a creepy parser game in which the protagonist is a docent at a historic home. It’s less silly and more scary than average for Veeder; and, as is often the case with Veeder’s work, it tosses in a bunch of elegant design tricks so casually that it would be possible to miss that anything virtuosic just happened. I’d really recommend this to people who are thinking about how to build a sense of dread in the open space of parser IF. The pacing of revelations, the use of light and darkness, the gradual changes in narration are all great. But An Evening is not played just for horror; it’s also a meditation on our relationship to the past.

The game comes with a link to a rainscape you can listen to while you play, and I recommend using this.

Alexander Systems (Darusha Wehm for Sub-Q) is a Twine story of dystopian work, punishment, and solitude. There are quite long passages between choice points, and the first few screens end with a single link-to-continue — the pacing feels rather different from the Twine average — but the prose is assured.

Starship Adventures is a new collaboratively-written ChoiceScript game, coordinated by Felicity Banks and including writing by a number of other authors:

You’re a naturally heroic and quick-thinking space captain flying a starship from world to world while keeping your hair groomed to perfection. It’s your duty to keep the engine running, the scotch flowing, the crew happy, and your outfit looking fabulous. There’s carnivorous flora, deceptive aliens, space anomalies, horrifying creatures, and too many arch enemies to keep track of them all! Can you survive?

Enchantedonsequel and Christyonsequel are two conversational games involving dialogue with a fictional character via Facebook, played on Facebook Messenger and “powered by Sequel”. These are adaptations of work by Felicity Banks and Joey Jones, originally available on other chat apps.

Mark Marino (of Living Will and the Mrs. Wobbles series) and Rob Wittig have also done a project with Sequel, which Mark describes thus:

In Baby Seals, Spencer and Heidi are drawn into a new Reality show in which Spencer gets to do fake Special Ops — unless they’re real.

My initial impression is that the interface, universal to all of these games, is a little on the clumsy side — Lifeline-esque choice-based interactions like this:

Screen Shot 2016-05-07 at 10.01.50 PM.png

…where the selection isn’t even about clicking the choice you want to make. Still, it’s interesting seeing various commercial attempts to do IF in the chat space. There are also times when you have only one option to select, and the UI makes it pretty unclear that it even is supposed to be your dialogue, rather than just a tap-to-continue after the previous person’s monologue. For instance:

Screen Shot 2016-05-12 at 10.57.22 AM.png

Here, context makes it clear that we’re selecting the (lone) option to say “I won’t,” but visually it’s not distinct from Spencer saying “I won’t!” and the protagonist doing a continue action. Then, too, the system doesn’t always cope gracefully with even a fairly brief distraction from the game. At one point I set Spencer aside for a moment to type up some notes — a pause certainly shorter than pauses that appear naturally in online chats in general, let alone a gap of hours — and when I returned and tried to pick an option, I got this:

Screen Shot 2016-05-12 at 10.59.32 AM.png

So it’s not entirely smooth or graceful yet, I’d say, and I already consider Facebook chat/messenger to be the Most Annoying Way To Chat (TM). That said, this is an accessible way to do Lifeline-alikes.

For my taste, this kind of game is immensely dependent on the appeal of the character you’re conversing with: during the time I played (which was not the full game), Marino and Wittig’s reality-show star Spencer reminded me very accurately of certain Hollywood-peripheral people I know in LA, and this kept things entertaining. Pieces with a less-strong protagonist voice might struggle to make the format work.

Continue reading

Running an IF Meetup

Screen Shot 2016-04-06 at 9.41.33 AM.png

The Oxford-London IF Meetup has now been running for a little over two years, and I thought I’d stop and talk a bit about what we’ve experimented with doing and how it’s worked, and what I think could be better.

First of all, I should say that the meet has been more successful than I had imagined at the beginning, and I’m very grateful to everyone who’s come and contributed their ideas and input. I’m especially grateful to Failbetter for supplying a venue; without access to their space in London, we would have had to find (probably expensive) meeting rooms in central London, which would add quite a lot to the overhead of running the group. Having a supplied venue means that we can continue to offer the meetup without charge to members.

From an organizational perspective, though, it’s also been more challenging to run precisely because of the interest level. What I expected to have happen was that I’d announce a meetup, I’d get six or eight diehard IF community enthusiasts showing up, and we’d grow outward starting with a small set of committed volunteers who could help me figure out how to scale and who wanted to pitch in for what. In practice, we routinely have 30ish signups for London meetings, and people are coming from a range of backgrounds. So I’ve had to improvise a bit from the outset.

But I did have a set of specific goals in mind, which were

  • create social connections between people interested in IF (basic networking)
  • build a peer group to support people working on games and tools — which in an ideal world would mean everything from mentoring/encouragement for new authors to expert feedback for advanced tool-builders
  • educate myself and other people about the range of work currently being done

and — informally but importantly —

  • have enough fun that people come back

Here are some thoughts about what has worked and hasn’t:

Continue reading