Chris Crawford and Storytron

The latest issue of Dr. Dobb’s Journal arrived today, and contained an interview by Michael Swaine with game design legend Chris Crawford on the subject of his new venture. You can find the piece online at DDJ.com. If games and game design interest you, I advise reading the interview before continuing. I have admired Mr. Crawford since the mid-1980s, around the time of Balance of Power. This is a guy who wrote his first commercial computer game for Atari in 1979. Balance of Power was a certified 250k copy smash when it was released in 1984. Somewhere along the way he veered off from the game business and went in a different direction. His new gig is a company he cofounded called StoryTron. After reading the interview I went to the site and read everything there, including some of the message board content. I think I now better understand where and why he parted ways with the industry he helped to create. I’m not sure that, in the end, it will be a journey with a successful ending, or at least it might not be the kind of success he envisions. But I understand the attraction of what he is trying to do.

Mr. Crawford wants to build worlds. You can see that in the DDJ interview, and in an interview he gave to Gamasutra. You can see it even more clearly in this abstract from his book Chris Crawford on Game Design. In it he discusses the motivation and design behind Balance of Power. He was perhaps the first designer to catch the Creator bug, and begin to envision his simulations as believable alternates for reality. BoP began with a highly-detailed model of the world of international diplomacy, and although he had to pare it down to make it work, it was still one of the most complex simulations of its time. The urge is a powerful one. Virtually every designer of mechanisms dreams at one point or another of the concept of automata. Game designers tend to take the idea further than anyone else, because they can. An industrial engineer has to be satsified with creating the best individual robot. A game designer can create an entire virtual world and render it for the viewer.

If you’re inclined toward this kind of thing it is an incredibly enticing vision. And if, like most programmers, software designers, and logical thinkers, you are both a pattern seeker and a rule writer, a miner of fundamental formulae, then it’s very easy to be siezed by the notion that if you… can… just… get… the rules right you can simulate life! What a virtual world that would be! It would be a world populated by amazingly intelligent and interactive characters all going about their daily lives, and in which a million individual stories bloom and wither moment by moment, any one of which your character can dive into or not, as you desire. Yep, that is one hell of an idea for a simulation designer. It’s the Holy Grail of simulations.

Unfortunately, there’s always the chance it would be about as exciting as the Motor Vehicle department for the average consumer. The market for Mr. Crawford’s worlds was different back in the 1980s. Just about anyone who qualified to buy and play with one was an enthusiast, and might be easily taken by the same fascination that consumes the designer. And the designer in this case is very much consumed. There is a messianic quality about Mr. Crawford’s enthusiasm for what he has always called interactive storytelling, but which could now be more fittingly termed social simulation, that often takes him past where a less motivated person would rein in. For example, he refers to the StoryTron “actors” as “intelligent,” “emotional,” and “perceptive.” I’m going to go out on a limb here and say they are none of those things. We don’t know how to program those things. Nobody does.

What StoryTron has done is to spend a lot of time thinking about a model for social interaction, which they believe to be the basis of all “stories.” They have developed a type system (Actors, Roles, Verbs, Principles, Plans, Stages), operators to interact with the types, a scripting language called Deikto to handle input and output, and an engine which they call StoryTronics to run the whole thing. The basic model is that Actors execute Verbs in response to other Verbs, or in response to their own Plans. They choose possible Verbs based on their Roles, and the game matches interacting Actors and the Verbs they have executed according to Principles. I’m impressed by the neat elegance of the model and framework. It’s obviously been very well thought out. In the end, though, it is primarily a framework for walking a behavior tree based on heuristics, such as the evaluation of a given Actor’s response to a Verb based on the Actor’s role, and variables capturing attitude, standing, etc.

If the complexity of the tree, i.e. the number of possible stimuli and responses, is great enough, then you could certainly expect to see interesting emergent behaviors in such a system. If the global concepts of Principles and Roles actually give you enough high level control to allow the world to be defined and nudged into the appropriate behavior in a reasonable amount of time, then you might even be able to fashion interesting worlds within such a framework. Crawford is clearly aiming in this direction, given that all the world-building and programming takes place in a drag-n-drop paradigm where you connect Verbs, Actors, Roles, etc. I find the whole thing completely fascinating, and will definitely follow its development, and experiment with it. However, I find the concept itself more enticing than Crawford’s vision of it, and I suspect that vision might ultimately cause him to fail to get the most from the idea.

Ninety percent of what they are doing is creating a heuristic model of social interaction between characters. But Crawford doesn’t see it that way. For him the model is just a necessary component of an environment in which you can tell interactive stories. But of course he doesn’t mean “tell” at all. He expects designers to fashion worlds in which interesting stories can emerge. If you are scripting events and moving the reader (player?) along a plotline, you would seem to be off the reservation philosophically. The reader is supposed to create the stories by interacting with the world. This is far too tall an order for any current technology to deliver on. It is, in fact, not philosophically distinct from the idea that a billion monkeys typing would randomly produce Shakespeare. It’s a beautiful, wonderful notion that is just not happening any time soon. It requires algorithms that are not only intelligent, but are capable of being inspired to beauty. The best you can achieve is to embed many stories in the world, have the character stumble on them, and have them progress somewhat randomly to some set of possible conclusions. That much simulated disorder is manageable.

Not that there is no market for interesting simulations that run themselves. Look at Wil Wright’s success with The Sims. But that is exactly the point at which the real problem occurs. According to Crawford The Sims is a toy (and to be fair he says that Wright originated this view), and not interactive storytelling at all. StoryTron does not see itself as creating an interaction engine. That is not big enough. They are talking about creating an entire platform for these emergent stories. So I did not see any mention of a serious idea for separating the model from presentation. If I want to use StoryTronics to drive a population of NPCs in an RPG it doesn’t seem I will be able to do that. Similarly I did not see any idea for hooks to custom evaluators. If I want to code some more specialized AI for a given character, say a General who needs to evaluate global strategic options, it doesn’t seem I can do that either. That’s because this isn’t an engine. It’s a world in which writers, not programmers, can… well, not do what they usually do, which is to tell stories. Rather “story builders” will fashion worlds with rules that cause stories to emerge from the model.

Crawford specifically disavows the genre that he calls “branching narrative,” but I think this is as much a stretch as the idea that his Actors are intelligent or emotional. What he is creating is an engine that can handle a branching narrative with orders of magnitude more branching, and much subtler means of evaluating decision points. Such a fine-grained system is unlikely to produce anything that looks like or can be experienced as a story, unless the high level authoring tools are truly breakthrough technologies that allow the author to layer the story on top of the world. I don’t think that is where they are going, simply because of Crawford’s disdain for plot. He sees plot as the author telling the reader where to go and what to do. That’s absolutely true, but then, that is the whole nature of a story. Given a blank canvas, a brush, and paints the average viewer of fine art is unlikely to be able to create a Van Gogh, or even something he or she would appreciate. The average reader does not want to write their own story. The average gamer does not want a simulation constrained into a “story telling” interface. So where does StoryTronics fit in? I think it is flexible enough to be used for some really interesting things, and it may well find a profitable niche. But it will not be telling stories. Artists tell stories. Until we can make a program that is capable of being inspired as opposed to evaluating simple rules, computers do not.

A Basic Lack of BASIC

David Brin makes an interesting point in a recent article on Salon.com (apologies for the ‘click the banner’ hoop you have to jump through to get to the story). The author of such popular SF works as Startide Rising and The Postman is also a programmer, and he has a son who shows signs of being a programmer as well. Now various people can argue that we don’t have enough programmers, or that we do, or that the ones we have are too expensive. But I don’t think anyone will consider it a bad thing if a young person who is inclined toward the art finds the right tools to assist in the learning curve. The point Mr. Brin makes that somewhat surprised me is that we used to have the perfect tool, and now largely have it no more. That tool was BASIC.

The word ‘BASIC’ is an acronym that stands for Beginners All-purpose Symbolic Instruction Code. It was designed all the way back in 1963 by John Kemeny and Thomas Kurtz, both of Dartmouth. The point of it then was to provide a fast way for students new to programming to get up to speed on the fundamental concepts: stepwise execution; flow of control; instructions; operators; operands; variables; input/output; etc. It used to be that every IBM-compatible PC had BASIC burned into a ROM on the motherboard, and there were any number of more capable versions of it available on tape or 5.25″ diskette once those became common. Incidentally, two guys by the name of Gates and Allen got their start implementing BASIC for the Altair.

The attraction of BASIC was its austere simplicity, its interpreted execution model and resulting immediate feedback loop, and the wide range of things you could do with it, from record-oriented I/O and data processing to graphics and printed output. You could even read/write memory and ports directly. In fact, being the kind of kid who ripped apart perfectly functional devices to see how they worked, as soon as I got my hands on a PC compatible with BASIC I used peek and poke to mess with memory until I found the region that controlled the screen. That was probably the single most thrilling moment I’ve had as a programmer. Just typing load “mygame.bas” and seeing the cassette player come on knocked my socks off. Kids who are inclined toward programming just don’t have that kind of fast, easy access to a channel of control over the machine that so fascinates them. For me, BASIC was a natural launchpad to procedural BASIC, and then on to Pascal, Assembler, C, C++, Javascript, C#, and everything else I have done since.

Instead of BASIC, what young programmers today have access to is… what? Java? Visual Basic? Even though these languages share some of BASIC’s positive traits, i.e. garbage collection, interpreted or JIT-compiled execution models, weak typing, late binding, etc., they are far more complex, both in terms of their syntax and program structure, and the environmental complexity they have to deal with to make cool things like screen displays happen. Brin makes a good point when he relates that many math textbooks still include small algorithm examples in BASIC, that kids cannot run because nobody has a minimal BASIC interpreter at hand on their machine. Not that there aren’t decent BASIC interpreters available. The original inventors of the language still sell TrueBASIC, but it is $39 for the most minimal version. The whole point of BASIC was that it was just there. If you booted an IBM compatible with no O/S you got a BASIC interpreter. Brin believes, and I agree, that this had a lot to do with the U.S. dominance of computing and software development that lasted for decades.

I should note that there is a simple BASIC interpreter for the Mac. There are specialized BASICs for game development. There are actually a lot of different free BASIC variants for Linux, Windows, and DOS, but most of them seemed to be specializations for one purpose or another, and most were compilers that produce stand-alone executable binaries. This is understandable, if you don’t take into consideration the needs of the absolute beginner. The simplest variant I located, ScriptBasic, is a compiler that will at least let you type in a quick program and execute it, but I think when you lose the line-oriented interpreter of the original you lose quite a bit of the approachability. In the original you didn’t have to think about anything except the lines of code. There were no files, or directories, or configuration files, or compiler command line switches, or at least you didn’t need to deal with these things unless it was important.

Over the years I’ve thought often about some sort of beginner’s programming environment, mostly because it always seemed like a good commercial niche. My daydreams in this realm usually tended toward things like Logo and other such tinker-toy approaches. What Mr. Brin made me realize is that BASIC, the old-fashioned intepreted kind, is already perhaps the best model for a beginning programmer. You just dive in and start doing stuff, and that’s what ignites the creative juices. I’ll keep looking for a suitable interpreter, and if I find one I will make it available here in the site. It might even be fun to write one, and I think it would not be too hard in .Net. In any event, I have been a big fan of David Brin’s since reading the Uplift saga, and I am a bigger fan now that I know he cares about beginning programmers too.