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 itch.io 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.
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.
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