Something New

Last night I took a look at a graphics programming system called Processing. It’s quite groovy. I had been dimly aware of it before, but I think I sort of rolled my eyes and muttered, “Just what I need — another software toy.” But I enjoy hobbyist-level computer programming, and this week I’ve been pondering what I might want to do with it. Processing offers some intriguing possibilities.

Csound is programming, but it’s not a very good fit for my own music composition preferences. Interactive fiction is programming, but I’ve become disenchanted with both the traditional IF delivery systems and the possibilities for meaningful storytelling within an interactive framework. Javascript running in a browser is an extraordinary resource, but what on Earth would I do with it?

Dave Phillips posted a link on the Csound mailing list to a new piece that he did using a system called AVSynthesis. I liked the piece — it’s not my style, but it evokes a definite mood. But when I gazed upon the web page for AVSynthesis, it was pretty clear I would never be able to fight my way through what might loosely be called the documentation.

Processing seems to be very well documented. It’s in active development, has a large user community, and does some spiffy things. Basically, you use it by writing code in Java. The code itself is easy to write and easy to understand. You can display and animate

Fuzzy

Surprisingly often, scientific researchers make what (eventually, perhaps after decades) turn out to be bad assumptions. They simplify a vexing problem in order to investigate it with the available tools, and then assume that what they’ve learned describes what happens in the real world, forgetting that they began by making a simplifying assumption.

Right now I’m reading Microcosm, a wonderful layman’s science book about the bacterium E. coli. You may not know much about E. coli, but they know quite a lot about you, at least in a vague, utilitarian way, because billions of them are living in your intestines right now.

E. coli has been quite extensively studied in the laboratory. It’s right up there with mice and fruit flies as one of the favorite organisms used in research. But research can’t be done in your intestines. On p. 51, the author (Carl Zimmer) says this:

“Out of the 4,288 genes scientists have identified in E. coli … only 303 appear to be essential for its growth in a laboratory. That does not mean the other 3,985 genes are all useless. Many help E. coli survive in the crowded ecosystem of the human gut, where a thousand species of microbes compete for food.”

But I’m not here today to meditate on intestinal parasites (though that’s a topic worth meditating on). I’m a lot more interested in what happens inside of E. coli. The little critter is a jam-packed protein circus! Large molecules are whizzing around carrying out amazingly intricate

Fun with Synthesizers

I have an embarrassing number of synthesizers on my hard drive. It’s embarrassing mainly because I never had to pay for them. Not because they’re pirated software, I hasten to add. These are legal NFR (not for resale) installations that I’ve acquired over the years by writing product reviews, mostly for Keyboard.

A few companies give reviewers time-limited licenses, so that after a few months the instrument will no longer load. Thus I can no longer use Arturia’s ARP 2600 V2, darn it all. But most companies evidently figure it’s in their best interest for me to be aware of their software, and the best way to insure that is to give me the opportunity to use it. This is a very sensible view. When Cakewalk released Z3ta 2, for instance, I was able to write a review comparing it intelligently to the original Z3ta, because I still have the original installed.

High on my go-to list are three u-he instruments (the oddly named company is owned by Urs Heckmann) — Zebra 2.5, ACE, and Diva. Diva is pretty much a CPU hog, so I don’t always reach for it first, but it’s just as good as the other two. The patching in ACE is decidedly weird, but it’s a whole lot deeper than it looks. Following on the heels of u-he is Spectrasonics, whose Omnisphere is just plain stunning. Camel Audio Alchemy is seriously amazing too, though perhaps not quite as intuitive to do sound design on.

The Native Instruments plug-ins are all stupidly good. Reaktor 5 heads the list, of course. It’s a dozen instruments and sample-triggering beatboxes all rolled into one. FM8 is extremely versatile. Massive I use less often, but it’s brilliant too. The one weakness of NI synths is

Dead Letter Office

Apparently nobody is very serious about wanting a solid, modern presentation for interactive fiction in web browsers. My recent blog posts on the subject, which I mentioned in the IF Forum, have met with a thunderous silence. As Adlai Stevenson once remarked, “I’m underwhelmed.”

I suspect that the main reason nobody is hot to tackle this issue and wrestle it to the ground is because nobody really gives much of a crap about interactive fiction in any form. I suspect that the observation I made the other day about Quest — that it’s caught in a negative feedback spiral because nobody who truly cares about producing high-quality work would mess with it — applies to the entire field, not just to Quest.

The 2011 IF Comp was won by a game called “Taco Fiction,” whose premise is that you’re a down-and-out, seriously broke guy. You can’t pay your rent or make your car payment, so you’ve decided that the solution to your problems is to mug a passing pedestrian and then rob an all-night taco joint at gunpoint. You haven’t actually loaded your revolver; you’re not quite that much of a desperado. In fact, trying to hold up a taco joint with an unloaded revolver is sort of doubly pathetic, isn’t it? But there we are. That was the most profoundly meaningful or best developed IF story of the year.

It’s pretty easy to see why any writer who wanted to produce serious fiction (and we’ll include humor in the “serious” category) would look at

Re: Quest

So far, the response has been underwhelming. I post a couple of thinking-out-loud pieces about how a 21st century interface and authoring system for interactive fiction might be developed. I drop links to those posts on the IF forum. And … nothing. On the forum itself, a couple of brief discussions ensue, but if there’s a groundswell of people saying, “Holy crap! You’re right!”, I blinked and missed it.

Alex Warren chimed in, noting that his Quest authoring system produces games that run in a Web browser and is extensively customizable. Alex is always keen to remind people about Quest, and very polite about it. So I had a quick look at Quest. I want to emphasize the word “quick,” because I may well have missed something important. But after an hour or so poking away at it, I’m moving on to look at other things.

The promise of Quest is, “You can write text adventures without programming!” And indeed, you can. To this end, the authoring system makes extensive use of mouse-clicking and little boxes where you enter snippets of this and that. This approach is bound to appeal to aspiring authors who are intimidated by programming — but if you have a bit of programming experience under your belt, having to grab the mouse over and over and over in order to create objects and define their behavior becomes fairly annoying.

This may be a matter of personal taste. If you like the mouse and hate typing, you may respond differently.

Within, or behind, the Quest authoring interface is a powerful scripting feature, with which you can customize your games.  But to get at the power, you have to

Look Through Telescope

Yesterday I summarized the problem: The existing delivery systems for interactive fiction (a.k.a. text adventure games) are mired in the 1980s. The early 1980s. Today I’d like to toss out a few ideas about what, ideally, ought to happen in order to bring the presentation of IF forward into the 21st century.

Broadly, there are two ways to move forward: either a massive extension of an existing authoring system, or an entirely new system. Both courses are fraught with difficulties; neither is a stroll in the park.

Let’s take a brief look at the characteristics such an authoring system would, ideally, have. The list below is not intended to be exhaustive — I may have left something out. It’s intended to serve as a starting point for discussion.

1. The games produced using the new system should be playable, and with an essentially identical appearance and functionality, in MacOS, Windows, Linux, and mobile platforms.
2. Convenience for the end user should be emphasized. The user should not have to download and install separate interpreter software or a self-contained app.
3. The authoring system itself should be available on all three desktop platforms, and without too great compromises in terms of utility. (No use of a command-line compiler should be required in one OS, for instance, if it’s not required in another.)
4. The author should have

Stuck in Lodi Again

First a little ancient history, then a rant, and then maybe a vision for the future.

It would have been the summer or fall of 1982, just about 30 years ago today. I had a Kaypro II, my very first computer. Single-sided 5-1/4″ floppy drives and 64kb of RAM. I bought it when the price came down to $1,295, if memory serves. Anyway, my friend Jon Sievert, who had been instrumental in convincing our boss to invest in Kaypros for the office, hung out in his free time and swapped cool software at Kaypro user meetings. This was a couple of years before copy-protected software, and programs were passed around like party favors. So one day Jon showed up at my house and said, “Here, let me make you a copy of this. You’re gonna love it.” And he was right. I did.

What he gave me was, of course, “Adventure.”

“Adventure,” and later, “Zork,” transformed the computer from a rather balky utilitarian device into a magic playground. You didn’t know what might happen.

Another 15 years would pass before I discovered Inform 6 and wrote my first text adventure game, “Not Just an Ordinary Ballerina,” but I knew from the very beginning that this was a creative field I would enjoy. Today I’ve written six or seven text games, using three different development systems, so I feel qualified to make a few observations.

The Kaypro ran the CP/M operating system, a precursor of MS-DOS. The user interface was a command prompt. It looked like this: > The screen had one color: green. There were no graphics, no mouse, no sound, and no notion of networking. When you wanted the computer to do something, you typed a command at the command prompt.

Fast-forward to 2012: Computers today have graphics and sound. Many of them have touch-screens, and they’re small enough to fit in a backpack, or even in your pocket. Worldwide networking is a fact of life.

Today there are several full-featured development systems with which to write and deploy text-based games. And yet, the games produced with these powerful tools still use the command prompt as their primary user interface. Does this seem

Undum & Vorple, Part III

What will interactive storytelling look like in the 21st century? Oops, we’re already 12 years into the 21st century. And yet the main authoring systems for interactive fiction still produce stories that rely on a computer user interface that was common and well understood in 1980.

Maybe it’s time for a paradigm shift. Do you suppose?

In the last couple of days I’ve glanced at a variety of new software tools designed for interactive storytelling, and/or stories created using said tools. Verdict, first, evidence afterward: Undum with Vorple is the clear winner.

Twine has a nice editing environment (it’s a bit like Quest), but Twine stories seem to want to clear the main display area and toss up entirely new text every time you click a link. Continuity of narrative in such a system is essentially zilch. Bad psychology — in essence, it’s even worse than what you get with an old-school command line interface.

The two ChoiceScript stories that I looked at were stunningly bad. It appears ChoiceScript is set up to collect the player’s characteristics based on what radio button the player clicks on in various menus of choices. Player characteristics — a relic of Dungeons & Dragons. Radio buttons — ugly.

Ren’Py might be a reasonable system if I were a graphic artist. I’m not. BloomEngine may be capable of delivering an effective browser-based story experience, but the game written by its creator neither looks attractive nor reads well; plus, the engine apparently relies on HTML 5 tags with a minimum of Javascript code, which seems a somewhat artificial limitation to me. If you’re going to build a race car, you don’t start with a bicycle frame.

John Ingold wrote a clickable story called “A Colder Light” using Inform 7 with some extensions. That development system may have some promise, but “A Colder Light” reads exactly like a 1980-era command line game (because that’s what it is). The sugar sprinkled on top is

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

Undum & Vorple

Technologies — there are so many! How do you pick and choose what you’ll use?

Last week I finished writing an interactive fiction game called “The White Bull.” This game has been entered in the 2012 Spring Thing competition, which will be open for players/voters on April 6. I’m pleased with the way the game came together, and I hope players will be too. I used the TADS 3.1 development system, which is very sophisticated. Almost intimidatingly so.

It has to be said, though: What TADS produces is, at the end of the day, 1980s-style text adventures. Granted, it has all sorts of advanced features, but the way you encounter the story as a player is, you type commands at the command prompt, exactly the way you probably did when you were playing Zork or Adventure on your Commodore-64. The same is true of Inform 7, a far more popular development system than TADS.

This user interface is very good for certain things, but not so good for others. The author can implement complex actions that are not immediately obvious to the player — for instance, something like ‘put the gerbil in the microwave’. This could be an effective puzzle, assuming you don’t mind a little cruelty to small animals. The player has to conceive of the action and then try it.

A user interface that relies on clickable links can’t easily be used to implement this type of puzzle. If the menu of allowed actions for the gerbil includes ‘put in microwave’, then