Long-time readers of this space (both of you) will be aware of my ongoing fascination with interactive fiction. This is partly because hobbyist-level computer programming is fun, partly because designing an interactive fictional world is fun, and partly because, back in the ’80s, I got hooked on the immersive excitement of text adventure games.
I’ve written and released six or seven text adventures and used three different development systems. Like the first-generation programs in the ’80s, these are parser-based games. In a parser-based game, the reader/player types commands such as “get lamp” and the game will respond in some appropriate way. It may say, “You pick up the lamp” and add the lamp object to your inventory, or it may say, “You’re carrying too many things already.”
At the time when parser games were invented, all computer users knew how to type commands at the command prompt. That was how you copied and deleted files, started programs running, and anything else. The command prompt system was already a metaphor: The computer was pretending to be a teletype machine. In a real first-generation computer, the commands would have been stored on punch cards or rolls of paper tape. Nonetheless, the teletype metaphor was universally understood by computer users.
Not so much anymore. The command line interface (CLI) still exists in your desktop or laptop computer, but 99% of computer users never encounter it, and wouldn’t want to. For today’s computer users, the CLI is about as familiar as ancient Greek. It has been entirely replaced by point-and-click user interfaces. Also by tap-and-swipe, but for convenience we can consider those actions a subset of point-and-click.
That being the case, it’s no surprise that the design systems for writing parser-based text games are looking pretty old-fashioned. There’s not a lot of fresh development work going on: Inform 7 (the most popular system) hasn’t been updated in five years. Beyond that, the presentation layer — the manner in which an Inform or TADS game presents itself to the user — is not pretty. There are tools with which you can spiff it up a bit, and I won’t say it’s as bad as putting lipstick on a pig, but you can only do so much.
And then there’s Twine. I’ve looked at Twine a few times in years past, and backed away from it. The root of my discomfort is that I like having the world model that a parser-based game deploys. Also, there’s the mystery factor. In a decent parser game, you don’t know quite what commands will have an effect. You have to think. In a point-and-click game, either a command is visible as a highlighted link, or it doesn’t exist at all. There’s no mystery.
In spite of which, I’m now seeing Twine as the wave of the future. Not just because more than half of the entries in this year’s competition are Twine games or written in some similar system but because Twine is in active development — and just as important, because it gives authors ways to make their stories look good.
Writing a story in Twine, a story with branching links (what we call a choose-your-own-adventure or CYOA story), is dead easy. Digging deeper into Twine so as to design puzzles or take advantage of special effects — that’s not easy at all. But what the heck. Hobbyist-level computer programming is fun.
Twine is based directly on JavaScript, and that’s both the good news and the bad news. Your Twine story will run natively in pretty much any web browser, and you can do anything in your story that any web page can do — pop-up tool tips, embedded animations and audio, you name it. Your story can look as spiffy as the most glamorous web page, and your readers will be able to interact with it exactly as they already understand how to do.
If you want the good stuff, though, you’ll have to learn a little, or more than a little, about JavaScript and CSS.
The thing about desktop publishing — sorry to take so long to get around to the point of this little homily — is that Twine offers a viable alternative for indie authors. Some advantages, some disadvantages, it’s a mixed bag. But you might want to consider it.
Let’s call our typical indie author Jane Auteur. Jane writes a novel, or perhaps a shorter work, and then wonders what to do with it. There are dozens or hundreds of web-based services that will help Jane get her novel formatted and up on Amazon as a real e-book and paperback. Jane will, however, have to pay handsomely for these services. Instead, she can roll up her sleeves and do the file formatting herself. That will save money, but there are various technological hoops to jump through.
At the end of the day, Jane will have a book that she’ll have to promote. It will be accessible to people who have an e-reader, or who are willing to wait for the paperback to arrive. She may make a few bucks on sales. Okay, that’s one option.
Instead, she could download Twine (which is free), jump through a few different technological hoops (if she chooses), and end up with an html file that anybody in the world can read in their web browser. One downside is that there’s no easy way to make money selling html files. Also, she’ll still need a way to host the html on a web server somewhere. On the plus side, it’s enormously easier to make a web page look good, with color and graphics and maybe some background audio of gentle rainfall, than to make an e-book look good. And a print book with an animated purple background? Don’t even think about it.
Publishing to browser may be the wave of the future. E-readers like the Kindle feel a bit like a Sony Walkman to me — thrilling technology that will obsolete itself before too very long.
At the moment, good tutorial information on how to use Twine is a bit scattered and very incomplete. But that may change. The tutorials on JavaScript are very good. Twine’s development environment is sort of maybe okay, I guess. It’s not really good, but it’s simple and easy to use.
The issue that I’m still puzzling over is how to write branching or point-and-click stories in a way that produces a convincing narrative. But that’s a topic for another time.
Footnote 1: After poking around for a while, I managed to find a couple of decent Twine tutorials and a cookbook (not the official Twine cookbook) with some spiffy code. I’m now able to do text and background colors, add a bottom border with some text, and a few other things. Most of it is to do with CSS (the story stylesheet). It will take a little longer to get a handle on things that will behave a certain way when you click on them. The IF Forum is a great place to post Twine questions, by the way. A couple of power users were very helpful today.
Footnote 2: If you write your fiction directly in the Twine text editor, you’ll get straight-up quotes and apostrophes, not curly ones. This is ugly. What’s worse, if you should import a story from a real word processor (which will probably have automatically converted to curly quotes), when you add new text directly in Twine you’ll end up with a mishmash of straight and curly quotes. This is a nasty problem, and I don’t have a quick fix.
Jim Aikin's Oblong Blob 