Bletchley Park, 1942. A component from the Bombe machine, used to decode intercepted German messages, has gone missing. One of the cryptographers is waiting to be interviewed, under direst suspicion. Is he stupid enough to have attempted treason? Or is he clever enough to get away?
Working on a new branching narrative project for inkle has crystallised in my head a problem I think I’ve often skirted around, but not ever pinned down before; and it’s a problem that sits right the heart of interactive narrative design.
The problem is this: if we’re tracking what the player chooses, and using that to alter how events play out, then how do we decide when to cause, and how do we decide when to affect?
There’s a conversation going on here – the reader says something, and the author says something back. The best interactive writing matches the author’s reply to the reader’s comment so perfectly it feels like there must be a human being inside the machine, typing furiously away.
But how do we decide who gets to hold the talking stick at any given moment?
A few weeks ago I posted up a nasty little perl script called the Kindliser, which turns a plain-text markup into ebook-ready HTML. Not such a big deal – it’s just a web-page with links – except that it also included support for tracking true/false values, which is impossible.
It does it by playing through every possible game the player might have, and writing them all out separately… which turned my first example game Flaws from a 40Kb sourcefile with 40 paragraphs of so and 4 true/false flags into a 600Kb HTML.
The other day I thought; I wonder how far I can push this thing?
This link appeared first as a comment, then as a tweet, and finally now as a blog-post, which is all back to front. But this is archaelogy, which works downwards.
The short version is: presenting Kingdom Without End by Shannon Cochran, a multi-choice input game from 2001 about archaeology, that is perhaps the best example of CYOA written in a parser-IF style, and not only that, it’s a damn fine piece of work too.
I’ve written a few times already about my new, novelette-length choice-based story built in Undum. The project began life as technical experiment – a quick attempt (a bit like this one) to “do” a text-game as a multiple choice adventure. The concept was simple: the game would have locations, and objects, but streamline the usual breadth of Interactive Fiction’s parser down to just the choices that mattered for the story.
It didn’t work and I had to change the design. But I learnt a lot in the process.
A few weeks ago I blogged about a Kindle ebook I’d produced and put on Amazon. It was a simple “click the links” CYOA story with one cunning twist: a limited ability to store information about what the player had done, and use that information to alter game text and game choices.
That ebook was built using a custom tool – that tool is now getting its version 1 release. While it needs some validation and error checking to help diagnose typos and simple coding mistakes, it is fully functional and capable of producing working CYOA ebooks.
Full documentation and download on the Kindliser page.
In the last few weeks I’ve been reading up on what kind of IF possibilities the Kindle opens up. The short answer is, “anything” – well, anything without too much animation. The Kindle is a computer like any other. But the more app your thing becomes, the less e-booky it feels. So what can the lowest-tech approach achieve?
I’m working on tidying up the tool I’ve written for making Undum game-files from a simple text format.
While I get that sorted, I thought I’d publish the single most useful other Undum thing I’ve got, which is an extra function to avoid writing in HTML. Following I7′s lead, I’ve called it “say”, rather than the Undum default, which is “write”.
I’ve been doing some more work with Undum (which I’m starting to link to off this blog so frequently I should really make a category tag for it. In fact, I will).