I’m not sure when it started. That is, I’m not sure when the fight of those who would exclude Twine games from the the genre of “games” moved away from the larger battle of definitions and began trying to take apart what might make a “game” to dismiss Twine projects. Regardless, I imagine it to be the act of people who, finding out they cannot push something so large over, are now trying to dismantle its footing. It smacks of desperation to me.

John Brindle takes up this idea in his own post what a mechanic might be from his (pragmatic) view. However, in reference to how Twine works, he writes “In Twine games, as Raymond Neilson pointed out earlier today, the basic mechanic is ‘click’ (or rather, in the backend, ‘move’ from one tile to another).”  Later, he elaborates, writing:

Also arguably, Twine games and text adventures completely blow our ideas about ‘how games work’ out of the water. For example, a big part of the ‘interactivity’ of Christine Love’s Analogue: A Hate Story is remembering stuff you read in one part and applying it to a decision later. The same is true in Twine games: one of the player’s actions is to read meaning from passages of text and carry it with them until it informs their decisions or reading of another. This is a basic unit – a ‘mechanic’ – of linguistics and literature, but not of games, because we don’t think about them that way. And yet, isn’t it just as large a part of games? When you see an enemy for the first time in a game, don’t you, to exactly the same extent, ‘read’ their appearance on the screen, ‘read’ the signals about your HP and their HP that you get, and carry that knowledge forward?

In reading that, I had a slight problem with how he expresses that Twine “in the backend, ‘move’ from one tile to another” as that’s not actually true. It doesn’t act that way. It, in fact, overwrites what the player is actually seeing on the page itself. Because of the player reacting to what they are presented,the content changes. Passages, while it is convenient to think of them in terms of hypercards, are actually data that is manipulated and whose states are being changed by the act of interacting with the story.

This is vitally important for his later comparisons of literature (the reader carrying information forward) and interactive fiction (a player needing to use that information to progress) as it speaks to the difference between a hypertext and Twine game too: the act of mutation marks one as a game and another as a text. This is, in my eyes, the ultimate proof Twine games are “games”. A text does not change its content from interaction. A game, on the other hand, does.

The internal memory is changed as a reaction to the presence and actions of a player. This is my own definition of a mechanic: a reaction to an event. Texts do not have this. The act of interacting with a novel does not change its contents. Sure, you can add more data or even remove it. But, in the reading moment, it is not changed. Even hypertexts do not have this.

While hypertexts are thought of as having many valid paths through its content, they do not change states. Twine does this constantly. Each new passage is added to the History object and is saved during the session. Playing anything created in the Sugarcane format shows this as the generated hashes of each new passage shown is concatenated to the current URL for bookmarking purposes. The Twine game itself is changing its internal memory during execution.

It’s a combination of code and interpreter in one package. A Twine game creates itself from its own data — reads through the text content of the children nodes of the div ‘storeArea’ — and maintains a Tale object that is composed of what it found. However, during execution, the page itself, both what the player sees visually as well as the DOM of the page itself, is changed. Child nodes are read, changed, and appended — all as a response to what the player does.

I would go farther then to define the basic mechanic of a Twine game to not to be based in a ‘click’ event, as Christine Love’s Even Cowgirls Bleed and my own little Not Game shows. Instead, it’s the movement of the mouse itself — the mouseover and click DOM events. There must be a clear intention toward interaction. The movement of the cursor across a page bubbles the event across every element it touches. When this is caught, it triggers the mechanic and calls whatever function was listening for it.

This is what makes a game the same as that of one created through Twine: not only is information passed, but progression comes from decisions. Passages do not exist within the narrative of the History object until they are generated as a result of the player. This is unlike a text, whose content is fixed ahead of time or even a hypertext whose nodes exist in connection to the previous one. The passages within a Twine game exist always in potentia until they are rendered.

Passages do not have connections to one another until they are shown to the player. They exist as saved wiki text within the Tale object. By choosing links to follow, their connections to each other come about because of a reaction to the player. A decision is made and the code reacts to create the next passage visually from what an author wrote within it, influenced by the other JavaScript code, CSS rules, and even other HTML elements that exist before it.

The player both reads and writes the story in Twine.