Craft

ICIDS 2015: Highlights

Last week I attended the ICIDS 2015 conference in Copenhagen. The conference was about academic research on Interactive Digital Storytelling (IDS) which is very close to what we call Interactive Fiction, with some key differences. The topics revolved mostly around making computer-generated story content, emergent gameplay, and autonomous non-player characters. In a nutshell you could say that while IF is about using computers to tell stories, IDS is more about making computers tell stories.

"Bird Attack", a game made with Inklewriter presented at the conference

The IDS people seem to be well aware and at least superficially following the IF scene. People like Emily Short, Squinky and Porpentine were mentioned several times. Inklewriter was used to build a game in one study. The interest is naturally in things that are close to the areas of research, so games that have something to do with computer-assisted content generation are the ones that get most attention.

All conference papers can be downloaded here. The ebook download is available for free for an unspecified time so it's best to grab it while it's there. Once the offer expires the download will cost more than 50 €.

The defining dilemma with IDS seems to be that computer-generated content is often random and incoherent in contrast to human-written narrative. On the other side of the scale you have generated content that's random but allows for emergent stories, and on the other side there's human authored content that's coherent but restricts the story to the pre-written plot. A lot of effort is going into bridging this gap so that generated narrative would have the best of both worlds: highly emergent plot that's still a coherent whole.

One of the suggested approaches (Ryan et al) was detecting sensible plots from a story world where many players or autonomous NPCs interact with each other and create emergent content. Dwarf Fortress was used as an example of such world. The method was to analyze things like when individual events happened and what kind of narrative tension the events had. This was a just a theoretical idea at this point so there wasn't yet any actual algorithm that could do this.

Hartmut Koenitz has taught interactive narrative classes using his own ASAPS system which seems to be one of the more mature projects, although it's available on request only. He has identified some tendencies that his students have when writing interactive stories:

  • Tendency to build strictly non-convening branches: the story branches but there's always only one path to a given passage (traditional CYOA book style)
  • Strong binary choices ("do you a) give your money to charity or b) become a crime lord") instead of more nuanced options
  • Mechanistic pacing: each passage ends in a choice
  • Narcissistic content: the students want every reader to see all content the game has

Koenitz also talked about how effective temporary removal of control can be for an interactive story. If you sometimes take away control from players, the control they are left with becomes more precious to them.

Alex Mitchell analyzed reflective rereading of digital narrative, and presented three types of motivations for rereadings:

  • Partial rereading: rereading because you can piece together more of the story after you've seen the whole thing (e.g. Memento)
  • Simple or unreflective rereading: you want to recapture the experience you had the first time
  • Reflective rereading: having seen the work before, you know what it's about and want to view the work with that extra information, for example to identify details that might have been missed the first time (e.g. 6th Sense)

He also identified three types of experiences from generated or highly varying interactive narratives:

  • Eliza effect: The system looks complex but is actually simple. Telltale's games were used as an example of this: at first playthrough they seem to offer a large degree of choice, and the games do their best to reinforce this interpretation (periodical "They will remember this" notifications for example), but on replay it becomes evident that the plot is actually largely predetermined.
  • Tale-Spin effect: The system looks simple but is actually complex, and the player may never become aware of the underlying complexity.
  • SimCity effect: The system is complex and works with the player to build up understanding of the complexity. Emily Short's Blood and Laurels was used as an example of this type of game.

A slide about Blood and Laurels. Click to show contents in plaintext.

New Dimensions in Testimony is a project that has filmed interviews of a holocaust survivor. A holographic projector shows him in 3D and you can ask questions that are interpreted with voice recognition software. The aim is to replicate a face-to-face conversation as accurately as possible so that people can have that experience even after it's not physically possible anymore.

The end result looks like something out of Star Trek, and the numbers are impressive: the system has 1700 different responses and testing showed that there was an appropriate answer 95% of museum visitors' questions in the database, although due to speech recognition and language parsing issues the system replied correctly only two thirds of the time. They were confident that question understanding can be further improved.

Kate Compton talked about her generative text tool, Tracery, and announced a new IDE for it at tracery.io. It basically takes a certain data structure and generates variations based on the list of text strings given: 

{
  "origin": [
       "#location# you can see a #landmark#."
  ],
  "location": [
      "Behind the #building#", 
      "Far ahead", 
      "Somewhere in the distance", 
      "Nearby"
  ],
  "building": [
      "house", 
      "shack", 
      "gazebo", 
      "garage"
  ],
  "landmark": [
      "river", 
      "forest", 
      "beach", 
      "hill", 
      "lake", 
      "swamp", 
      "mountain range"
  ]
}

The placeholders (#location#, #landmark#, #building#) would be replaced with random items in the lists, resulting in e.g. "Behind the gazebo you can see a beach" or "Far ahead you can see a swamp."

Tracery is probably best known as the main component of Cheap Bots Done Quick which is a Twitter bot making service. I tried it out and made a couple of Twitter bots, and it really lives up to its name: it took less than an hour in total and most of that time went in trying to find suitable word lists.

Elizaveta Shkirando from Ubisoft talked about "betatesting" story elements in games. Usually in AAA game development narrative elements have low priority and story writers are brought in at a late stage when it's practically too late to get feedback. Ubisoft has tried to change this by making it possible for writers to get narrative feedback much earlier.

The writers made a 5-10 page long summary of the script (which was not too big and not too vague) that was given to two groups. The first group was writers not involved in that particular project, and the second group the game's designers who weren't directly involved with writing the script. The groups were able to make notes to the script, ask questions from the writers, and then answer a questionnaire that had evaluations like:

  • Appreciation: "I enjoyed this section of the script."
  • Comprehension: "I understood what was happening in this section of the script."
  • Interest: "I want to know what happens next in the story."
  • Character motivation: "I understand the protagonists motivations in this part of the story"
  • Character progression: "I understand what the protagonist must do next."

The questionnaire repeated after every section of the script, and at the end there was a final questionnaire that had questions about overall likes and dislikes, most memorable moments, satisfaction with the story's ending and so on. Afterwards the testers who gave the most interesting and insightful comments were invited to a group discussion with the writers.

Shkirando also stressed that it's important to ask and receive positive feedback as well instead of just lists of problematic issues. This helps the writers to not lose the good parts when they're fixing the problem areas.

Melissa Roemmele showed a story writing assistant that could help alleviate writer's block by adding a new sentence to the story on demand. The corpus is about 20 million stories collected from blogs, consisting of in total about 700 million sentences. The software analyzes the story that's being written and picks a sentence that seems to be the best fit for the context.

It's uncertain how well the tool would work in practice, but it would be at least a cool toy to play with. Unfortunately it's not publicly available.

In addition to the presentations, there were posters and game demonstrations. Some of the games were more traditional and not necessarily about interactive narrative, at least in the traditional sense. Here are a couple of picks:

An "interactive documentary game" that lets you make a documentary about a crime organization. The material for it is real and they're filming it right now. The release is set to next year but the feature list seemed so ambitious that it seems likely that 2016 is an overly optimistic target.

Blue Behold by Karleen Groupierre is a physical setpiece that's "painted" by a video projector. It comes with glasses that track eye movements: a spotlight follows the player's gaze and interacts with the environment. It's really beautiful and fun to play. Too bad the set's physical size and special equipment mean you need access to the original work to be able to play it.

Don't Let Them Die by Rob Homewood is equal parts artwork and game. The game consists of a flock of birds flying around a pretty landscape. It pulls stock data from the Internet every minute, and if it detects a massive drop in stock prices in a short period of time, the birds die. Therefore you play the game by preventing stock market from crashing: by being part of society and consuming.

It could of course be debated whether the humankind can play a game like this, or whether it's a game at all. As an art piece it's multifaceted and thought-provoking; easily the most interesting demo in the conference.

Don't Let Them Die

The problem with a lot of academic software projects is that they're built for the purposes of a single, often very narrow, research project. It might be about, for example, a single aspect of autonomous NPC behavior, and a game is made focusing on that only. The end result is either a short demo that looks very interesting but isn't complete, or a system that does that one thing they're studying but isn't really usable in real world applications. It seems very similar to what happens with IntroComp games: when asked about it, every single author says that afterwards they're going to expand and release the game or tool they've created, but in real life that happens about as often as an IntroComp game gets a full release.

One project from Reykjavik University looked very promising: it aims to combine all these small projects into one complete system that could be used to make real games. It includes five different technologies that are way beyond my understanding, but apparently the end result would be a tool to make complete simulated story worlds.

Integration poster

Where'd you learn to shoot like that?

This is the sixth article in the Back to the Future theme week series.

Doc Brown with a custom made precision rifle

There's a dramatic principle called Chekhov's gun:

Remove everything that has no relevance to the story. If you say in the first chapter that there is a rifle hanging on the wall, in the second or third chapter it absolutely must go off. If it's not going to be fired, it shouldn't be hanging there.

The idea is to remove anything that's not going to be relevant to the story, or in other words, don't add too many red herrings.

A real life example: my very first work of IF was about a hard-boiled detective who, as I first assumed, has to carry a handgun as the genre trope dictates. The problem was that there was no actual use for the gun at any point in the story. It was just inventory filler for the sake of "realism." It wasn't until a beta tester brought the subject up when the gun had to go.

Let's take another practical example. A story features a bedroom. There you have a bed and a nightstand. On the nightstand there's a ballerina-shaped porcelain clock. As per the Chekhov's gun principle, we ask ourselves what purpose do these items have. The bed is there because it's an essential part of a bedroom; there would have to be a good reason for not having one there. The night stand is there to support the clock.

That leaves the porcelain clock. Why is it there? Does it play a part in the plot later on? Does it tell something important about its owner? Whatever its purpose, owning such a tacky thing is notable enough that it would have to be explained. It can't just spontaneously exist without a reason.

If it turns out that the clock is not a Checkhov's gun, i.e. it doesn't have a relevance to the story, then it should go. And since the only purpose of the nightstand was to provide a place to put the clock on, it shouldn't be mentioned either.

Note that, in the context of text-based narrative, not mentioning something doesn't mean that it doesn't exist in the story world. It just means that it's not significant enough to mention (or implement). Every location has tens or even hundreds of things that could be realistically expected to exist but have no relevance and therefore aren't mentioned or implemented.

The reverse Chekhov

Here's a transcript of an interview from the documentary Tales from the Future: In the Beginning... where Back to the Future writer and producer Bob Gale talks about writing the script.

We use the index card method of plotting. So we would have a big bulletin board in our office, and we would say "ok, we know, for example, Marty goes back in time." So, an index card goes up, says "Marty goes back in time." And then, towards the end "Marty goes back to the future," that's another card.

So we said ok, wouldn't it be cool if he invented rock 'n' roll. So we put up a card saying "Marty invents rock 'n' roll." Well, we need to establish that he can play rock 'n' roll. And that he wants to play rock 'n' roll. So that means that somewhere on the bulletin board before the card that says "he goes back in time": "establish Marty's desire and ability to play rock 'n' roll."

Two index cards and corresponding images from the movie: 'Marty's good on a skateboard' and 'Marty invents the skateboard'

Same thing with the skateboard. If he's going to invent the skateboard, show him on a skateboard. So these pairs of index cards would come up.

In light of this technique I'd like to turn the Chekhov's gun principle around:

If a rifle goes off in the second or third chapter, in the first chapter you must say that there is one hanging on the wall.

This is perhaps even more useful than the standard Chekhov's rule, at least in the early stages when you're designing the overall plot of the story. Working backwards by taking things you want the story to feature and adding things that support that feature to earlier points in the story will add a nice dose of authenticity to the setting and characters.

Clint Eastwood never wore anything like this

This is the fifth article in the Back to the Future theme week series. Contains spoilers for the first film.

Doc Brown Common writing advice is to always avoid clichés, but that's too simplistic to accept as a universal rule. Clichés and sterotypes serve to support another advice: Show, don't tell.

The main purpose of stereotypes in narrative is to establish character archetypes that are already familiar to the readers or viewers. Take, for example, the character of Doc Brown from the Back to the Future films. The "crazy wild eyed scientist" look immediately communicates a lot of information about the role of this character. We can expect some advanced, perhaps slightly humorous, and possibly dangerous inventions.

At the beginning of the first film, Marty's father George is portrayed as a stereotypical loser. He has a bad posture, a greasy haircut, and a pocket protector. At the end of the film, when Marty returns to his own time, he notices that his actions in the past have inadvertently changed his family. George is no longer the pushover he used to be. Beating Biff in the past gave him a boost in confidence which changed the course of his life permanently. He wears stylish clothing and a neat haircut. The slouch is gone.

Two images of George McFly

Left: "I'm just not very good at confrontations."
Right: "Now Biff, don't con me!"

The scene when Marty returns home and discovers the change in his family is almost purely show-don't-tell. At no point is it explained what's happened, the viewers are given more than enough clues to come to the right conclusion themselves.

The portrayal of new George wasn't completely successful, though. Outside USA George's appearance wasn't as easily recognized as the stereotype of a successful person. In mid-80s the yuppie stereotype had just reached its peak in popular culture but it was largely America-specific at that point. While the change of appearance of Marty's home and family members can't easily be misinterpreted, some nuances were lost to audiences in other cultures. Especially confusing to European viewers was why Marty's parents are carrying tennis rackets: the "rich people play tennis" stereotype is distinctly anglospheric.

This shows that stereotypes are culture-specific and that they change over time. They apply only for a relatively short period. In Back to the Future part III the 1955 version of Doc Brown chooses clothes for Marty to wear for his trip to 1885. Doc's perception of cowboy clothing seems to be colored by rodeos and early westerns, and even the 30 years older version of himself recognizes the outdated cliché.

"I dunno, are you sure this stuff is authentic?"

"I dunno, are you sure this stuff is authentic?"

Drawing conclusions from these precedences, good use for clichés and stereotypes is when you want to establish a well known archetype. It's still good to remember that stereotypes are dependent on culture and time, so their meaning might be lost on some of the audience. Bad use of stereotypes is if the reason for applying them is "for laughs" or because "that's how they all are". When they're done well, clichés can be used as a powerful authorial tool.

Where we're going we don't need roads

This is the fourth article in the Back to the Future theme week series.

Welcome to the future!

Oct 21, 2015 shown on the Back to the Future time machine's display.

In the movie Back to the Future Part II (1989) the protagonists travel to the future, to the distant date October 21, 2015. That day is today, so we'll have a look at what parser interactive fiction looks like — and could look like — in this futuristic year of 2015.

Let's start by establishing the baseline. The grand illusion is that an average parser IF story looks like this.

An abstract but complex node graph showing multiple nodes branching and convening

Not a parser story structure. [source]

This recent document from One More Story Games categorizes interactive story flows. To which category does an average parser IF story fall? It's not what the document says it is.

An average parser IF story flow looks something like this.

Contrary to the popular belief the traditional story structure of parser IF is strictly linear. The gameplay is more often than not a linear stream of puzzles leading to one conclusion. In other words, the story in each playthrough is more or less identical regardless of what actions you take during the game. You might have the choice to solve some puzzles in any order, or choose which order to talk to NPCs, or uncover pieces of the backstory at your own pace, but the number of meaningful choices is almost always effectively zero.

I know this is blasphemous, but to quote an unrelated movie: search your feelings, you know it to be true.

The illusion of free choice is created by the geography. Note that the PDF linked above has fallen into this same trap. It puts IF into a "connected map" category on page 2, but it's conflating story and world geography which are completely different things. Moving around in the game world doesn't count as a story. This bears repeating: open game world does not equal branching narrative.

That is not to say that all parser IF is linear, but there are only a handful of exceptions. It is on one hand a little bit surprising, considering the impact of Galatea (2000), and on the other not at all surprising, considering the amount of work needed to pull it off and the lack of tools designed for that specific purpose.

This is not criticism. Branching narrative is not and should not be a value by itself. But let's not fool ourselves by pretending that parser games are the shining paragon of branching narrative.

What are parser IF's strengths then? Here's a few:

  • World exploration
  • Storytelling
  • Adventure game puzzles
  • Wordplay

By adventure game puzzles I mean the standard use-thing-on-other-thing puzzles, which are pretty much fully explored by now. There might be something new to discover, but mostly everything is a variation of things already seen hundreds of times.

To me world exploration is still the main selling point of IF, and the world model is where I see biggest potential going forward.

Sandbox worlds

After that rather lengthy introduction, let's take a look at another kind of map.

Partial map of Zork I

Partial map of Zork I. [source]

This resembles the earlier storybook structure quite a lot. The difference is that it depicts a physical map of a parser game's geography instead of its story structure.

If we lay out a linear plot on top of the spatial map, it might look something like this (imaginary example):

Linear plot laid out on top of Zork's map

The red dots are story events placed on the locations where they happen. The story world exists only to support the plot, or to serve as a setting for the puzzles. And there's nothing wrong with that – story comes first. But what if we turned the setup the other way around?

Here's the story structure of AAA sandbox games like Grand Theft Auto:

Sandbox story flow.

Sandbox story flow. [source]

There's a central storyline, and side missions sprinkled around the map that are unlocked as you progress in the game. Once the side missions become available you can complete them in any order.

Parser IF already has the geography of a sandbox world, so why not take advantage of the fact? Instead of building the world to support the story, we could make the world the primary focus. Now the plot becomes a string of interconnected, self-contained "missions".

This requires some additional work, but also has a payoff. It would also require stepping away from the strict expectations of realism in IF, the same way that GTA and other sandbox games are often somewhat unrealistic: after failing a mission the game world resets and lets you retry as many times as you want, for example.

Crowdsourced content

One largely untapped potential is shared worlds. There are some shared settings like the Andromeda series, Flexible Survival and Kerkerkruip. Andromeda is a series of games written by different authors sharing the same setting. Flexible Survival and Kerkerkruip are single games written and continuously expanded by multiple people. Flexible Survival is especially an impressive result and by far the largest parser game ever made, but sadly a pornographic furry game is unlikely to ever get mainstream recognition no matter what its technical achievements are.

What I'm envisioning is a multiplayer setting like Guncho but with a common world and developer tools built into the environment. It would also help with the content creation problem.

In a shared environment the players could make content as they're playing by filling in the blanks that have not yet been completed, or creating their own spaces inside the shared world. MUDs offer this kind of functionality but they often lack the kind of direction I'm looking for: letting everyone do whatever they want will usually create a mishmash of varying quality. There would have to be some kind of editorial role that would maintain integrity and quality.

This is something that has seen some implementations (mainly on the MUD front) but they lack the final touch that would make it actually work outside niche environments.

Alternative interfaces and genre hybrids

What is the key feature of parse IF? For some it might be the parser itself, but to me it's the world model. If we left everything else as is but changed the user interface to something else, I think it could work just as well. In the current mobile-dominated landscape there's pressure to move away from typing primarily because it is a significantly inconvenient mode of interaction in touchscreen devices, and secondarily because the parser is generally considered having a steep learning curve for newcomers.

The current alternatives, mainly turning parts of story text into clickable hyperlinks, with or without context menus that appear on click (for example, clicking on the word "door" opens up a menu with verbs "open", "close", "unlock" and so on), haven't been very successful. I don't have an immediate suggestion as to what would be a working alternative, but I'm sure there's something that could be made to work. More experimentation is needed.

Taking the alternative interface idea even further, parser IF would have a lot to offer to other gaming genres. What parser IF really does well is the world model. Using an IF engine to power a non-IF game could create a spectacularly deep game worlds. Even a graphical adventure game using an IF engine under the hood could be worth trying.

Shark still looks fake

This is the third article in the Back to the Future theme week series.

A holographic shark in the future

The parser is a curious piece of technology. Since its first appearance about 40 years ago it has survived almost unchanged to this day, apart from superficial improvements.

Parsers come in two generations of sophistication. The first generation is the now practically extinct two-word parser that only understands commands in the form of VERB or VERB NOUN. The second generation is the modern parser that understands VERB NOUN PREPOSITION NOUN and VERB [NOUN PREPOSITION] TEXT where "text" is freeform input.

The third generation, which we don't yet have, is a parser that understands any reasonable input and is able to transform the player's intent into lower level tokens for the story engine. For example, a third level parser would know how to interpret the intent from OK LET'S TAKE A PEEK INSIDE THAT MAILBOX NOW and tokenize it into [LOOK IN] [MAILBOX] – all without the author having to anticipate and write grammar rules for that specific input or even those specific words.

The good news is that we probably have the technology to make a third level parser, at least to a reasonable extent. It would solve a big part of the age-old tutorial problem and remove many causes of frustrations associated with the parser. It would take a dedicated team some serious effort and university-level research but it's certainly doable.

The bad news is that there's another piece of the puzzle that needs to complement the parser or that kind of sophistication would completely go to waste. It's not enough for the story to understand input, it has to also respond to it appropriately.

Let's look at an example. In the past a relatively common complaint was that the parser didn't understand commands with adverbs, like OPEN DOOR CAREFULLY. In reality patching the parser to recognize adverbs is trivial in most modern development systems. A story that "understands" adverbs would be expected to respond to input something like this:

CLOSE DOOR

You close the door.

CLOSE DOOR QUIETLY

You close the door, careful not to make a sound.

CLOSE DOOR AGGRESSIVELY

You slam the door closed!

Where are those different responses coming from? It's not the parser that spanws them. Someone has to write the text, either as default responses to the CLOSE DOOR [ADVERB] action or as custom responses for interacting with this specific door.

Realistically you'd group adverbs together so that considering synonymous and closely related adverbs you'd have maybe 3-5 separate adverb groups. Even in the best case scenario you'd have to write up to five extra custom responses for every action to take into account all reasonable user commands.

After the author has done all that work, the end result is perhaps mildly interesting for the player to explore but has yet no real meaning within the story. It's not really worth the huge amount of extra work just to acknowledge the adverbs player has used by varying the game's responses. If you drop a glass violently instead of carefully, shouldn't it break? Shouldn't NPCs react differently if you talk to them amicably or aggressively? How should the parser respond if the command is nonsensical, like CLOSE DOOR LOVINGLY?

Any adverb-aware system that had any real effect to the gameplay would suffer from a combinatorial explosion of both all the extra responses that would need to be written and the results of actions that it would have to take into account. Making such a game wouldn't be beyond imagination but it would practically require dedicated effort from a fulltime team. Apart from trivially short works it wouldn't be feasible to a solo hobbyist.

Doc Brown wearing a "mind reading device" on his head

"Do you know what this means? It means that this damn thing doesn't work at all!"

To further illustrate why the parser and prose are inseparable, consider a story with a parser that has a human-level understanding of language but the story engine isn't sophisticated enough to deal with the input.

First a neutral command. This is what you'd generally see in any standard parser game.

TAKE ALMANAC

You reach for the almanac very carefully, holding your breath so that Mr. Strickland won't notice you...

Now imagine a more complex command:

DASH TOWARDS THE ALMANAC AND GRAB IT QUICKLY

The story's prepared response to a neutral TAKE ALMANAC command would be almost completely the opposite of what the player's intention is. If the story engine ignores everything in the command except the basic intent, the result is this:

DASH TOWARDS THE ALMANAC AND GRAB IT QUICKLY

You reach for the almanac very carefully, holding your breath so that Mr. Strickland wouldn't notice you...

The effect is jarring and because the real command is masked it looks like the parser has almost completely misunderstood the player's intent.

Another option would be to communicate the lower level command to which the parser reduces the original command.

DASH TOWARDS THE ALMANAC AND GRAB IT QUICKLY

[–> TAKE ALMANAC]
You reach for the almanac very carefully, holding your breath so that Mr. Strickland wouldn't notice you...

This would justify the disrepancy between the input and the response, but exposing the internal workings of the parser would further make the complex parser even more of a gimmick. Once the player notices the pattern there's no point to keep writing the "natural" phrases when it's obvious that they're just going to be reduced to the bare minimum. (As a teaching device it wouldn't be that bad though.)

The third option is to discard any command that conflicts with what the story is expecting, but that would not end well. It would lead to either horrible guess-the-verb-and-adverb puzzles or incredible frustration when the parser seemingly understands the basic intent but refuses to carry out the action.

The final option is to write separate responses for every type of intent, but this has the same problems as mentioned above, most notably the multiplied effort required to write the text and test all the combinations.

To sum it up: A system with a mismatch between the capabilities of the parser and the capabilities of the engine is not viable. The two are intrinsically linked. We're in a situation where improving the parser requires advancements in technology in several areas, both in understanding the input and generating the response. A smart parser is somewhat feasible, but only if the content generation problem is solved.

If all this sounds too pessimistic, fear not! Tomorrow we'll explore some untapped potential that could already be available with the tech we have now.

What if we don't succeed?

This is the second article in the Back to the Future theme week series.

One of the most useful advice that has proved its worth to me again and again, both in creative work and in business life, is "fail early, fail often." It might sound counterintuitive, but it simply means "have a lot of ideas, discard the bad ones before you've spent too much time on them." The word "failure" is used here in the most positive connotation it can have.

Not all ideas are equal. In the best case scenario you get an idea, realize immediately that it's not viable, and discard it. Even though the idea was a failure it was useful because you can now focus on better ideas. If you have 100 ideas it's best to shift through them quickly instead of finding the hard way which of them is the gold nugget.

Even if a project is based on a good idea, the details will need constant revisiting.

Doc Brown pointing at a sign in a miniature model that says "Point of no return"

Don't let a bad idea get past the point of no return.

The creators of Back to the Future had always envisioned Michael J. Fox to play the protagonist, Marty McFly. When the filming started Fox was unavailable because he was starring in a popular sitcom Family Ties. Eric Stoltz, an up-and-coming young actor, was cast instead.

A billboard crediting Stoltz as the star of Back to the Future

In an alternate timeline, Stoltz was the star of the film. (Screen capture from Fringe.)

In late 1984, after a few weeks of filming, it became clear that Stoltz wasn't right for the part. He was by all accounts a good actor but he just didn't have the personality or the comedic sense that the part required.

At this point they had basically three choices. Keep filming with Stoltz, risking an inferior end result; change the lead to someone else; or try again to get Michael J. Fox on board. Thankfully they went with the third option and managed to strike a deal with Fox and the producers of Family Ties. Fox joined the cast, Stoltz had to go, and the movie was better for it.

Changing the lead actor was a dramatic decision and it was made right before the point of no return. Recognizing the failure earlier would have saved them a lot of money and wasted effort.

Two pictures from the same scene where Marty McFly looks at his young father in the past, the first one with Eric Stolz and the second with Michael J. Fox as Marty McFly

Above: Eric Stoltz as the original Marty McFly.
Below: Michael J. Fox in the final film.

Other famous but less dramatic "failures" were the first drafts of the script where the time machine was built from a refrigerator instead of the iconic DeLorean, and the original ending in later scripts which involved getting the 1.21 gigawatts of energy to power the time machine by driving it into a nuclear explosion test.

A storyboard frame showing a nuclear test tower

A frame from an early version of the Back to the Future storyboard

The moral of the story is that it's best to fail as early as possible. It opens up a possibility for choosing something better.

The important thing to acknowledge is that you can't plan for success when you're doing experimental or creative work. Failure is always an option. The only time you can plan for success is when you're doing something that's already done and tested before, like assembling Ikea furniture or designing a game by cloning an existing one. When you're creating something new, no-one can tell if it's really going to work or not before you can see it in action.

It's also important to not take the principle too far. Some ideas need time to grow to their full potential, so discarding them would be a mistake. Balancing between being bold enough to discard probably bad ideas and holding on to potentially good ideas is the hard part.

Identifying failure points

Coming back to game design, failing early means identifying potential failure points, testing them, and making correcting moves or even discarding the project if needed.

Pretty much every aspect of game design is a potential failure point. To name just a few:

  • Game mechanics
  • Plot and story structure
  • Characters and character relations
  • Setting
  • Geography
  • User interface

The key is to think what will be this game's innovation. Tried and tested details probably won't be a problem, it's the things that are going for something new that are most likely to require repeated iterations.

Once a potential failure point is identified, the best way to find actual problems is prototyping. Make a small example that shows the thing in action; implement the game's core mechanism, at least partly; start writing from the climax of the story instead of from the beginning; write the key interaction between main characters first. Once you have something concrete, no matter how small, you can more easily get a sense of whether it will work or not.

Biff, what a character

This is the first article in the Back to the Future theme week series. Contains spoilers for the Back to the Future and The Godfather films.

The three things that matter most in a story are characters, characters, and characters.

— Bob Gale

Character arc is a narrative technique that, in a nutshell, means that a character figuratively transforms from one person to another during and due to the events of the story. The character might experience a change in personality or opinions, learn a lesson, or otherwise come out as a different person.

Here are some famous examples:

  • Ebenezer Scrooge in A Christmas Carol. Scrooge's extreme transformation from a bitter old man to a philantropist is one of the purest forms of character arc.
  • George Bailey in It's a Wonderful Life. Christmas is a well-suited theme for character growth stories.
  • D'Artagnan in The Three Musketeers. D'Artagnan is a hot-headed peasant who becomes a heroic musketeer.
  • Luke Skywalker in the Star Wars movies. Many of the Star Wars characters have their own character arcs.
  • Michael Corleone in The Godfather. Michael starts out as wanting to have nothing to do with his father's crime syndicate but eventually rises to take his father's place. This is an example of a character arc that results in negative change.

So how to include character arcs in interactive stories? Here are a couple of options.

Option zero: No character arc

A valid, and very common, option is to disregard any character growth entirely. Not every story needs it, especially in a game where the main focus might be in gameplay, exploration, puzzles or something else other than the characters.

The use of this option should be carefully considered, though; although no writing rule should be followed blindly, the character arc is almost universally regarded as a fundamental building block of a good story. Change is part of a character's metaphorical journey, and if the journey didn't have any impact on the characters then it could be argued that the events they experienced weren't really that meaningful.

Option one: Player character arc

Back to the Future didn't start out as a trilogy. When the first film became a huge success, the creators started working on sequels.

While the protagonist, Marty McFly, had driven the first movie's story forward, the film was never about him. The main character was his father, and that's where the character growth takes place: George McFly transforms from a submissive loser into a self-confident, successful author.

Screenshot from Back to the Future II with Marty and Biff

"Are you chicken?"

The filmmakers realized that while it was ok to have the protagonist not experience any real growth during one film, it wouldn't work for an entire trilogy. So they gave Marty a character flaw: he would lose his temper every time someone called him a coward (or, more specifically, a "chicken.") Now he had a negative trait that he could grow out of and thus demonstrate that the journey had affected him.

I'm the first to admit that the whole chicken business feels artificial, especially since there's no sign of it in the first movie, but it does show how important aspect characters and character growth was to the movie's creators.

Player character growth can be much less effective when the player's experience of the story doesn't match the protagonist's experience. As an example, let's assume that the protagonist starts out as resenting one of the NPCs but grows to respect them during the story. If the player hasn't experienced the same kind of change in their attitude towards this NPC, it's a mismatch that can make the story feel unrealistic. There must be a clear reason that has caused the change in the protagonist.

Option two: Non-player character arc

Marty didn't get much more agency in the sequels either. In the second film the focus is on Biff who becomes a powerful and corrupt businessman, and the third is about Doc Brown who builds a new life in the Wild West and finds love.

Marty is someone who mainly goes along with the things happening around him. He is almost purely a reactive character. In many ways this is very similar to the typical game protagonist. The player character is often an empty shell where the players are supposed to project themselves. The player very rarely has any real agency: the plot happens, and the player reacts to it in ways that trigger the next events.

When the game has no strong opinion on the player character, character growth can be delegated to NPCs. They are also less susceptible to the problems associated with how the player experiences the story, because the player is less likely to identify with the NPCs as strongly as they might with the protagonist. Again, there must still be a clear reason why character growth has taken place: an NPC can't just suddenly reappear with a completely new personality or opinions.

Option three: Choose Your Own Growth

Interactive media gives us yet another option: the author can let the player decide what kind of character arc the protagonist experiences. A good example of this is Slouching Towards Bedlam where the player's actions have long-reaching consequences in the protagonist's fate.

Providing several options for the player is of course a lot more work than making a single predetermined path. It needs more effort than just slapping on a final choice at the end. If we think of the character arc as a literal journey it should be clear that the same path can't lead to two different destinations.

In the best case when the story provides enough room for the player to move it doesn't necessarily even need to conclude the character arc explicitly. The player creates and experiences the character's journey, filling in the blanks. When the character arc is being built organically during the entire story, any possible last choice at the conclusion should feel like a natural choice to the player instead of just a bundle of alternate endings.

A big pitfall to avoid is the "kiss the baby / eat the baby" choices, i.e. moral choices that make you choose between an obviously good deed and an obviously evil deed. They have been widely criticized and ridiculed, mainly in AAA games, because they are ultimately meaningless: you could just as well ask at the beginning if the player wants to play a good or a bad character and be done with it. The impact is far bigger if the choices the player makes are subtle rather than obvious.

For more practical guidance on writing character arcs, K.M. Weiland's How to Write Character Arcs is an extensive online resource.

Being brutally honest

I was writing a comment to The Many Authors of IFComp over at Sibyl Moon Games, but it became so long and slightly tangential that it's better to post a proper article instead.

Historically there have been several parser IF writing communities with partially overlapping members. The "main" community, originating from rec.arts.int-fiction newsgroups before largely migrating to the intfiction.org web forum, makes up for the bulk of the high-profile activity and covers the most diverse collection of authoring tools. Smaller communities are usually focused around individual authoring systems (ADRIFT, Quest).

The approach these communities take to providing feedback to authors varies greatly. The main community used to be on the far end of the scale: "brutally honest" would probably describe it best. The community expects and rewards quality, and things that don't work are meticulously brought out in reviews.

On the other side of the scale there are communities that reward effort. No matter how bad the game is, you get cheers and pats on the back just for releasing it. Feedback, if any, is overwhelmingly positive. The community doesn't necessarily even expect that published games would be open for criticism.

The games produced by these two extremes are also very different. Communities that only reward effort produce a lot of games that are almost without exception, to be brutally honest, utter crap. This is because of two main reasons: Firstly, there is no incentive to spend time designing, polishing and testing your game because you'll still get the same reward in positive responses no matter what the quality of the result is. Secondly there is no peer pressure: when no-one expects high-quality games, there's no outside push to aim there.

The brutally honest camp produces less games but they're generally of better quality. There's a sieve that the authors are pushed through: all work undergoes close scrutiny. Authors who can't handle the criticism will drop out, but those who stay are less likely to repeat their mistakes and more likely learn from the feedback and keep improving. The peer expectation of game quality is generally high and the authors aim higher in the first place.

The downside of unchecked criticism is that, from the point of view of an individual author, the feedback can feel unnecessarily harsh. A novice author can easily give up if the feedback is crushing, which is understandable; when you do things as a hobby, you want to have a positive experience or you go do something else.

The challenge is to combine the better parts of the two extremes. How to not punish anyone for producing creative work but at the same time encourage high quality?

The trend is already moving in this direction: some reviewers (including me) post only reviews that are net positive and events like Spring Thing have non-judged categories. This is only a partial solution. Lack of feedback shields authors from negative feedback but also leaves them without means to improve.

It would be great to have some kind of mentoring system where experienced authors could help out newcomers to design and polish their games. The downside is that it's not mass-reproducible: it would require a lot of effort from the mentors and the ratio of newcomers to experts is too high for everyone to get a mentor.