HM is on sabbatical for June and guest writers are filling in for him. This week it’s the turn of Dan Cox, who has previously written for Nightmare Mode and been a strong supporter of Twine. He has authored both a Gamasutra series on Learning Twine and a video tutorial series. He has also figured out how to use Google Drive to host Twine, explained how Twine authors could distribute and sell their work through and, most recently, been working on getting Twine to work on Ouya.


In many ways, I’ve come to think of Twine as a religion of sorts as I’ve watched the tool and its greater community grow these last two years. It has its followers, rituals, and customs. It has its saints and celebrities. There are numerous sites and people dedicated to promoting it and, of course, it definitely has its detractors. Yet, if I view my own relationship with Twine in this light, I think I might now describe myself as having lost my faith.

I am no longer comfortable with some of the community practices. I feel that Twine’s two core promises, that it doesn’t require programming and is for everyone, have changed. What I once promoted as tenets of the Twine “faith” I no longer believe or celebrate. I’ve increasingly become worried that the Twine community might be headed in the wrong direction.  

For a long time, I was comfortable with the lie that Twine doesn’t require programming to make something. I knew it wasn’t really the truth, but it was easier to explain. That Twine uses the TiddlyWiki syntax and that, to make even the simplest story, from Start to another passage, required an understanding of how links work and using brackets to create them was glossed over quickly by many people. Unless I was personally working on a guide to Twine, I wouldn’t even mention TiddlyWiki at all, in fact.

That Twine is based in a markup language, a programming language, itself has become somewhat taboo to mention. What I noticed at first as a general distrust of people who could write code in late 2012 has become openly hostile in some circles in 2014. The echoed refrain that Twine does not require programming of any sort as the number of macros increase exponentially is, I’ve decided, at best paradoxical and, at worst, largely hypocritical. This is an especially ugly truth in light of the celebrated works of leading Twine authors mutating how Twine internally works and including hundreds if not thousands of lines of code themselves.

Let’s stop this. Instead of denying this aspect of Twine, especially as 1.4 now includes whole JavaScript frameworks like jQuery, the community should embrace this change. Stop pushing away programmers with one hand while requesting they make macros with the other. Twine has never been free of code and never will be.

Using Twine has always required some mastery of a certain amount of programming. Setting aside writing macros themselves for a moment, just navigating the many options of the built-in Twine macros demands an understanding of at least what they expect in terms of parameters. To use the <<display>> macro, you must know that it requires the name of another passage. The same with variables for <<set>> and, of course, the use of <<if>>, <<else>>, and <<endif>>. They all ask for some knowledge of how programming works to understand their combined usage.

Yet, there remains this dissonance between this promise of Twine and its reality. A dissonance that often reaches a cacophony for me when it comes to macros and the use of JavaScript.

I have never really understood the logic of using multiple JavaScript macros and claiming that a project did not use programming. I have seen way too many praise Twine one day for being a creator’s paradise free of code and doom it the next to the deepest parts of Hell while battling with conditional statements.

There have even been many days in my last year or so with Twine when, yes, I have regretted spending so much time writing posts emphasizing how to create and combine macros. I’ve changed since those early, passionate days. I don’t recommend my own macros for loading external JavaScript files any more and generally recommend people completely avoid doing that. My stance has switched pretty strongly from wanting to include all manner of outside JavaScript and web technologies, to actively telling people, should they ask me, to avoid many things completely and to aim much more at inclusion than reaching for the latest shiny at the risk of excluding many people. For as much as you can, I’ve told people privately in e-mails and messages, create in Twine for as many people as possible.

Because, of course, that’s the other promise of Twine: it’s for everyone.


Often, I’ve seen and heard this particular promise comes up in discussion of privilege. In conversations about who, why and how people get to create. On more than a few occasions, I have witnessed Twine solely positioned as the answer to libraries, engines, and other game-related middleware as labelled by and for “white dudes.” That somehow, all other game and project software is made by this singular lump of people and that they exclude all others from joining, learning about, or even taking part in their communities. It’s just for them.

While this isn’t always strictly true, of course, the sheer weight of harm privileged, white males have done and continue to do other groups is staggering. It is unfathomable in its monstrosity and scale. In programming communities specifically, it can often be the worst when entrenched ideologies collide with everyday reality. When those who write and follow very strict rules come into contact with new, challenging, and diverse ideas, the outcomes can sometimes be very ugly for everyone involved.

It should come as no surprise, then, that Twine, having been welcomed by often marginalized voices in the greater game development community, is sometimes wielded as a rhetorical weapon in defence of their right to create. Some authors even go so far as to reject other groups using Twine at all and claim ownership over it. Seeing it as one of the few sanctuaries for expressing their too often marginalized voices, they push back against intrusions from the outside and can sometimes pressure an insider mentality to protect their hard-won and often-attacked space.

Unfortunately, as someone who has used Twine to teach and continues to promote it as a tool for classrooms despite his own frequent lack of faith, this means these issues comes up faster than they would for other tools, engines, or software libraries. The reality for most people using Twine is that there is often a very real cultural war being fought over who gets to create and how they label their creations. Many of the frontline battles for power to dictate and manipulate definitions have been, are currently, and probably will continue to be fought, discussed, and argued around Twine in the coming years.

As a sometimes teacher, this prolonged conflict leaves me with a bad taste in my mouth. I can try to equip my students for these battles. We can discuss the issues. I can even tell them about my own “holy wars” with Twine and relate what to expect should they engage with their own enemies. But it will be a battle for them. And in all likelihood, they will be forced into picking a side and then defending it.

I still promote Twine. I still like Twine. But I just don’t believe anymore.

Related: On Writing Twine

Download my FREE eBook on the collapse of indie game prices an accessible and comprehensive explanation of what has happened to the market.

Sign up for the monthly Electron Dance Newsletter and follow on Twitter!

38 thoughts on “Faltering Faith in Twine’s Teaching

  1. I think all this stems from the fact that most people aren’t afraid of programming — they’re afraid of writing code. Give them something that doesn’t look like programming at first sight, such as Inform 7, and they’ll happily embrace it. By the time they realize it’s still programming, they’re hooked.

    That, you see, is why people keep making tools for “making software without writing code”. Which, of course, still end up being used by programmers, because dragging and dropping colored boxes and filling in dialogs is still programming, and some people just can’t wrap their heads around that. But it’s the “writing code” part they blame instead.

  2. Thought-provoking — I think I will try to write a longer response later, but in the meantime — would you consider something like Markdown to be a programming language? I would not, but I certainly am biased.

  3. I like Felix’s distinction between ‘writing code’ and ‘programming’.

    You absolutely have to do ‘programming’ if you’re going to create anything interesting.

    Even paper gamebooks have this, with state variables (‘You are now carrying the trouser press’), and if statements (‘If you are carrying the trouser press, turn to xxx’) and they’re nowhere near a computer. The most you can manage if you can’t change the programming is a reskin, which can be fun but will be very limited in what you can say.

    ‘Writing code’ however is far more intimidating. This is the part that you don’t have to tackle in gamebooks, because readers are going to know what you mean even if you misplace a capital letter. ‘Writing code’ involves expressing stuff in a formal language so an idiot machine can understand it, with irritatingly strict limits on how you say things. This looks like natural language, but they are completely different at any level other than the superficial.

    Formal languages are very easy to get wrong in ways that are not easy to diagnose. It’s just Syntax Error after Syntax Error. ‘hello’ is not the same as ‘Hello’ or ‘HELLO’, except when it is, and parsers rarely give useful errors like ‘that variable name is the wrong case’.

    The case of Markdown is the worst of both worlds – You can’t program in it, but it’s still a formal language that needs you to ‘write code’.

    Twine suffers from this same problem from the outset.

    Just a quick look at Anna Anthropy’s (excellent, but it illustrates my point) introductory tutorial ( shows how much you have to get into the ‘writing code’ mindset:

    ‘The first passage in your story is called “Start.” Don’t change this name! Other passages can be named whatever you like, but the title of the first passage HAS TO BE “Start,” capital S, lowercase tart.’

    Formal language – Passage name has special meaning, Identifiers are case sensitive.

    ‘The text to the left of the | bar (same key as the backslash, which on my keyboard is between BACKSPACE and ENTER) is what the player sees. The text to the right of the bar is the name of the passage she goes to when she clicks on it. Remember: it has to be double brackets!’

    Formal language – Links have a special double-bracket syntax, and a special character to differentiate between appearance and meaning.

    ‘If you gave it the same passage name you wrote in the link, there’ll be an arrow pointing from the first passage to the second passage. ‘

    Formal Language – Get the passage names to match up EXACTLY.

    ‘It says “Untitled Story.” You can change that. Create a passage named “StoryTitle.” What you write in that box will be the game’s title. Create a passage named “StoryAuthor” and you can write your name: the HTML file will say “StoryTitle by StoryAuthor.”‘

    Formal Language – Special passage names again, with particular meanings. Again, better get the capitalisation right.

    It goes on and on, using different operators (‘eq’ vs ‘=’) for assignment and comparison, something BASIC managed to avoid in the 1970s. And the brackets! Square, pointy, curly, then double them! All the brackets! Everywhere!

    You need a formal language to communicate with a computer, but it seriously doesn’t have to be as bad as Twine’s. I’ve been writing code for thirty years, and white, and male and even I find it obtuse. And just when it looks like it couldn’t be any worse it drags Javascript in too.

    For a tool that’s supposed to not need programming, there’s an awful lot of writing difficult code using a formal language that you’d have trouble making any more twisted.

    Sorry, went on a bit there. Like I say, nice insight. I shall think more.

  4. Quick version: If you set out to design an accessible hypertext story making tool, Twine would be a great example of what not to do.

  5. Twine isn’t for the dead either, but as long as it continues to be the most accessible thing I know to do what it does, I won’t really have a problem with the “for everyone” label.

    The distinction between “coding” and “programming” doesn’t ring meaningful in this context. The people who can get intimidated by telling computers what to do are the people who will most likely consider “writing code” and “programming” to be synonymous.

    Mandatory personal note (because in the end this is Twine we’re talking about): the skill I struggle the most with when making games (or whatevs) for people to enjoy is writing in English. I could point out the grammatical dependencies and the weird written vs. spoken discrepancies and the had-hads and I’d end up concluding English is programming.

    The point is not, I think, that Twine doesn’t require programming. It’s that most people on the web can pick it up and make things with it without realizing they’re programming. That’s what “no programming” is meant to stand for: of course you’ll be coding, dummy, but it won’t feel like it (at first).

  6. CdrJameson, most of your top-level criticisms are being addressed in Twine 2. In fact I did use Anna’s tutorial as a blueprint for what was wrong with the UI — in short, the issue was ‘magic’ passages and tags. Now, instead of a Start passage, you choose which one to start with from a drop-down menu. Instead of StoryTitle, there’s a text field in the editor. Instead of tagging passages ‘script’ or ‘stylesheet’, there are dedicated areas for editing custom JS and CSS in the editor. Links are also now case-insensitive.

    But as far as deeper issues go with macro syntax, I think you have a valid point.

  7. To answer your question first, Chris, and build outward to the other comments, yeah, I do see markdown as programming. In order to display correctly, it needs an additional component of a parser; it has to be read over and produced in a different context. The text is not strictly for humans but instructions for something else, some other final product.

    Some of the issue with Twine when it comes to thinking about what it means to write code or produce programming, then, is that it covers more than one language. For example, I always position HTML as a programming language, but I know many others don’t. And I also see both CSS and JavaScript as two other, separate programming languages. So, in just counting those, that’s three.

    But as David points out, there’s also this fourth thing in that it requires another language too. Nearly all the twines I’ve ever seen have some bit of natural language in them. And that’s not even counting the (compiled) instructions either. Nearly all have titles, author names, instructions, or some other things.

    None of which is strictly Twine’s fault in any way whatsoever. I want to make that very clear too. I’m not bashing Twine at all. Having worked in web development for the last decade or so, I know all too well the complications that come with trying to get browsers to do things. (In my experience, the problems almost always originate at the browser level and JavaScript just inherits them.)

    However, in thinking and writing about languages at all, I’ve just fallen into the other trap here. When getting into analyzing if something is a formal language of not (which is a good conversation to have, I want to note), we also miss the fact that it doesn’t matter to someone who wants to create if something is ‘formal’ or not. They just want to make something.

    This is a constant struggle I have in education and I’ve seen it mirrored in the Twine general community too. When dealing with the bleeding edge, we risk cutting off people from using the tool (or engine or library) we are trying to improve. Most people, I’ve found, don’t care all that much about what drives the editor itself, they just want it to work correctly or at least in the way it is perceived to work.

    In order to get what are perceived as ‘needed’ things for Twine, though, other people (programmers) are required to make macros. Thus, and I think this is what Richard was getting at too, many creators become dependent on programmers to make these things. A situation, while neutral at first, has the potential to lean into creators seeing ‘programmers’ (and those with greater knowledge) as holding power or not doing enough to help. (Something I’ve seen a number of times and experienced myself.)

  8. There’s a degree where this is all worth worrying about and there’s another degree to which this is all angst which keeps us from making shit and I’m not sure which overpowers the other.

    I don’t really come from a game design background–I did some games crit before I realized I absolutely hate games crit and moved to game writing, but most of my creative stuff for the past few years has been in music, and that’s kind of the framework I’ve been approaching Twine. I *can* program or code, or whatever you want to call it. in twine, and I *can* do CSS, and my first works were completely solo–I think of stuff like The Richard Goodness Trilogy and Sam and Leo Go To The Bodega as kind of my demo tapes–they lack polish and some more sophistication but I think they give a good idea of The Kind of Stuff I Do–it ain’t radio friendly but I can carry a tune and write a riff. Out of the box Twine is great for making demo tapes. It’s essentially the Garage Band of videogames. And yes, people can do some amazing things by themselves in Garage Band–check out “Visions” by Grimes, which she recorded and produced herself in her apartment because she’s goddamn brilliant–but mostly you’re gonna get some really bad stuff, because most of us aren’t goddamn brilliant.

    But when I was working on TWEEZER, I wanted to have a lot more visual polish, and was frankly getting bogged down on a lot of stuff that was Not Writing; while I knew I absolutely refuse to make another game in Twine Default Color Scheme, because TDCS is ugly as shit, and while I knew certain effects I wanted in the text, I don’t have a great color sense and I wasn’t sure how to use certain macros like <> and stuff. I could make a good looking game on my own; PaperBlurt helped me make a great looking game.

    It’s similar with Zest–I *could* spend time learning how to program certain things, but they would take me a while to learn and again, I don’t like doing things that are Not Writing; while lectronice had to learn certain things and this is a bigger project than he’s done before, he got the basics in a weekend where I would still be struggling with learning JavaScript.

    I don’t know–I guess I see a lot of Twine Evangelization as people passing around home demo tapes and wondering why they’re not getting radio play. And personally, I’ve always worked better in bands than as a solo act.

    So I don’t really look upon getting a programmer and a CSS guy as me rubbing against limitations–frankly, I like that there’s a hell of a lot more possible than I can do, and it actually helps free everyone to do more elaborate stuff. When I was programming the game itself in its earliest stages, there was a ton I had to cut out just because it was too rich for my blood. Knowing Twine the way I do, I know what it’s capable of, and I know I can get a *lot* by describing a mechanic that I want and having Lectro implement it. For CSS, I can give some general ideas to Blurt and he’s going to run with that into something really impressive. (Usually I give him room descriptions and he picks colors out of left field that work perfectly.) I don’t think of getting a programmer and a CSS guy as a dependency any more than I would think of finding a drummer and a producer in order to make a record.

    There’s only so far that a lack of polish can get you, and there’s only so far you need to go on your own. Part of my dislike for Naked Twine is that it limits people to only what they can do themselves. Let’s face it: The Twine that made it to Steam, Depression Quest, was created with a team, with each of the members working to create a strong, sellable work. There’s only so much that rambling walls of text pasted into the default Sugarcane theme will get you.

    I mean, really. Why *aren’t* there more Twine collaborations? Being limited in your skills ain’t a weakness, and it’s not a dependency for me to find a programmer to help me out–I can do things with design and writing that he can’t. It certainly doesn’t help Twine’s image–or the sales of works made by it–to proclaim it as merely a tool for quickly creating small, solipsistic, rough works. while there’s a place for that, I kind of wish more people would start using Twine to make *actual* games. That’s, frankly, why I made Fear of Twine an exhibition (if I had it to do over, I would have called it a “festival”, incidentally) than a game jam. There’s enough opportunities to find out what Twines people can make in 48 hours. I wanted to see what people could make over the course of a couple of months, and it led to some really, really strong works.

  9. People who already learned HTML and CSS, and had already created their own sites think Twine is easy, but it is pretty hard if you never did any kind of web-design.
    People push it like it is the simplest game dev tool, but you can’t even drag and drop an image into it, something you can do easily in web-design software (or in a word processor).
    I see no difference in difficulty from creating text adventures using HTML in something like Dreamweaver.
    In fact it is probably easier to just drag and drop stuff into a wysiwyg editor.

  10. Maybe it’s just me, but this really confuses me. It’s sorta silly to criticize one element for a flaw that every other element in a group also has. It’s downright confusing if the element you choose to criticize is the one that deals with that flaw best.

    So: Why would you get mad at a game engine because it requires programming (most of all if you define programming so vastly that no code-less tool can even be conceived)? And even if you’re doing that, why would you particularly pick the tool that suffers the least from this.

    I mean there are real people who are willing to insult someone over the meaning of “game” and folk who make twines are the least likely to do that. There are real people who are making real money by selling game engines that promise much more polish than Twine and deliver a much more obscure experience.

  11. You can totally drag and drop images into Twine. It’s a (relatively) new feature, but at least it shows that most things wrong with it are being addressed.

  12. I haven’t tried Twine 2 yet, but my difficulty with it is not so much the programming that it takes to do a straightforward branching Twine structure with a couple of variables. I agree that this is pretty straightforward and user-friendly. But it seems like most of what I actually see people doing with Twine–I guess not yours, David–involves a bunch of CSS and Javascript, which is not at all user-friendly.

  13. I guess I’m OK with Twine being limited in what it does. “Twine doesn’t have a world model,” for example. It’s simple to use because it gives simple results. Want complex results? Then using it becomes complex.

    Most twines I know are actually straight-forward branching structures with a couple of variables. My twines all are, that’s for sure. Úrquel uses Sugarcane with almost no modifications, and if it has any charm it’s in the words, not the technical side. Eioioio is a basic branching twine, only the branches tend to represent physical spaces instead of plot points. When Acting as a Particle is probably a “branching structure with a couple of variables” at its simplest (all technical stuff in it was shamelessly copy-pasted). And I’m just one dude. My point is “there’s only so far that a lack of polish can get you” stops working when you realize you can screw polish and still write interesting things without ever running out of possibilities.

    Newcomers who marvel at Twine’s simplicity aren’t writing with hopes to get on Steam. They might not even care about polish. Caring about polish is what all the rest of the gaming world is doing.

  14. It’s not just the rest of the gaming world that is pushing past the limits of accessible Twine, though. Porpentine is giving a presentation called “Twine: Software for Accessible Game Design, specifically pitching Twine as suitable for people with time constraints. I’ve played four of the accompanying games. Two of them are pretty straightforward Twines you could just do out of the box (“Calories” and “Rat Chaos” assuming there’s no problem with the graphics in “Rat Chaos”) and two of them (“Their Angelical Understanding” and “Even Cowgirls Bleed”) are the sort of thing that only professional programmers can come up with.

  15. Failing to acknowledge the existence/trend of CSS-heavy twines would be pointless (more so if you wrote several). You may not agree that polished and unpolished games are worth the same, but the best way to make that exact point is curating them next to each other. And it can be particularly cool because the gesture’s not saying sophistication is worthless, long live the punk. It’s saying they can coexist, and it’s saying Twine is a place where they can coexist.

  16. (Sorry – blacked out for a week there)

    Twine 2 certainly looks interesting, I’ll have a look. I think Twine would benefit greatly from a better editor. Unfortunately, I fear that markdown is an inherently nasty way of doing things, with many escape characters needed even for visible formatting before you even get into anything as complex as linking.

    Ideally, I’d go for some kind of WYSIWYG, like Word, PowerPoint or a decent web page designer. Markdown is similar to something pretty primitive, like WordPerfect for DOS from about 1990. You had to edit your document in a special ‘mode’ where you’d put codes in for ‘start underline’, ‘end underline’ etc. then go to a special viewer to see what it was going to look like on the page. Like doing HTML by hand, I guess. Word just blew that out of the water.

    It also just occurred to me that I did once write a hypertext-y thing called Kar2ouche, designed for schoolkids which had a pretty simple to learn interface.
    It was just a series of timed, still frames made up from layers of text and images, with a series of these resulting in a storyboard. To make a thing a hyperlink you just dragged the destination frame onto a layer, then when ‘playing’ the story clicking on that layer would jump you to the destination. No need for names/labels, or any of that. Frames could time-out and transition you to the next one if that’s what you wanted, and you could string several together quite quickly and end up with a kind of stop-motion animation.

    Too simple to have variables etc. but made some fun stuff with it.

  17. I don’t want to come off anti-Twine; I think Twine is awesome and the extended things people do with Twine are also awesome.

    Still, Inklewriter is far more accessible than Twine 1.x for writing CYOAs with choices at the end. You really can make it do what you want with

  18. …bloody hell, the computer spontaneously decided to post that….

    …the instructions on the GUI. I don’t know how intuitive it stays when you add variables, and it is specifically limited AFAIK in that the choices have to go at the end rather than inline — but then again that’s a conscious choice designed to keep the UI easier.

    I also don’t know what it takes to extend it to multimedia but I don’t usually see someone say “Inklewriter is a tool that’s easy to use to make branching stories. Here, have a look at Banner Saga.”

  19. Yes, Inklewriter’s very cool. Yet there’s the problem that you need an account, and you can’t distribute your stories outside of the site, as far as I can tell. And third party macros are… scarce? nonexistent? So it’s more of a simple space instead of one where simple and complex can coexist. Besides, it seems to push you into the CYOA genre, while Twine feels more like it pushes you only into its structure, but giving you some tools to resist that.

    I guess Twine just hits that complexity/simplicity sweet spot, for many people, in a way that must have a reasonable explanation in the way it works or presents itself. There are many tools better at what they do than Twine, obviously, but I just don’t see Twine’s promise of simplicity as deceitful.

  20. I begin to wonder if this kind of conversation about Twine is one that utterly ignores players. Let’s face it: Someone who has no investment or interest in creating a game isn’t going to give a shit whether or not the person who created it had to use coding or not any more than the average Nirvana fan cares what strings Kurt used. What matters is the end result.

    I mean I know a lot of people dislike the basic Twine CSS. It reminds me of back in the ZZT days–when you started a new room in the editor, the borders defaulted to yellow. “Yellow bordered rooms” became known as a shorthand for a lack of familiarity with the editor. It was as much a social norm as anything, although that particular shade of yellow was pretty ugly–and since it was one of the first things you did learn, if a game had yellow bordered rooms, it suggested that this was a first game and probably not very good. While CSS isn’t the easiest thing to learn, it’s easy enough at this point to learn how to at least change some colors around. It’s almost a brown M&M clause.

    I guess for me I’m always thinking more about the player experience, or more rather about an experience of collaboration. Because while I agree that pandering to the player isn’t always what you want to do, especially in more auteury shit, I think the idea of the death of the player is one of the most arrogant, naive, and stupid ideas I’ve ever heard. There are only so many My First Games that an Audience will want to play. Focusing on the simplicity of Twine limits the audience of the works.

    So I guess the question is, what is Twine? Is Twine a simple tool designed to get people making their first simple games, at which point they’ll graduate to a grown up, real language, or is it a tool that can create a variety of interesting and engaging experiences for an audience? Who is twine for–developers or players?

    Because nearly all of the talk surrounding it has focused on the developers side–whether that’s focusing on the more advanced coding aspects as Cox has done, or whether it’s in evangelizing it as A Way To Make Your Very Own Game. We don’t talk as much about the physical experience of reading and playing a Twine–what it feels like to be on the other side of the screen.

  21. All tools/platforms/genres have default templates or rookie mistakes or practices that work that way. Not giving a crap about CSS is a cool way to just start writing and seeing your words appear and be clickable, which is Twine’s first appeal. Later on you can worry about looks (be it in the same project or on your second game, like I did). OR you can worry about looks right from the start, of course, but I think Twine is built so you care about that later, and that’s fine.

    No one is saying Sugarcane is beautiful (though I don’t see how white on black with a little blue can really be considered that ugly, unless you dislike what it represents), and I’m eager to see what the Zest team can come up with, and I’m eager to see more Twine collaborations, but amateur looks are always kind of cute, and I don’t think that’s holding anyone back.

    We see a lot of Sugarcane because there’s a lot of people new to Twine, always. That’s what’s good about it. But I’d bet not a lot of folks stick to default looks after their third twine (it’s even possible that not a lot of folks even write a third twine, I know).

    Twine has made a big fuss about the authors because that’s part of its spirit, innit? But that hasn’t stopped people from talking from the twine-player point of view. I mean, there are a lot of places to find reviews of twines, where discussion of strategies to make things more engaging for players is as common as it is for any other type of game. And I’m talking about both IF specific places (like StoryCade of Emily Short’s blog) and more general Weekly Indie Compilations that abound nowadays.

  22. To build some off what you are writing about, Richard and David, I think you are right about many of the things you’ve written in the comments here. I really liked your earlier comparison of beginner twines to demo tapes, Richard. I think that encapsulates a great deal of the quick-and-dirty meets great-potential-here presentation of many of the twines I’ve seen, and even most I’ve created myself. The ability to quickly generate something is a major part of what makes Twine so powerful.

    However, and here is where I start to disagree but also possibly open this up some too, I don’t want that binary between developers and players. Nor do I want to ever present Twine as merely a stepping stone to something “more grown up” either. While I know you were only asking — given how much CSS and JavaScript has been written about in the comments here — about if that is the perception right now, I want to come down very firmly on the side of positioning Twine as a fantastic tool to make something, be that the very first game or one among hundreds.

    Because some of the rhetoric I’ve been personally responsible of spreading usually presents Twine in that light, too. That it’s great for a first game or some prototype, but people should move on when they are ready. It’s something I’ve come to regret and I wish I hasn’t thought that at one time, even if I do hear and read it from many other people in “grown up” communities.

    Starting around July of last year, back when I went quiet on Twine, I had started to wonder, as I mentioned in the piece too, if I was only promoting the development of code-things in Twine. If I was pushing for more and more programming, the latest shiny bits, and for more technology wonders. And as I also wrote as well, I now think that’s the wrong approach. Getting hung up on trying to match the needs of people who want to push the edge, like in now including jQuery, will only exclude the first-timers and those with less experience with CSS and JavaScript coming in behind us.

    We don’t have to think of Twine as being either for advanced users or beginner users. We can and definitely SHOULD think of it as for both and try to find some way to help others do all the neat things too. I mean, if there is one thing I can point to as something that is a constant disappointment for me, it’s in the education and documentation of how to do things in Twine. It’s gotten tremendously better since 2012, that’s for damn sure, but there is still a need to do less show and a great deal more tell about various secrets.

    Sure, some small part of me thinks we should make some Judgement About The Future of Twine. But, as much as the uneasiness gets at me sometimes, I know, at least on some level, that all this anxiety is actually really good. That we can’t come to a conclusion about even what the community looks like is great. It’s not at all a Bad Thing that I was told off for being terrible for writing this and that my opinion doesn’t matter at all. (Even if that has made me rather disappointed.) It points to a passion about Twine that will only make it grow in popularity.

    There are lots of opinions about Twine that will never be captured in the comments here and we really do have to support all the My First Games (as disrespectful as I find such a label). As ironic as is that I now push the same ideals of the people who days ago wrote that they disliked or even outright hated me, I do really believe there needs to be space for what might be seen as the incomplete, the glorious trainwrecks. There is a whole swath of people, maybe even a majority, who will never read this and don’t even care. They deserve the right to create and for Twine to work for them too.

  23. This article pissed off a few people on Thursday (regarding the cultural battle side of the essay rather than the code part) which drew a lot of people over to read Dan’s words. Today the article has been pinged by RPS and it appears this is a topic “the general population” is not interested in. As far as I can tell, no one has talked about it in the comments over there and the traffic for a Sunday Papers link is pretty low.

    Makes you wonder how important Twine is, really.

    (I have a response on the whole code thing I’m mulling over. Maybe later.)

  24. Much of this article is very similar to Leon Arnott’s tech-tweet-streams right before Twine 1.4, so it’s even arguable that this line of thought is particularly productive. But yeah, I guess “faltering faith” is kind of a strong way to put what could easily have been “disappointed thoughts that can hopefully lead to making Twine better at what it’s already good at.”

    That’s nitpicking though, and I know it.

  25. David: About Inkle, you can distribute in off Inkle site — there was an Inklewriter entry in ShuffleComp that was distributed as part of the ShuffleComp package etc. You might be able to use this to distributed stories created with a guest account, I’m not sure. But it’s a fair point that it really wants you to use the site.

    The other points are fair as well… but to me that tends to point out that (aside from the gating problems with the corporate control, and even then there are ways in which doing stuff online is friendlier than downloading a Twine app, though I guess you can Twine online now?) Inklewriter does seem friendlier than Twine to the “you-can-just-pick-this-up-and-make-a-game” ideal. It’s not as much of a gateway to more complex programming, but then again it’s not as much of a gateway to more complex programming.

    And I mean, this is a lot like the debate over Inform 7 and I’m a rabid Inform 7 defender. People say “You can program a game just like you were writing in English!” and that’s just not true. And then you get to the really hairy stuff, where speaking of Inkle I’ve just been going through one of Jon Ingold’s extensions trying to updated for the new version by changing stuff like “L__M(##Miscellany, 20);” to “best_etype = ANIMAAGAIN_PE;” because sometimes you just have to find someone who can dive down to Inform 6 to help you out. But it’s still clearer than the other languages that do this stuff, except for the ones that are clearer than it but have their own problems.

  26. So I’ve been following this for a while and glad to see the comments section is still going. I’m just going to talk about coding stuff, rather than the cultural stuff:
    Any time I’ve done a presentation on Twine, I show Inform 7 as well.
    My pitch is this: Twine is (honestly) a little more programming-like than Inform 7 is. But at the end of the process, you have a series of hyperlinks, which is really easy to understand for your audience. With Inform 7, I feel the process is less “programmy” for something more robust and impressive. But your audience has to meet you halfway with the results. They have to deal with the parser, which a lot of people don’t really get. And if you want to make the parser smarter, then you’re starting to do programmy stuff.

    I feel when shown back to back, complete beginners understand Inform better because the results and world model setup feel more like a game. It works in the realm of places, where Twine just works in text in a more abstract way. But if you want to make something easy to use on a tablet that you can show to anyone and have them “get” it, go with Twine even if it’s more work to understand for a lot of people.

  27. “You can totally drag and drop images into Twine. It’s a (relatively) new feature, but at least it shows that most things wrong with it are being addressed.”

    I did not know this, just updated and tested it.
    To be honest did not work as I expected (still can’t drag a image directly into those squares), took me quite a while to figured it out, but it is sure easier than having to hunt and copypaste a full path like you would in a normal web-design, and the Twine tag is easier than HTML tags.
    I still think it is not that much intuitive, but I had given up Twine, now I see how I can use it (not a writer so that small hassle to use images was really demotivating).

  28. Cool, Amanda. I hadn’t thought of the world model as something that makes Inform 7 more accessible, in part because in I7 I ran up pretty quickly against parts where I had to do programmy stuff, but now that you say it it makes a lot of sense. As does the fact that the output of Twine winds up being more accessible — as you know that’s something IF people have been worrying about for a while.

  29. Twine may still be programming, but as someone who’s been making games for more than a decade now, and who hates programming, I can say with some confidence that making a Twine game *feels* different. It feels like I’m focusing on the writing and the structure of the interactive story, not on trying to get things to work. Unless it bugs out, which happens, but which isn’t an issue with Twine’s design per se. And a lot of the changes that are being implemented are going to fix the technical problems that currently exist.

    But problems or no problems, God knows that Twine is certainly a long way away from having to write { blargh(fnu, 6, 7, $glu); f_bollockzoids = x* trapezecall.APItwat ?zoink “444.332.731” } to get a program to initiate the process by which a function can be used to tell the program that maybe next week you’d like to display a few letters on the screen. (But don’t worry, with the new plugin we released, you only need to use zoink the first time! And it only costs $100!)

    Perhaps it’s merely a matter of using the right tool for the right job. I find Twine very useful for making certain kinds of games, so I use it for those. For others, I use different tools. Twine is not an all-purpose solution, but then why should it be?

    So ultimately the problem that I see is the fetishization of Twine as a symbol of all kinds of cultural values that it can’t possibly hope to represent. No tool could. Ironically, given the ideologies involved, this actually seems like just another version of Silicon Valley libertarian techno-utopianism.

    Twine is a tool. It’s a good tool. But beyond that, what we do with it is up to us.

  30. I was asked to give some input by Richard on this topic, I have a passing interest in Twine but found the general syntax and structure of the coding required off-putting. As a person who started in college as a Comp Sci major and switched to English because I’m a more naturally gifted writer than coder (and was only able to financially manage that because I chose to be more responsible in my choice of college from a price perspective), I think the hostility towards the concept of programming from the Twine community may come from a misunderstanding of what programming and coding are, and an ingrained impression of those phrases being connected to a barrier of progress. (Keep in mind that though I have experience with programming languages, it’s little more than the experience someone might claim after having made it through and completed an intermediate foreign language course.)

    I’ve never found the basics of coding and writing English to be terribly different. They both rely on the writer to properly grasp a somewhat abstract concept and have the ability to string together something logically consistent using it. The act of writing code is never the hard part, it’s no more difficult than referencing a dictionary until you learn exactly what it is you need to know. For example, learning what system.out.print(); does in Java is as simple as using it. If/Then/Do/Whatever statements are also fairly easy to grasp for anyone who can do something as simple as put together a jigsaw puzzle. If these two conditions are met, do this other thing. It can be illustrated with events from their lives, like a time their parents told them to clean their room if they wanted ice cream.

    There are higher concepts required for more complex things, but basics, or grasping what you need to do something simple, is like connecting dots. If you have google, a resourceful person can figure out simple things relatively quickly. I’m a featured community blogger on Game Informer’s website and before they fixed their editing tools, I did a good bit of custom formatting for my blog. I had no html experience, but it only took me maybe an hour to track down what I needed to do, I kept that as a reference and kept referencing it until I didn’t need it anymore. I had programming experience, but that didn’t change the fact that I just entered what I wanted to do into google and started chasing links. And having not ever even worked in html previously didn’t stop me from being able to draw lines between what was written and what happened to my blog when I added that stuff.

    The big problem with programming, however, is getting out of the “Hello World” stage, and I’m a firm believer doing so is better done with other people. Attempting to create something that requires code, without anyone else, is a rather daunting task. People hit something they don’t understand and, without anyone else who might to help them work through it, they assume its too hard to learn on their own when instead it may have simply not been put in terms that work well for them.

    What all this angst over the programming side of Twine says to me is that people really invested in it, who don’t have a lot of programming experience, need to find other people in the same boat and work through it with them. Get on Skype, email or dropbox or whatever way there is to get code back and forth – GitHub is great for that, hop on a Skype call and talk about a GitHub doc. Posting tutorials isn’t working together, people need to be talking and discussing in real time, actually working to answer questions as they arise.

    The only time I actually enjoyed coding in college was when I had a class where my friend and I could sit down and do stuff together. Instead of hating coding, and people who can code and do nicer things because of it, the Twine community should consider embracing the concept of working together rather than alone. There’s a reason the biggest games in the world are made by hundreds of people, and it has just as much to do with the power multiple minds have to overcome problems as it does with productivity.

    I feel creative types who have trouble with coding, and are hostile to people who don’t, need to consider the same is true for the coding types, so to speak, when it comes to creative stuff. I’ve found my legs a little with pixel art, but for the life of me I can’t draw anything nice – when I do it’s quite literally an accident. And it’s frustrating to see programs pandering to people who can create traditional art like second nature, when I struggle to make a circle I find acceptable. I’m decent at writing music, but it takes me weeks and weeks of fighting through ruts where I only play the same thing over and over and over every day.

    It’s hard to play on both sides of the fence at the same time, really really really hard… for everyone. Which is why you see so few people making really ambitious things alone. If you want to do both, you’re probably gonna start off on one side of the fence, and have to work a long time – regardless of your race or gender or sexual orientation or what platform you’re creating on or what your starting point is. It’s not like coders can just create something fantastic at will or there isn’t a significant barrier of entry for them either. It doesn’t seem like Twine is the appropriate centerpiece for all that cultural warfare stuff, because its not the only free or cheap game making tool that a lot of really diverse people have made cool things with. Those problems are real, they just have very little to do with tools like Twine or Unity or whatever, and more to do with resources.

    Also, just a side note, the best programmers I’ve ever known were all women. One helped make the Xbox One and works at NASA, one started her own tech company while still in school, and one got a masters degree and graduated with honors ahead of most of her male counterparts – and she’s black.

  31. Nobody can hate programming with as much intensity as an expert veteran programmer. It takes someone who has discovered its true power to feel the bitter regret that despite all the innovations of the past decades, the craft is still largely an impediment to itself.

    Are you familiar with Bret Victor?

Comments are closed.