Undum & Vorple, Part II

No matter how attractive a technology may look, if it doesn’t do what you need it to do, it’s a doorstop.

After looking at Undum for a couple of days, I’ve concluded that it’s a doorstop. [Edit: Probably not true.] This saddens me, because it looks very enticing. As I detailed in my previous post, Undum is a way of delivering interactive stories in a web browser. It’s visually beautiful, requires no special knowledge of the reader, and can deliver stories to users on any platform that supports a modern browser — iPad, Linux, an old PC running Windows XP, whatever.

Using Undum, you create your story using Javascript and HTML 5. This is not precisely an author-friendly way of developing stories, but it’s manageable. These technologies are well understood and very powerful. If you want not only to create an interactive story but have it look good … folks, I hate to break it to you, but Inform, TADS, Quest, and the other authoring systems used for the past decade or so by authors of IF just ain’t gonna cut it. All of them display their stories in app interfaces that are, frankly, ugly. And not very user-configurable, either. So Undum would appear to be a super, super choice for the author who cares about giving the reader a gratifying experience.

But between the dream and the reality falls the shadow.

Web browsers are, very sensibly, designed in such a way that web pages can’t read files on your hard drive or write files to your hard drive. If such activities were allowed, the whole world of modern computing would collapse. Your personal computer would quickly become a hornet’s nest of malicious stuff. A web page can store a small piece of data (called a cookie) in a special folder, but only that page can read the cookie. Other restrictions quite likely apply.

As a result, Undum has no way to allow readers to store their progress through a story. Okay, technically it has one store point, which you can create using the Save button. The next time you load that Undum story, it will automatically fast-forward to the point where you saved the cookie. But you can’t save multiple store points within your story. [Edit: It turns out HTML 5 provides a facility called localStorage, which is plenty big enough to store lots of save points. Undum just hasn’t implemented a full save/restore feature, that’s all.]

This is a problem because Undum is designed specifically to produce interactive stories. In an interactive story, the reader gets to make choices. Shall I follow Barbara down to the beach, or shall I ignore Barbara and go back into the cabin? This choice may affect everything that happens throughout the rest of the story. Or it may not, but at the moment when you’re making the choice, you don’t know. Thus it is essential that you be able to save your position at the moment before you make the choice and return to it later if you decide you need to explore the other option.

An authoring system that can’t do this is utterly useless for presenting interactive stories of any complexity. And Undum can’t do it, because your web browser quite properly won’t let it. [Edit: This is not correct. The more I learn, the more I find that I don’t know.]

What’s needed, and needed desperately, is an IF authoring system that allows the author to put on a third hat. Not only will the author be a writer and a computer programmer, as at present, he or she will also be allowed to be a book designer. Typefaces, borders, background colors, width of sidebars — and the possibility of changing any of these elements dynamically in response to user input, which is precisely what Undum does — need to be placed under author control.

I tried to put this concept forward a couple of years ago in the IF authoring community, and got shot down. I would not dream for a moment of insulting the idea’s detractors by calling them old-school elitist whiners. We’ll just say that, surprisingly for people who are heavily involved in a creative activity, they seemed not to have a great deal of vision. Possibly the fact that I’ve spent most of my career in the publishing industry gives me a view of the aesthetics of page layout that is not widely shared by people who still think the Linux command line is a spiffy user interface. Or maybe the explanation lies elsewhere.

But let’s not get distracted by pop psychology. The main issue is this: It would be lovely to be able to write interactive stories that are engaging visually, require no arcane installation procedures, and present the reader with a modern click-or-tap user interface. Heck, there might even be a little money in it! Millions of people do read stories, you know. Yet as far as I’m aware, there is in 2012 no authoring system that can deliver the goods.

As much as I enjoy learning new software skills, I’m not really sure I want to devote a year of my life to becoming proficient as an iOS developer in order to bundle up interactive stories as iPad apps. But that may actually be my best option. Darn.

This entry was posted in fiction, Interactive Fiction, media, technology, writing. Bookmark the permalink.

7 Responses to Undum & Vorple, Part II

  1. Conrad Cook says:

    Ren’Py allows saving games, and the scripting language is not complicated.

    • midiguru says:

      I looked at that a year or two ago. Ren’Py seems to be designed specifically for producing graphic novels. Without disparaging that medium in any way (though I could do so if pressed), I will simply shrug and admit that I can’t draw. I’m a writer. Thus Ren’Py would, as far as I can see, be of no use to me.

  2. Conrad Cook says:

    So your complaint is that the technologies that allow saving, TADS and Inform, are ugly, whereas the technologies that allow prettification, Undum and Vorple, do not allow saving; and the one that allows both, Ren’Py, is too graphical for your purposes.

    You’re looking for something with the technical capability of TADS or Inform and the prettification of Vorple or Undum. Is that right?

    • midiguru says:

      Basically, yes. Realistically, there is not going to be a One True Technology that will do everything. Undum/Vorple has, in its current state, some quite stringent limitations with respect to game design, and its syntax for game development, being based entirely on Javascript, is nowhere near as friendly as the IF-specific languages. I’m prepared to deal with that, or at least prepared to roll up my sleeves and wrestle with it. But if readers can’t save their story state (I would use the word “bookmark” except that that has a browser-specific meaning), the user experience will be so catastrophically flawed that I have no reason to bother.

      On further research, I’ve found that HTML 5 has a feature called localStorage, which can almost certainly be used to build a game-save mechanism. It’s not without limitations of its own; specifically, saved games can’t be migrated from one browser to another, much less from one computer to another. But at least you should be able to tuck half a dozen saved games into localStorage and access them as needed.

      Unfortunately, I don’t know enough Javascript to be able to dive in and try using localStorage to see how well it works. But I will agitate to see if I can convince anyone to give me tips or write a few lines of code.

  3. Conrad Cook says:

    Does it have to be browersable?

    Honestly, it seems to me it must be easier to pretty up output from T3 or I7, but then I haven’t tried it. Can’t these be called from within a nice-looking window, or used in conjunction with CSS?

    Are they ugly because they’re unformatted, or because they’re formatted ugly?


    • midiguru says:

      This is a complex question. You can do a certain amount with either I7 or T3. (For an example of turbo-charged I7, check out “A Colder Light” (http://threeedgedsword.wordpress.com/2012/01/26/new-game-a-colder-light/), which you can play online. But then you hit the wall. Or rather, several different walls, depending on what you want to do.

      Dannii is looking at expanding the Parchment online player for Inform games to allow JS and CSS, but it’s not done yet. For one thing, Parchment won’t play Glulx games, and Zarf hasn’t yet finished the new Glulx specification … you see how messy things get?

      Both T3 and I7 look nice enough, considered as prettifications of a 1980 command-line computer terminal. But neither of them can take advantage of the capabilities that people today take for granted in Web browsing, because they’re NOT capable of using Javascript or CSS.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s