A 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.
There’s a similar simplicity or conservatism to a good deal of the craft advice: or rather, perhaps more fairly, the book presents a lot of conventions as straightforward absolutes. For instance:
When you construct a Twine story, you write it in second person so that the player becomes the main character in your story. (3)
Or this, which in a sentence sweeps away the whole tradition of Twine games about disempowerment:
If you create lots of agency for your players, they’ll feel like active, important figures in your story, and that’s the point of writing interactive fiction in the first place. (14)
(Emphasis mine.)
Occasionally the instructions include the kinds of admonitions we generally only make to children:
How different were your endings? Where there four very different outcomes based on the actions of the main character? Think about your own life and how there are natural consequences for your choices. (19)
When I got to this page I got lost in a brief reverie about the way cause and effect in real life tend to be random and unfair. I thought about how much of the good in my life has come about through luck; also, about this man I know who has lost not one but two wives to cancer, and how that brutal circumstance was a consequence of nothing that he chose other than loving and committing himself to them in the first place. Then I remembered that that probably wasn’t what the book was getting at.
Every smart writer starts with an outline. (23)
Well, except when they don’t. “Some kind of planning is a good idea” makes for looser and less immediately applicable advice, though.
The section on genre is similarly prescriptive, many sentences starting with things like “The goal of an adventure writer is…”, and offering prompts like this:
Words that will help set the tone in an adventure story: muddy, khaki, ravishing, plummet, shining, jewel, forest, scaling, racing, and leaping. (119)
This is not a kind of advice I’m used to seeing even in fairly introductory-level writing craft books; it’s a lot more common in rulesets for tabletop roleplaying games. Monsterhearts character skins, for instance, invite a prospective player to circle an attribute for their protagonist out of a trope list like this one for the Ghost: “Forlorn, meek, distant, stuffy, out of place, brooding.” It’s really useful in RPGs where you want to keep all the players on more or less the same kind of story tack, and also in writing workshops where you want to prod people into producing things quickly in an hour or two. As the basis of a deep understanding of any particular genre history, it’s very limited. But that’s just not the goal of this book.
Meanwhile, Writing Interactive Fiction with Twine does provide a route into some of the more technically sophisticated aspects of Twine — specifically, of the Twine 2 Harlowe format — that are currently not especially easy to learn from the documentation at twinery.org. Ford’s gentle lead-in, numerous examples, and exercises do a lot to explain how you might do programming-like things under a Twine surface, and why you might want to. You’ll find discussions of how to manipulate variables, simulate inventory, calculate and make use of total turn count, and much else.
Likewise, the book combines technical and writing instruction in a really thoughtful way. Most chapters introduce a few pieces of Twine syntax in the context of particular examples, and combines those examples with broader observations about good interactive storytelling. The “either” and “random” macros are introduced alongside a discussion about player expectations and plot predictability. “prepend” comes in the chapter on foreshadowing. Various more and less obvious text-addition macros appear in a chapter about character depth, along with more narrative considerations about conveying interiority. Arrays — and this is admittedly something of a reach — appear alongside the concept of metaphor, as ways of packing considerable information into a small space.
And as to that explanation of arrays, it’s again extremely gentle, assuming no programming knowledge from the reader and offering analogies and illustrations to clarify what an array is for. Having a diagram to help me picture an array as a shopping bag with slots for different items feels like overkill to me in adulthood, but I remember that when I was trying to learn to code as a kid, I found arrays the most bewildering thing in my programming books: they seemed so fiddly, and what were they for anyway? I half wish I could go back to my much younger self and offer her this explanation and these tools. I spent a good decade and more frustrated by technical limitations before I was finally able to write my first IF.
So overall, I’d say there’s a definite rhetoric to this book, and it runs counter to a lot of what has been written about Twine before. Rise of the Videogame Zinesters talks about Twine’s accessibility, the ease of writing immediately, and the critical importance of that tool to give voice to the voiceless. Writing Interactive Fiction with Twine instead positions Twine as technically sophisticated enough to express many of the same things that are valued in the parser tradition. And I thought it did a good job of that: certainly I found it the clearest explanation I’ve yet read for the coding aspects of Harlowe and SugarCube. Given that Twine documentation and code samples are notoriously scattered all over many different sites and forums, it’s really valuable to have these materials in one place, organized in a logical progression, with plenty of examples. I can definitely foresee coming back to this book as a useful reference for any future Twine projects: I might not need the picture of what arrays mean, but I welcome the tidy presentation of related macro concepts.
Second, the book knits together mechanic and fiction, presenting the technical craft of IF implementation in clear relation to the technical craft of storytelling. It may be doing both at a fairly introductory level, but that doesn’t diminish the importance of that rhetorical move. Lots of previous writing about IF craft assumes either that you have already digested a lot of writing instruction and don’t need to be told, or else that you don’t at all care about conventional fiction writing (though it’s worth looking at Aaron Reed’s Creating Interactive Fiction with Inform 7). The book is less into game design per se — it tends to treat the concepts of puzzles and plot progression as already settled things, inviting the reader to pick some pre-established puzzle types and deploy them, rather than to think afresh about what interaction could involve.
Finally, Ford’s book offers loads of exercises one could imagine using in workshops or with younger users. I think it may offer a route in to classroom teaching of Twine in particular, and I recognize that some of the book’s glaring omissions about Twine’s cultural history may have been made in order to keep it palatable to the PTA.
Above all, it feels safe: concepts have tidy subcategories; advice is clear, generalized, and prescriptive; characterization starts with a discussion of Big Five personality factors; the most conventional formats of branching narrative are placed alongside the most conventional of writing advice. (There’s a full chapter on Show, Don’t Tell.) Depending on who you are, that could be a really good thing. The book is thorough and careful and well-organized, which are serious virtues in this context. It’s doing something useful, that isn’t being done in any of the other books on Twine, and the more I read, the more I was convinced that the simplicity of its explanations reflected expectations about the audience, rather than limitations of the author. The final chapters do suggest that the rules laid out earlier can be broken by someone who knows what they’re doing.
At the same time. At the same time. I’m glad this exists — I will use it, and I believe so will others. At the same time it makes me a little sad. Here is a book about Twine in which gender is mentioned for a third of a page at the back of the book; a book about Twine that includes the sentence “Most of the time you’ll be able to straddle both genders with your player character as long as you’re careful about not making gender-based assumptions.” Indeed. It’s the most usable explanation of Twine I’ve read, and also the least touched by the evangelical spirit, by the sense of holy fire.
(Disclaimer: I read a copy of this book I was sent for free by the publisher for review purposes.)
Emily Short's Interactive Storytelling 
Does a book on how to use a hammer to do home repairs have an obligation to talk about Third World sustainable housing and Habitat for Humanity? Personally I think it can be overly constraining to lean too heavily on historical examples and cultural context when teaching the mechanics of a free, open-source tool like Twine, Inform 7, or any other computer language, particularly when several high-grade books already do this for those that are interested.
The documentation for Inform 7, for example, talks about IF and the “parser tradition”, such as it is, barely at all and mostly in very general terms, focusing strongly on implementation mechanics and achieving world-model effects. There’s little “holy fire” in, for example…
“Interactive fiction is a literary form which involves programming a computer so that it presents a reader with a text which can be explored.”
…and I don’t think the documentation is any the worse (in my opinion, it’s actually better) for its lack.
Providing context- and assumption-free information on mechanics and implementation allows new creators to pick up the tool and use it to realize their own personal vision rather than feeling constrained to conform to the existing culture that has grown up around it. It wouldn’t surprise me if this book _increases_ the diversity of Twine works rather than somehow diminishing it.
It wouldn’t surprise me if this book _increases_ the diversity of Twine works rather than somehow diminishing it.
I think that part’s true: that there are people who will find this an entree to the system who would not have been interested in the significant traditions of Twine work about mental illness or queer experiences. I also had the strong impression that that was part of why it’s written the way that it is. As I said in the review, there’s absolutely a place for this book.
And no, the Inform manual isn’t especially evangelical, except in the sense that I was trying to make the examples hint at future possibilities beyond the current parser space. But — well, two things.
1) Inform’s popularity didn’t come about as an underground movement driven by the work of marginalized people. The Twine revolution did.
While I don’t think a Twine manual necessarily needs to start with a massive history of the field, I often felt that it probably *was* omitting pertinent examples of Twine work because those examples were deemed inappropriate or too political for its audience. Yes, there probably are people who will be more comfortable learning to use Twine if they’re not told that some of the most powerful and enduring works in Twine are the expressions of trans femininity. And yes, it may be that providing a school-palatable text on Twine will introduce many new students to the material who might later go on to find that the Twineverse contains many eye-opening things.
But skipping over that kind of information for the ease of the majority is part of a long, long tradition of erasure. I didn’t slam the book for doing it, but I couldn’t not say something about it, either.
2) I also think it’s a bit striking that this book starts out by telling you how to do things that are done in maybe 10% (if that) of current Twine games but that *are* dominant features of parser fiction, and that it puts off the stuff like text animation and font coloring that turn up in quite a lot of the Twine games that already exist. The Inform manual does indeed present features that go beyond what the typical parser game needs, but it pretty much starts out by trying to explain how you’d do the kind of thing you might have seen elsewhere in other parser games.
This book pretty much a) assumes you haven’t seen a Twine game before, so you’re not going to be looking to emulate effects you’re familiar with previously; and b) establishes a baseline that does not correspond with the extant population of games.
Which again, I don’t think is necessarily bad! Personally, I really appreciated hearing more about how to handle data structures in Twine, and what was in those chapters spoke to the kinds of things I might want to implement in Twine but have held off attempting.
But doing that is absolutely a rhetorical move in the ongoing discussions about IF systems and what IF can be. It’s not somehow value-neutral; it’s not “context- and assumption-free information on mechanics and implementation.” There are assumptions. They’re just assumptions that are closer to mainstream cultural norms and parser community norms than in almost anything else written about Twine so far.
I get where you’re coming from, and you are obviously more familiar with this work than I am. I get the impression, though, that you are saying that a book about Twine necessarily _must_ be participating in an ongoing discussion about [the politics of] IF systems and what IF can be.
I certainly don’t think it has to be, but that may be an outgrowth of the fact that I got into IF via the programming route. In a programming language context, talking at length about the contributions of the luminaries of the C++ world or the cultural (or even business) significance of various major C++ applications is not necessary or even desirable in a book teaching the philosophy and mechanics of using the C++ language. C++ is a tool — with strengths and weaknesses and an interesting history to be sure — but I can pick that tool out and use it effectively and successfully without learning about or even caring about anything other than its applicability to my problem at hand. I don’t need to know, for example, that the recommended Javascript brace style has its stylistic roots in Kernighan and Ritchie’s original implementation of C.
I do love reading about the history of programming languages as well, and even learning about the particular academic/business/hipster communities that have adopted various languages for various reasons. When I want to learn how to write a variadic template, though, I’m looking for as close to pure instruction as I can get.
I could see the claim of erasure being valid if the author was trying to promote some alternative explanation for the rise of Twine or to retell the history of Twine while eliding the massive contributions by marginalized creators. You would know better than me if this is what the book is doing. From your description, however, it doesn’t sound like it’s talking about that aspect of the Twine _scene_ at all. In that sense, it sounds like the author is just limiting the scope of the book to construction and implementation of works using a popular authoring tool, which seems nonproblematic to me.
Yeah, I mean, I don’t mean this as a slam against the book! Like I said, I think it’s useful, I think it shows good craftsmanship and I think it reaches out to users who are not currently well served by the set of work available, including me. (In my case, it’s not that I *couldn’t* learn to use Harlowe before; it’s just that the amount of time required to ferret out the information I wanted, relative to how long it would take me to do the same thing in a programming language I already know, often discouraged me from sticking around long enough. I think this might tip the balance for certain projects in favor of Twine.)
And I wouldn’t say that the book is saying *false* things about the Twine scene, or claims an alternate history for it. But I also wouldn’t blame a reader for coming away with the impression that there was Infocom, and then there was amateur parser IF, and then Chris Klimas showed up, and then there were a bunch of Twine games mostly like Hallowmoor, with a very parsery model. This is not true. It’s untrue in a way that is really really important to certain people. Do all the readers of this book absolutely need to know that? Maybe not. Do readers of my review deserve to know it? I think they do.
Then, specifically re “C++ is a tool — with strengths and weaknesses and an interesting history to be sure — but I can pick that tool out and use it effectively and successfully without learning about or even caring about anything other than its applicability to my problem at hand.” — I do understand what you mean. But if you learn C++ from a book, and the book teaches you all the syntax you need but almost all of the example applications of that syntax have to do with graphics rendering, and it also has a bunch of advice about good graphics practice, then you’re probably going to come away with a pretty specific notion of what C++ is for and what you might imagine doing with it in the future.
To be clear, I think Twine currently has a founder effect going on, which results in people tending to use Twine to make games about personal experiences even though nothing about the tool requires you to use it for that. So it’s interesting to point out what else Twine is capable of, just as when I wrote the Inform examples I tried to throw in a bunch that did NOT assume you were writing a fantasy quest set in a cave. But I felt it was specifically notable that this book replaced the Twine founder effect with a *different* founder effect, one based in the parser IF tradition.
And as to “must be participating in an ongoing discussion” — well, yeah, kind of. The community of authors just is not *that* huge. If you publish a major book in the vicinity, and this is one, then it’s likely to affect who else joins the community, what they think they’re doing there, and so on. I’m not saying the effects are going to be bad; I was just trying to describe what I see here.
As to “this makes me sad”: that’s an emotional and personal response, not a “this book sucks”; I hope I made it clear I think it does not suck. But: here is a tool that has had a huge, transformative effect on the lives of people I know. For some it was nothing less than revolutionary. Of course, the sequel to revolution is that the new leadership now has to settle in to handle the humdrum and the pragmatic, and that doesn’t always turn out to be as glorious or as straightforward as they might have hoped. (“What comes next? / You’ve been freed: / do you know how hard it is to lead?”) I’m wildly overstraining this analogy, but that has happened in various ways with Twine, and one of the several ways it’s happened is that Twine is being integrated into the mainstream in this way.
That opening sentence is so painful. Habitat for Humanity is an amazing, valuable organization that obviously had no influence whatsoever in the adoption of the hammer as a common tool.
Yes, that was a strained, bad analogy. My ending sentence wasn’t much better, refuting a claim that hadn’t actually been made.
The provided examples of black-and-white prescriptive advice don’t seem “assumption-free” at all to me.
Don’t seem able to respond to your latest, so apologies for the jump…
Thanks for your responses, Emily! (And your original review, for that matter).
I’m still not convinced that every work covering how to use a tool or language is morally obligated to engage with the surrounding political / community issues, but you make some good points here that I respect.
I don’t know what to feel.
I’m queer, mentally ill, and dirt poor, and “both genders” doesn’t particularly include me. And I felt actively alienated by the “Twine Revolution” while it was happening.
I have nothing against the sort of content that the community tended to create – most of it wasn’t my thing, but I’m a big kid and can use my scroll wheel. Linear click-through stories, confessional writing, and certain types of sexual writing don’t particularly appeal to me, but I recognize that they’re not WORSE than the things I do enjoy, and that they have the right to exist and be shared and cherished in a community that values them. But there were definitely a lot of assumptions going around about what sort of tastes were revolutionary and what sort of tastes were establishment, and what sort of people had establishment tastes. If you weren’t the right sort of queer, you might as well have been a vaguely homophobic straight guy (see: how the way Encyclopedia Fuckme was described by its author http://auntiepixelante.com/?p=1271). And there was VERY little effort to recognize that community members had different needs around certain types of content – for example, it’s definitely important for people to be free to create sexual art that reflects their personal way of experiencing sexuality, but there was zero recognition that the community would probably include survivors of sexual trauma who wouldn’t appreciate the surprise sexualized disempowerment, violation, and defeat common to a lot of games that sought to deconstruct power fantasies.
So while works like this definitely don’t speak for me, it’s kind of refreshing that they’re not even claiming to.
Yeah, even currently there’s a lot of assumptions floating around about exactly how “the community” is parceled out, and “take control away from the player!” is so often bandied about surface-level discussions as a universally revolutionary idea, as an unquestionable sign of artistic progress (and progressiveness).
I know the feeling of “this isn’t representative” vs. “this is being hailed as representative AND IT ISN’T” (it feels cousin to the media-thing of erasure vs. lazily/harmfully stereotyped representation), though all of it just makes me tired rather than any part of it being refreshing!
Yep. I’m gay (not queer, thanks) and autistic and those technically limited “identity sob stories” do nothing for me. That’s not to say there’s no value in them for those who do enjoy them them, but Twine is capable of so much more than that, and this subculture that claims ownership of the platform can be very offputting to people who don’t want to be part of it.
It’s incredibly condescending to me, this idea that all I could possibly care about from fiction is representation of people just like me and that my life experiences can be reduced to victimhood.
I picked up a copy of this book and have been working my way through it to learn TWINE for my thesis project. Very nice review to stumble upon. It’s a very gentle introduction to IF through TWINE.
This is the only real accessible technical guide to Twine there is, and for that reason it’s essential, even if the creative writing advice is somewhat lacking in comparison. Porpentine and company (and their somewhat niche works) are only one particular subculture who became known for using the program, they aren’t synonymous with it and they don’t own it, so an introductory technical book like this is under no obligation to mention them.