Making Interactive Fiction: Narrative Design for Writers (Part 2)

This is part two of a two-part series about narrative design aimed at traditional-media writers and IF authors.

In part one, I walked through a series of questions that help clarify a narrative design. Now, I’m going to talk about how one puts all of this together.

The output of narrative design as a process is a design document — in games, it’s common to produce a GDD (game design document) outlining an entire game, but I like writing smaller and shorter treatments of individual systems, mechanics, or simply of a game’s narrative structure apart from any mechanic. In interactive fiction, especially short or experimental fiction, GDDs are rarely written. But I find a narrative design document, marrying major plot events to chunks of content and spelling out how they’re structured and accessed, to be more useful than a screenplay-style story outline.

In fact, flat story outlines are often hard to read or misleading when it comes to interactive narrative. I tend to draw diagrams; some of my work is “documented” in photos of whiteboard sketches or cramped up in notebook pages. Spelling out how things are supposed to work is great for finding holes in your own logic or seeing combinations of actions players could take that you didn’t anticipate. Prototyping the main narrative branching points as a simple Twine is a popular approach when dealing with that kind of structure; it lets you both see the shape of the narrative, and play through it to explore individual versions of the plot.

At this point, you can start asking some more systematic questions about the story: Does a typical playthrough get across everything I want to say? Does every playthrough? What are the things players will always see? What are the things that only a small fraction of players will see? If players can fail, where and how can they fail? If players are managing some kind of resource, what does that resource economy look like?

Those questions will lead you towards iterating on your design, and they’ll help clarify a lot of underlying issues that we often don’t think about until it’s a little too late. A game where players can miss large segments of story, and therefore get a version of the story that heavily elides important events or backstory, is very different from a game trying to make sure players get a chance to see everything important. Seeing what your structure does will help you figure out what you want it to do, give yourself an aim to steer by.

I know this seems like a lot of prepwork before you begin writing (though nothing says you can’t sketch out scenes, moments, or snippets of story before thinking through structural stuff — I often do that, too; it’s useful for figuring out what the story really is). But the idea here is to get you off the autopilot that tools (whether Twine or something else) tend to induce and get you thinking about how to construct a story as a sort of machine of meaning that players will engage with.

Bruno Dias is a writer and narrative designer based in São Paulo. His work has appeared in video game publications (Waypoint, PC Gamer), games (Where the Water Tastes Like Wine) and interactive fiction on Sub-Q and elsewhere