Let's Play: Ancient Greek Punishment: The Twine

Opening salvo

Hi. So because I've been working on an Inform 7 version of the punishment series, it seemed like a sensible idea to also give some thought to the Twine version, being in a text-y mindset etc.

It's also because part of me feels like I can maybe knock out a quick Twine version and thus delay releasing the Inform version which I'm still caught up in indecision over in terms of whether to "save" it for IFCOMP, submit it to sub-q, or just to put it Out There. Probably it'll be something like "submit to sub-q and get rejected" followed by "submit to IFCOMP and fail miserably" followed by "Put It Out There". So, everything.

Anyway that's neither here nor there, let's talk Twine.

It's probably silly to think I can do this quickly, nothing is quick.

Big question: "style versus substance"?

One thing I've been thinking about when it comes to Twine is whether I should be focusing on making a Twine that is "like a Twine" and so looks like and feels like whatever a "standard" Twine looks and feels like that. So narrative-oriented, links as actions and expanding descriptors, and stuff like that. Perhaps in some sense "using Twine the way it's intended" or something.

On the other hand I could think more about using Twine as a platform/material/technology and so look at how the affordances of Twine as a language relate to the punishments, asking which elements of Twine are cyclical, reptitive, etc. This seems more obviously interesting to me, but could potentially yield something that "doesn't look like a Twine" which would slightly defeat the purpose. This is especially the case when I start thinking about this as a vehicle to make a kind of very typographic/concrete version of the game and complete that with fancy stylesheets so it just doesn't look very Twine-y.

I haven't quite settled that, but I think it's clear that I at least need to think about how the underlying affordances of Twine relate to the punishments. I can just have an "and then" kind of story, and obviously the punishments aren't really about CYOA decision-making (or they could be in a comedy way, but I don't think it's the right way in this context? Maybe it would be funny to have a downloadable CYOA version?).

So I suppose its "both" then. It should still be like a Twine I think (and so less obviously like something like Burnt Matches), but should ultimately rely on the underlying mechanics of Twine (and hypertexts in general) to represent cyclical/eternal punishments.

(This feels related to questions I've been thinking about relative to Inform 7's underlying world representation and having punishments be true to that world representation - the edible apple being the quintessential example of this kind of authenticity.)

Twine affordances

The other day in a café I sat down to try to write down the various scripting hooks and other techniques that Twine (2) has available to put to work here. (Though now I say that I kind of wonder if Twine 1.whatever is a better tool given the number of extensions? Although is using all those extensions somehow less Twine-y?)

• Hyperlinks (the basic idea of passages/pages linked to one another)
• Cycling links
• Click to reveal links (and mouseoever variants) - Changers, links
• link-repeat maybe interesting in that it's iterative
• Variables saved and remembered
• Conditionals and loops (infinite loops?)
• Arrays
• Datamaps
• Datasets
• Dropdown menu and other UI elements (seems very UI though,)
• Undo (maybe something interesting about getting the player to click an undo link)
• Note that you can generate errors that might be of interest? Stack overflows? Non-existent destination passages?
• Live macros that are updated in real time
• event macro looks like it can handle timers?
• Mathematics
• alert and confirm and prompt
• Loading and saving games (this is another way to return to an initial state)
• Text manipulations, including rotation which could be funny in Sisyphus (but too concrete?)
• Transitions

So it's a pretty detailed set of possibilities? A lot of these aren't what I would call "typical" Twine techniques at the Twine-culture level necessarily, but still worth playing with? They are, after all, part of the language?

So look at the list I think these things:

• Part of Twine is creating a directed graph (of links), and that graph can be cyclical, and that can represent an experience that returns to its starting point. This idea of linking is, really, the fundamental nature of Twine, so it's appropriate to leverage it.
• A cycling link is another example of something that can return to its starting point (though in this case on a single page). After standard hyperlinking I think of it as the most emblematic Twine technique.
• Saving and restoring is kind of interesting. Under the hood you would be able to save the game in its incomplete/initial state, let them play through to a potential end point, and at the critical moment reload the game state. This could play well for Prometheus which has more of a "reset" idea than the others.
• Errors are something I find potentially interesting. You could imagine a linear story that ultimately tries to link to a passage that isn't there (which represents a completion state)? This might break the central idea of ultimately having something eternal though, unless there's some way to reset the experience after the error?
• Likewise an infinite loop could be funny, but again seems to give an ending which isn't desirable?
• Undo is an interesting idea as well? One could either trick the player into undoing their successful action (say pushing the boulder up a hill) or making it explicitly the only available action? Might be a bit contentious, though, to let them exist in a state that's finished.
• Timers (which are maybe built in? Maybe not?) are a way to cause something to happen, and that something could be a reversion of state? Most obviously a timer could be used to have the basin empty of water in Danaids, or have the eagle progress toward the player. But at that level it's really only serving a purpose much the same as any timer in other formats, so not very specific.
• Link repeating is intriguing perhaps especially for Zeno? The idea of a link that then reveals more text over and over again is an interesting way of representing the road travelled?
• Transitions might be a way to at least add some flavour?

Designs?

Sisyphus

• One of the tightly cyclical ones
• Could function as a cycling link or a cyclical graph for that reason
• Maybe cycling link as it feels more helpful here than in Danaids?

Tantalus

• This most fundamentally for me seems to be about non-functional links? Perhaps this is where the error could be introduced? You can still go back away from the error perhaps?
• Either than or links that grey out and no longer work on mouse over? (Have to worry about mobile though in that case.) Maybe there could be a Reach followed by an Eat/Drink?

Prometheus

• I like the idea of a save and restore? You could explicit say "game saves" in the first scene. Then the eagle arrives and eats your liver. And then the game restores back at the beginning literally. Quite nice. Do I want a big performance of needing to be able to struggle the eagle up? Is there any real advantage to representing this? Or better to have a linear telling? Weird given that struggling has been utterly central to my telling of the myth...?

Danaids

• This feels the hardest as it often does, it's a more complex set of actions and involves transporting something from one place to another. I guess I can represent it with a variable saying whether you have the water or not, though you then end up with just kind of bad pseudo-parser IF?
• Still have cyclical graph "available" if I use cycling link for Sisyphus

Zeno

• This feels like a candidate for the link-repeat idea? That each time you click you add distance to your progress but never actually get all the way there?

And so...

Makes sense just to mock these up and see what we see I imagine?

Just to say I put the meta tag in for device font size stuff on mobile and it worked fine. All the things seem to be visible in a single screen now which is the ideal. Don't think it needs to be more than that.

May I say, too, that I quite love using the absolutely default CSS for Harlowe. Looks just so much like a... Twine.

Well, I made mock-ups of them all as promised. Here is what happened.

Sisyphus

I used the basic cycling link. There is no version of the link where the boulder reaches the top as that would create a (kind of) win state, so it's just "nearly there" followed immediately by "rolling down". It's the simplest of all the things I did and it's quite satisfying. Importantly it feels very Twiney. Kind of the ultimate Twiney thing, and a perfect fit here.

I went with very blank and sparse language which I think works fine. I mean, it just kind of works?

Little weird to feel like it might be "done" but who knows, perhaps it is.

Should I be doing the due dilligence of just playing a bunch of Twines to make sure I'm hitting the rough style and approach? Does that even make sense?

Tantalus

This one was hard because I wanted to be fancy with mouse-overs, but have to acknowledge at the same time that it won't work with mobile. As such the base-line "trick" is that you click on links but they take you to pages where they turn out not to have worked, repeat ad nauseam. If using a mouse-style pointer this also happens on mouse over which is a little more fun and feels more like reaching, though I guess you could think of the movement as a reach and the click as a "grasp", in which case clicking is fine.

I spent a fair bit of time trying to get single-passage versions of this going with text and link replacement and so on, particularly liking the idea of things happening both on mouse over and mouse out. But again, if we're doing mobile that can't work anyway so perhaps not the biggest loss. (Not to mention I couldn't get it going anyway.) I think it's probably only to do with me wanting to flex my (non-existent) technical abilities, so also no loss there.

Prometheus

I ended up doing this one just with timers and not with any save and load stuff. The save and load is pretty funny, but I suspect it's just more funny for me and not particularly visible on the surface for an actual player. Further, saving and reloading doesn't really register for me as a typical Twine experience kind of a thing, so I don't think there's enough of a hook into the "cultural practice" of Twine?

So the way it went is basically just a circular graph but with the transitions being based on timers. This is nice because the player has no agencies and just sees the cycle happening.

I ended up not implementing struggling because it just doesn't feel like it adds enough, just transforms it toward being more of a kind of systems/simulation experience, which Twine can do, but isn't really the kind of thing I'd say is typical or in its wheelhouse. As such the player does nothing except watch the eagle come and go.

Danaids

The most systems-y one in a lot of ways (as seen with the text adventure). This is the one I "spent" the circular graph card on, so it's just four passages depicting the filling and emptying of the basin over and over again.

It maybe feels slightly less-than-ideal that two of the five are literal cyclical graphs, but on the other hand that really is the ultimate structure for a hypertext to represent repetition, so maybe it's acceptable. And I get brownie points for having the cycles be implemented differently and with different agencies right?

Zeno

Relatively pleased that this one manages to "solve" the Zeno-representation problem in a very Twine-y way and also manages to do a single-passage thing (along with Sisyphus). In this case it's using text replacement stuff that allows you to have the agency of "I run" and to have that alter the representation of how far along the track you are. It uses "half of" repeating on itself to create the requisite distance-to-go infinitely which is nice given that halving just stacks neatly.

So I mean... is this thing somewhat... done?

Single-passage versus multi-passage

I suppose this whole single-passage versus multi-passage thing does give us a particular aspect of Twine to think about. For me it currently feels most like a passage transition is a moment of action and time passing?

Or not? I don't know. Maybe the question is just an open one - what is the weighting and meaning of a textual/link change on the current page versus a transition to another page? What if the new page represents the exact same kind of textual/link change? Then the difference is just a light flicker? (At least with the default Twine passage transition.)

When I think about what I've seen in-page stuff done for (almost always cycling links) it has tended to be a way of altering flavour texts or expanding descriptive elements, so more about "looking" I suppose. Whereas in Sisyphus I'm using it to represent a very active piece of exertion. I think I "get away" with it here just because the cycling link is too good of a joke/play-on-commands in the context of Twine not to use. Anyone who has Twine-d will recognize what's going on and hopefully get a chuckle out of it. Which is part of the point of all this right?

Reload?

One weird thing I noticed with Twine is that if you do a standard reload in the page (or select the location bar and hit enter) it won't reload back to the front page, which is maybe a little frustrating as it probably means 99% of people who even play will try one and get stuck in it and not bother to look at the others.

I guess I can see if there's a way to alter that behaviour, but I suspect it might be baked in there. And I really don't want to just offer an in-game "reload" as that would be admitting the punishments aren't infinite.

World's fastest game?

So then have I finished one of these games in basically a day? Perhaps so, I don't think there's so much to agonize over here.

Show it to a person or two and call it a day? Perhaps so.

Jim and Mary took a look at the game overnight and I ended up feeling pretty dispirited by the feedback - through no fault of theirs, just that it showed kind of confusion and a lack of impact. See the testing documentation for their responses.

The big take-away for me was Mary's point around the experience not really feeling like anything, and this tapped into my fear of precisely that. As such, I initially reacted to the feedback by getting down about it and thinking it's just a bad piece of work, which is obviously an overreaction, but that's how these things go right? Right, dear diary? In reaction I also made a specific change suggested by Mary (numbering the minigames) as a sort of way to assuage the feeling by just doing something.

However, in revisiting the game and in conversation with Rilla I've managed to recover my good humour about it. And specifically I think a helpful thing about Mary's response (which I wrote to her about) is that she's really identifying (for me) something about Twine's more generally. Maybe it's a lack of imagination on my part, but I do find the base-level agency of clicking links (and reading the reaction) pretty flaccid and uneventful. To me, that's sort of a part of what a Twine is like, a very flat literary experience. (Part of it in the case of the punishment games, though, is also the intentional spareness of the text, but I don't think that accounts for much of the lackluster experience, could be wrong.) And I don't even think it's a bad thing, it's just a particular kind of affect that one can achieve in that particular medium, it's very distancing and cold, and that can be a very interesting standpoint to have on a particular fictional world. (To some reasonable extent I think that Burnt Matches does a good job on this front - the neutrality of the medium plays well with the emptiness and post-apocalyptic stillness of the setting in that game.)

And then beyond this affective layer, I think that this Twine version is worthwhile for just the reasons I've been discussing throughout this process: it's an engagement with Twine as a platform for expression, using a kind of "control variable" in the form of the punishment stories/interactions. And as per the discussion above, there's stuff to say about how the affordances and technical nature of Twine play into that. And then there's the kind of cultural layer as well. And then there's the affective layer that worried me above. So there's plenty of value.

How much of that value is "visible" to a generic player I don't know. I think that you'd have to be someone who at least knows about Twine and has played other Twine's to get a sense of how this game fits into that tradition. And then ideally I'd want/need that player to also have a sense of the larger project going on here in terms of the repeated "remediation" of the punishment game itself and what that tells you about how the present game was constrained and constructed.

So anyway, I'm okay again, thanks for listening.

I symbolically reverted the numbering system I'd added as a bandaid solution, too.

(Note: throughout this text, I’ll be linking to process materials generated as part of the project in its code repository. This approach to process documentation is part of the Games as Research project.)

Let's Play: Ancient Greek Punishment: The Twine is the ninth edition in the "Ancient Greek Punishment" series I've been working on since 2011. Lately I've been interested in what happens when I retell the five mythological punishments using the "language" of different game engines, and this time around the game engine in question is Twine, an easy-to-use and highly accessible tool for creating hypertext stories.

Each of the myths has the character of being an infinite punishment scenario, the most famous probably being Sisyphus, doomed to push a boulder up a hill only to see it roll back down over and over again. Twine has its own character as a game/story creation tool, in terms of everything from its default stylesheet, to its underlying coding language of "macros", to the typical ways the Twine community uses Twine's features to create their stories. I'm always interested in the intersection between design and the technology in use, so in the following, I want to look particularly at each specific myth and how it interacts with the capacities of Twine through my own design decisions.

Sisyphus's cyclical situation

I'm not 100% sure why, but I view the "cycling link" as the emblematic storytelling technique in Twine stories. It's often used in stories in a couple of ways, but perhaps most interestingly as a way to create agency for the reader in determining the actual description of a scene. By cycling through the possibilities of the link, they can set a particular descriptive passage the way they like it, perhaps making a vase contain peonies instead of roses, say.

In planning to make these punishment games in Twine, it was immediately obvious to me that the cycling part of the cycling link would be a great affordance to leverage - after you've seen all the possibilities of the link, it goes back to the first and continues on. As such, it's ideal for representing an endlessly repeating set of options, or in this case actions. So Sisyphus's pushing of the boulder is encoded as a cycling link - each advance of the link gets the boulder further up the hill, until the final option sends it rolling back to the bottom, leaving the player back where they started. The code looks like this:

Something that interests me here and elsewhere in the game is the physicality that you can interpret as part of the interaction here. Each click on the link (or touch on a mobile device) represents a literal push of the boulder in the story - the player exerts effort, however minimal, to advance the text and the boulder itself, the text is the boulder, the cycling link is Sisyphean.

The apple of your eyes only

Continuing with this idea of physicality, in Tantalus I went with the key action of "reaching" as features in the story. Tantalus is perpetually reaching upward for a piece of fruit or downward for water, but it always thwarted when it moves away. It's another cycle in the sense of reaching, failing, reaching again, and so on, and so the graph of the story is tight loop of two alternating passages, depending on whether you've reached for the apple or the water:

In representing this activity using Twine's affordance, I was taken particularly by the idea of mouseovers on links that would deactivate them, followed by their reactivation on mouse out. I spent a decent amount of time trying to get this work, but the nature of the associated Twine code seemed to make it impossible to have this occur within a single page. Instead, I needed to create separate pages ("passages" in Twine) that would be reached on mouse over, with the appropriate link inactive on that page.

Importantly, this code interaction of mouse-overs really simulates Tantalus's plight for the player. You literally reach (with the mouse pointer) for the "apple" (link), only to have it become inaccessible (the link vanishes). I think this kind of correspondence between played experience and lived experience is particularly interesting, a kind of deeply low-fi approach to the more direct metaphors of alt-control approaches. In the end, I also realised that mobile devices don't have mouse-overs, so I implemented the same action on click/touch, which still fits the physical metaphor well in the sense that a mobile user reaches (with their actual hand) for the link, grasps at it (by touching), and then sees it become inaccessible.

This raises another weird element in videogames generally: the failed action. I'm very intrigued by the emotional state that can be generated by trying and failing, especially in the context of videogames' general drive to provide consistent and constant agency for players.

The role of the Promethean reader

Speaking of failure, the Prometheus myth has always been my favourite in the Ancient Greek Punishment series of games specifically because of the enforced passivity of the player. In most versions I've made the player can only struggle to stop the eagle pecking out their liver, but ultimately must succumb.

In the case of the Twine rendition, I ended up dropping even the option to struggle because it felt as thought it would turn the experience into too much of a "simulation" (with states concerning where the eagle is, how much liver is left, etc.): this is something Twine can do, but I wouldn't call it a strength. Instead, I went with a favourite Twine affordance: timers. Although they're not used with great frequency (in the Twine's I've frequented), switching pages/passages based on time rather than player input is an interesting switch-up in terms of your experience of the text: pages don't usually turn themselves.

In the case of Prometheus, this works out well, since really Prometheus's experience is one of waiting. As such, in the Twine version, the reader is presented with a cyclical set of timed passages, one after the other, which describe the inevitability of their liver being pecked out by an eagle. It's a story that tells itself and the player is transformed into solely a reader. It's all cut-scene.

Patterns of hypertext bathwater

The Danaids is the story of a person (well many people in the original myth) condemned to pour water into a leaking basin (or bath, or something), trying futilely to fill it. It's always been the most complex of the myths I've tackled in this set of games because it involves multiple stages of action: filling a receptacle, moving to the basin, pouring the water, seeing the water leak, returning to the filling station, etc.

In the context of Twine, though, this kind of thing is very straightforward and natural: it's a cycle of pages all linked together by the appropriate "actions". It looks like this in Twine:

In fact, this is a real classic of hypertext design write large, appearing as one of the key patterns in the canonical article on the subject Patterns of Hypertext by Mark Bernstein. Unsurprisingly, this was the very first structural affordance of Twine I thought of when I started to tackle this game and I even "saved it" to be applied to whichever of the myths seemed most resistant to other techniques (one of my goals was to avoid exact repetition of any one Twine tool).

One unfortunate side effect of using what feels like such a "literary" hypertext approach is that I think it really does lose any real sense of physicality and is much more in the vein of "select an action/path and see the result", a more typical/conventional experience. It's an ironic truth, I think, that a link that describes an action ends up being nothing like performing that action. It becomes entirely the role of the reader to imagine it.

Additive infinity and immobility

The final punishment myth is that of Zeno, not technically a "real myth" per se, but it should be. In this one, Zeno is doomed to run toward a flag he can never reach because of his (highly comical) physics puzzle that motion is impossible because you have to repeatedly get half-way to your destination. This isn't technically a cycle in that Zeno always makes progress, just increasingly smaller progress, and so the challenge is finding a way to represent that.

In the past I've used things like listing the explicit distance to go (while accounting for floating point number overflows!) and even mathematical formulae using sums approaching infinity. Given a hypertext is focused on, well, a text, I didn't want to abbreviate the infinite race, so I went with another classic ability of Twine, which is text expansion/replacement:

It's kind of ugly to look at under the hood, but the outcome is an "additive infinity" where each click of the mouse (not unlike a step taken) adds another "half-way" to the text describing Zeno's progress toward the flag:

This is satisfyingly "literary", but I have to admit that I've abdicated my responsibilities as far as its infinity is concerned. I'm not sure how many "half-way"s it would take to eventually overrun the browser's or JavaScript's ability to display it, but there's presumably some kind of limit.

Eventually infinity comes up against reality.