It’s Twine Week on Electron Dance. This is the last of five posts.
I never had any experience of using Twine until I wrote Truth is Ghost, which was released as part of the Fear of Twine exhibition in February. I had heard all sorts of things. It’s really easy. It’s better than parser IF. It can make your voice heard. It’s the remedy for capitalism. It can make English Breakfast tea.
Now, with a little experience of Twine tucked under my Batman utility belt, I have a few thoughts to share.
Twine is a tool for creating hypertext fiction. You make a node. You put text in the node. You etch links into the text. New nodes sprout and the map spreads. Sometimes it is sensual, watching hypertext tendrils stretch but sometimes the process inverts and all you can see are unfinished paths, doors you wished you had locked, endless rabbit holes of words.
Making a twine is easy.
Making a good twine is hard.
But if you are feeling frisky, you can flirt with some italicisation or something a little bold. Maybe you change a colour. Maybe you would like to change the background? Put a box around it. A box of hearts. A different font? Wait, this is not easy at all, this is not what you were prom—
No one likes to look as ordinary as Ms. Jody Average. For a while, Twine was synonymous with this:
There are still twines being made this way today. This is Ms. Jody Average. But READER do not look at the screen because you will miss all the heavenly glory. The words are the twinkling stars in the sky, twinkling for your attention. Read the words. Follow the links. Find your way. Embrace the hypertext.
It is not enough.
There are too many Jody Averages. We can do better than this. We can make something more beautiful. We can make text plus. If text is so good, then text and more must be better, more delicious food for the mind.
This must be why the mighty Infocom, those old masters of interactive fiction, perished. They told everyone that the graphics of their games were powered by imagination. They said text was key. But they died. Perhaps they did not think highly enough of text plus.
Thirty years on, it is time for a new revolution of text. No-frills white on black is good for starters, but it will not be enough to keep the fires burning. Add a little zest. Let us add a little CSS.
Oh.
My.
GOD.
Let me tell you the sad tale of HTML. I will try to dress it up as a parable.
In the beginning, the web was powered by a simple language called HTML. It contains simple instructions like <h1> for header and <p> to start a paragraph and <a> for a link. The great genius of HTML is that it prized text over implementation. Write once, read anywhere. The hypertext revolution had begun. Well, it was good for starters, but it was not enough to keep the fires burning. Web page makers realised they had the tools to make something compelling. A few mouse over events here, a few tabulated images there: a web page could become an interactive drama. HTML disciplinarians were unhappy. HTML was about content not form. But the new web was about beautiful form. Pixel dimensions took over. No one cared about the promise of HTML. Designs had to be tested in every browser. Designs had to be tested on different screen sizes. Form over content. Style over-- The web gurus knew what was going to happen. The ice, they said, is gonna break.
They solved the problem. They kept HTML clean and made a layout language called CASCADING STYLE SHEETS (CSS) to keep the web designers happy. All you had to do was learn CSS and you could make anything. People flocked to CSS Zen Garden to admire what CSS could do. Except CSS was its own little private fucking NIGHTMARE
Making a twine is easy.
Making a twine with a distinctive visual look is hard.
There are very few people in this world who enjoy working with CSS. This is what some of the CSS from my twine looks like.
The twine community does not tell you to “buy a book on CSS”, because CSS books are hateful creations. Trust me. I bought one myself about a decade ago. I also read it. The twine community, instead, offers ready-made CSS and concise advice. No one wants your CSS becoming complicated, because CSS will eat you for breakfast.
As the fascination for text plus has grown, Twine has moved forward with these new times. Twine has better support for multiple stylesheets so formatting and layout can vary from passage to passage without using macros from the twine black market. But total control always seems a little out of reach.
That extra CSS mile is what can kill you. During the making of Truth is Ghost, much time was expended trying to suppress transitional effects. Those weird transitions between some of the passages in Truth is Ghost? I did not want them. I had a deadline to keep and so I conceded defeat. CSS will eat you for breakfast.
Form may not be your only concern. Maybe you want to make something sophisticated. Maybe pure hypertext, node-link-node-link, is just not enough for your vision.
Instead of creating duplicating a whole node just to add “Gary followed you into the room like you asked”, you could use a variable to remember that Gary is following the protagonist through the narrative corridors of your twine. It almost sounds like programming, does it not? Does it look like programming to you?
Come, now, do not panic. They are mere IF statements. Except the IF statement is full of trouble. Maybe you should panic. As you layer in several IF statements you may also notice the resulting text looks wonky and wrong, with additional spaces popping into existence against your authorial will. Okay. Panic.
Maybe this is still not enough. You want more. You want all the latest macros. You want text to explode in the middle of a paragraph when a link is clicked. You want pauses. You want video. You want to distort space-time. You want Twine plus.
This type of trajectory is well-known.
When a new technology lands on the dance floor, it looks simple. It has few buttons, few functions. By design, it cannot be customized because that brings complexity and complexity turns away people. The early adopters love the technology. They evangelize its lack of bloat, its everyday appeal. But they ask for a few extra features. Something here, something there. Nothing too fancy. But these people are experts. They are not learning from the ground up. When a technology caters for power users it is all too often at the expense of the newcomer. The more features included, the greater the climb for the next generation of adopters. Now they see bloat. Now they see an entrenched old-guard with a wiki. At first the old-guard continue to evangelize but, in time, they believe they have paid their dues, put in the time, and fall in love with RTFM.
This is not the Twine community.
At least, not yet.
It may not happen. But it is already clear that the Twine movers and shakers want to be able to do more with the platform. It is difficult to say where Twine will end up or whether Twine itself is a passing fad, destined to follow the example of Infocom. You remember when Depression Quest (Zoe Quinn, 2013) got on Steam? Man, those were the days.
In ten years time, what is Twine? This, I do not know.
Twine Week
- Monday: On Reading Twine
- Tuesday: On Truth is Ghost
- Wednesday: On the Achievement
- Thursday: Counterweight 12 “On Fear of Twine”
- Friday: 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!
Okay, these last two weeks have been pretty tiring; going to be largely offline for a couple of days. I’ll be back. Honest.
Ah, CSS. I learned the basics back in the early 2000s, and thought it was ‘not that bad’. Many years later I looked at a /real/ CSS file, not one of the simple things I made for my lo-fi HTML creations. Holy shit, that was a rude awakening.
I still want to try and make a Twine. But I also want to make many things. I’m not sure that being unable to settle on a tool to tinker with is the best starting point.
As for the future of Twine, well… who can guess where anything to do with computing will be in ten years time?
I was just thinking about TWEEZER and how much effort has gone into making it as a Twine. I’m thinking it would’ve been actually pretty easy to do in any old BASIC language. And here we are, sweating over something as esoteric as CSS with Javascript macros pasted in. The one advantage is that Twine is browser based and practically anyone can run Twine works. But, boy, BASIC, you know?
In terms of just “making” something, Twine is probably the easiest of all. You can make a basic hypertext story using the standard Sugarcane template very easily. Use of variables – it gets a little more complicated then, especially with all the spacing issues that crop up.
I think the shooter will still be with us in ten years time. But I wonder if Twine will ever be any more than a “niche” thing. Yes, Depression Quest is on Steam but one free game does not a cultural shift make.
As far as web development goes, and I include Twine in this group, it has gotten far easier to do basic things. There was a time not just a few years ago when displaying certain types of images — PNG transparency in IE 6 required DirectX calls — and basic tasks such as sorting browser events were incredibly hard. Over ten years ago, when I started using JavaScript, the language was treated as a joke. Now, there are whole ecosystems designed around it as both a client and server language.
Web development as a field is incredibly hard to predict. And that’s just at a macro level too.
As far as Twine goes, yes, I think it will remain relatively niche. To compare it to another seemingly savior of IF, Inform went through a similar trajectory many years ago. It too was heralded as the coming new age of interactive fiction. Now, though, has anyone heard of Inform 7? That is, outside of something like the Xyzzy Awards?
The other problem Twine has is that it is still a huge mess internally. It’s a Python GUI running a JavaScript-based Wiki system with a large number of hacks to make it more use friendly. Many of the reasons “code” looks so strange in Twine is that it is parsed in bizarre ways. To get around some of the issues with storing and reading JavaScript, many of which are in place to prevent security problems, Twine has to contort itself in strange ways.
As someone who has supported the Twine community from way back in December of 2012, I still believe in the promise of helping people learn Twine. It is still the easiest to learn and usually the fastest to get started with for those who have no programming knowledge whatsoever. However, it inherits many of the problems HTML itself has: those of competing specifications and companies trying to promote their products with new and exciting features.
The “learn the Rules” is not wrong, but it is also not strictly Twine or its community’s fault either. There are far more nefarious undercurrents to the politics of browser functionality and specifications than many people realize. There were and continue to be whole hidden wars that have shaped how we currently use the technologies and software behind Twine. The consequences of all those battles are what we live with today and what dictates how CSS and JavaScript are allowed to work.
@Dan: Yes, I think Twine is probably the easiest tool to make some interactive fiction. I can see it’s upped it’s game massively – I went through one Twine upgrade during the making of Truth is Ghost and I was absolutely grateful for upgrade.
You make the point about Twine is a mess internally and so, to some extent, all those macros and so on are not really Twine issues but due to the instability of the underlying web platform. However, no one needed to create all those macros to make twines. No one needed to mess around with CSS. Twine did a job and did it well – but it didn’t stop the urge to tinker with the formula, web chaos be damned, and make things which were more unique and more responsive than just showing new pages after clicking a link.
And here I’m not painting this as a community “problem” or anything like that, merely inevitable. Nothing stays the same, things always move and evolve. What was groundbreaking yesterday is antiquated tomorrow (hello Ultima IV). I worry that for twines to be noticed down the line, people will need to mess with presentation and/or form. The hypertext story seemed new, all over again. That evolution will leave people behind. If we instead deny evolution, does Twine last without it?
(Twine will survive, but its manner of survival is what I’m getting at here. Niche or super-niche?)
“You make the point about Twine is a mess internally and so, to some extent, all those macros and so on are not really Twine issues but due to the instability of the underlying web platform. However, no one needed to create all those macros to make twines. No one needed to mess around with CSS. Twine did a job and did it well – but it didn’t stop the urge to tinker with the formula, web chaos be damned, and make things which were more unique and more responsive than just showing new pages after clicking a link.”
My point wasn’t that JavaScript or HTML is unstable, but that the way Twine goes about doing things is. Much of the lauded functionality of Twine internally is a mess. It is using things that open up the browser to all manner of exploits and is, in many ways, hacking around a solid foundation of JavaScript to do things. (Most of the time, it does things in a “wrong” way but is run so fast in modern browsers that few people would ever be aware of it.)
I also pretty strongly disagree that the “macros” didn’t have to be written. Most of the stuff you showed in screenshots are macros. Set, display, and even using basic arithmetic inside passages are macros. Nearly everything that isn’t a bracketed link in Twine is, at some level, a macro.
As far as the evolution — ‘feature creep’ is the software engineering term — goes, I agree with you on this. In fact, I’d go so far as to state it is not only a future problem, but one that has historically plagued Twine for years now. Most of the well-known people who use Twine substantially change the way it works either through CSS, JavaScript, or combinations of the two.
This has been a problem since CYBERQUEEN became popular back in 2012 and will be going forward too. With each new version Twine gains a few new things — being able to use jQuery without using macros is nice — but it is still being pushed not by the needs of the common user, but by those hacking into it to add things they want.
(To answer your question: super-niche. But relatively speaking, of course. If many of the louder voices stopped using Twine, I doubt it would be as popular as it is now. That is its Achilles’ heel. It is only in the limelight as the people who use it are too.)
Dan, I’m thinking more of the original Twine pitch. If we go back to Porpentine’s “Creation Under Capitalism” she writes, “The history of game design has been working with a canvas that screams at you and changes shape and rejects your strokes if they aren’t just right–working with machines.” The idea that we can just write what we want and stop worrying about programming, an adjunct to the Rise of the Zinesters line that today’s tools are better for the non-programmer. The rise of macros threatens to undermine that. You don’t need any programming nous or macro knowledge to write no-frills no-image white-on-black node-to-node hypertext with the default Sugarcane template – but possibly you’re going to look amateur compared to those with macros or CSS. If not today, I can see that happening tomorrow.
Did you see this recent twine (do not) forget by oOoO and lectronice? It blows you away in terms of technical prowess, but I’m not sure why it’s built in twine. However, saying that, there are some good moments but I don’t think the writing itself is strong enough.
I haven’t been following Twine closely so I wasn’t aware there was a tipping point anywhere.
However, I want to be clear for the lurking public: there is NOTHING wrong with creating complex macros and CSS to pull off crazy stunts and sassy-looking words – the history of game design has seen constant one-upmanship in both the AAA and indie spaces. But if Twine is to remain a tool of Ms. Judy Average, macros will diminish those works located beneath the bleeding edge, stratifying Twine in exactly the same way programming is argued to be exclusionary.
I agree with you that there shouldn’t be the barrier of lots of code to do neat things with Twine, but I also know, having watched Twine rise over the last couple of years, that the most successful and popular users of Twine are those applying and demonstrating a high level of competency with the very “programming” vilified by many.
Since reading your response, and on thinking about these issues the last few days, I’ve been increasingly thinking about writing an essay on the paradox of Twine’s “pitch.” There is, on the one hand, this promise that you aren’t “programming” with Twine, yet are writing in a Wiki-style syntax and are often wrangling CSS to do visual effects.
But, on the other hand, that’s all programming. Writing HTML is programming. Writing CSS is programming. Writing JavaScipt is programming.
To make distinctions is to give in to creating a taxonomy of what is and isn’t “programming.” That’s profoundly dangerous and invites many of the lexicographical fights I’ve seen over the years of arguing that scripting languages aren’t “real” programming either. That compiled languages, those whose output can only be read by machines, are true “programming.”
It’s all fighting over whose works get considered and whose aren’t.
However, in getting back to thinking about Twine, I’d write that the tipping point was with 1.4. Forever ago early last year, 1.3.5 was a fix for some problems with 1.3. It didn’t introduce anything and was more for stability than anything else.
With 1.4, jQuery was introduced. And the ability to include other twee files. It was, if we want to divide the Twine community into “programmers” and “non-programmers” (for as ridiculous as that is to consider), 1.4 was made for those looking to do more. Previous versions made it hard — but not impossible — to include outside JavaScript libraries. With jQuery, it is far easier to do that now.
At the risk of drawing this out even more, that was one of reasons I stopped using and had gone mostly silent on Twine. Back when I was writing weekly posts about how to do things in Twine, I saw I was leaning into the technical side. I wrote several macros, showed how to do the same, and was generally all about using JavaScript to do things in Twine.
However, I noticed a fierce trend of “Twine doesn’t use programming; here is a macro” too. There was this constant dissonance of rejecting “code,” yet relying on JavaScript to do nearly everything. Many of the earlier communities I was a part of would equally promote that Twine didn’t require learning code and emphasize those projects that used it the most.
I wasn’t comfortable with that. I’m still not.
I like Twine. I’m still happy to help people with their projects and, if I come across something I think might help the general community, I will and have promoted it. However, I have long been of the belief that drawing some imaginary line between what is and isn’t programming and placing Twine on the “isn’t” side is harmful.
So, in short, I agree that there is a “macros” problem. And I’ve only seen it get worse since I’ve been watching Twine grow in popularity.
So, I don’t really have much to add to this. Thanks for sharing, very enlightening.