Storytron news

The blog is dead, long live the bulletin board!

2006-05-10T14:28:00.000-07:00

We have a nice bulletin board system up now; you can find it by clicking on the phrase "bulletin board" on the links above. Henceforth, we'll be able to carry on our discussions there in a more organized fashion. I expect that we'll be abandoning this blog soon, replacing it with topics in the bulletin board.

Swat Version 0.52

2006-05-04T21:11:00.000-07:00

I have just uploaded Swat 0.52 to our website manager, Paulo. He's in a different time zone, but he'll get it up soon, probably before you read this. Here are the changes in this version:

1. A new menu, Swat, which contains the about box with the version and date, and a preferences pane that permits you to turn off the sounds.

2. A Redo function, but it doesn't work right, so it's disabled.

3. A scroll bar for the script pane.

4. Corrected a bug in which paste only works once. It arose because I failed to clone the object being pasted.

5. I attempted but failed to get working a feature that would preserve the state of the script tree under editing. Right now, if you close some of the operators, every time you edit something, they all open up again. Fortunately, this problem is partially ameliorated by the addition of the scroll bar to the script pane. I'll try to get this working.

6. A number of programming changes that make the code more robust.

See, I really do pay attention to your complaints and suggestions!

Immersive tutorial

2006-05-03T09:35:00.000-07:00

Comments, evaluations, and questions about the immersive tutorial go here.

Step-by-step tutorial

2006-05-03T09:34:00.000-07:00

Comments, evaluations, and questions about the step-by-step tutorial go here.

Questions about Swat

2006-05-03T09:33:00.000-07:00

Post your questions about Swat here and someday we might even be able to answer them!

bugs in swat

2006-05-03T08:56:00.000-07:00

Report bugs here. We know it's crawling with big, ugly bugs, but there's a good chance that you've found one of the three million species that we still haven't catalogued.

Swat is up!

2006-05-03T08:38:00.000-07:00

At last, at last, Swat is up for downloading! At last you can see what all our hype is about. Just click on the link above that says, "swat", and it will take you to the introductory page that gives you all the information you need. We'll be posting specific blog entries for your to post your comments; please make sure to put your comment in the correct place (assuming you can find one that fits -- if you can't, just put it where-ever seems best to you.) We are already looking for proper bulletin board software so we can keep all this stuff straight.

We're eagerly looking forward to your reactions!

He who praises me lavishly is my enemy; he who criticizes me correctly is my friend

2006-05-02T10:16:00.000-07:00

...or at least that's my recollection of the adage. I don't know who the volunteer lab rats were, but you really tore my tutorial apart, and you have my sincere gratitude for it. I have been writing the Storytronics documentation for months, without actual feedback from budding storybuilders outside Storytron. I had to rely on a mental image I created of a beginning storybuilder, a poor substitute for the real thing. The present version of the tutorial is much improved thanks to you. May you treat it as harshly.

Quantifier Quandary

2006-04-29T20:06:00.000-07:00

I'm writing this to talk my way through a tricky problem involving Quantifiers, the terms used in Deikto to express the magnitude of some trait or to modify a verb. From the outset, Quantifiers were designed to operate one a zero to five scale. The standard quantifiers were zero, tiny, small, medium, big, and max. However, we have shifted to a bipolar system in which most (but not all) values run from -1.0 to +1.0, with the values representing a kind of percentile distribution -- so that a value of 0.0 indicates the norm, with half of all plausible values above it and half below it, while +1.0 represents the highest plausible value, and -1.0 represents the lowest plausible value.

So what should the Quantifiers be? It now appears that we need many more Quantifiers, and they must be adapted to this probabilistic scale. I'd like to have 11 Quantifiers, but the problem is, English doesn't have that much resolution in its quantifier set. Here's a seven-step scale:

minimum, tiny, small, medium, big, huge, maximum

That's not much resolution. But going to a nine-step scale requires us to resort to some sloppy terms:

minimum, tiny, small, minor, medium, major, big, huge, maximum

It's possible to use compounds to get somewhat better results:

minimum, tiny, small, medium-small, medium, medium large, large, huge, maximum

But taking this all the way to an eleven-step system gets cumbersome:

minimum, super-tiny, tiny, small, medium-small, medium, medium-large, large, huge, super-huge, maximum

Moreover, we get into some issues with the semantic linearity of this scale. Here's how it would look as a table:

-1.0 to -0.9: minimum
-0.9 to -0.7 super-tiny
-0.7 to -0.5 tiny
-0.5 to -0.3 small
-0.3 to -0.1 medium-small
-0.1 to +0.1 medium
+0.1 to +0.3 medium large
+0.3 to +0.5 large
+0.5 to +0.7 huge
+0.7 to +0.9 super-huge
+0.9 to +1.0 maximum

Let me remind you, this system has to work for all variables in the system. Deikto is smart enough to be able to substitute different labels for quantifiers used on each word -- but that makes the job of designing these words even more difficult.

Right now I'm inclined to accept the nine-step system. The eleven-step system seems too clumsy.

Comments?

Chris on podcast

2006-04-28T10:26:00.000-07:00

Christy Dena, an Australian media research, has interviewed me and prepared a podcast of the interview. You can download the podcast at:

http://wrt.ucr.edu/wordpress/2006/04/24/wrt-interview-with-chris-crawford/

Comments and criticisms of my wild claims made in the interview are welcome here.

D&D: Deadlines and delays

2006-04-14T11:49:00.000-07:00

I had been planning for some weeks to release the first pre-alpha version of Swat on Tuesday the 11th. Perhaps you noticed that this did not happen. After nearly a week of smooth sailing during which no serious bugs cropped up, all of a sudden bugs began coming out of the woodwork in droves. I tried to stomp them one at a time, but eventually realized that there were too many. The problem lay in my poor design of the data structures behind the undo feature. I had to throw the entire system away and start all over. But then I realized that changing the undo feature would require me to change another data structure, which in turn mandated a change in the Dictionary file, which led to... well, you can see how these things go.

I have just finished the major redesign and have begun testing it. So far so good. If all goes well, we should be able to release the pre-alpha version in a few days. Jonathan has been writing up the tutorial, and so all the pieces are coming together. Keep your fingers crossed...

Programming is a waste of time

2006-04-04T13:53:00.000-07:00

Today I wasted two hours trying to fix a programming problem. The problem arose from the bad behavior of the Java JTree class: when you select and edit an item in the tree, it automatically deselects it. I wanted to be able to retain the selection, but Java blocked my every effort. I called up Dave Walker, our technical guy, and asked his help. We screwed around with the documentation and the program for nearly an hour, trying to get it to function properly. Finally, Dave hit upon the solution: accept the deselection. After all, only rarely will a storybuilder edit an operator in a script and then wish to edit it again; normally you alter an operator and then move on to another.

The moral of the story is that sometimes it's best not to try to find a programming solution.

Win some, lose some

2006-03-31T15:06:00.000-08:00

Last night I decided to bring up a minor feature I had been contemplating for a long time: the addition of audio feedback to Swat. This is nothing more than little beeps and boops that sound in response to your button clicks. I've long felt that these sounds are crucial to a good user interface, so I set to work. But gad, what a battle I faced! First there were problems getting a microphone to work with my old Mac, then recording the sounds, then storing them in a file format that my sound editor would recognize, then editing them, then getting them into a file format that Java would recognize (and, along the way, a great deal of time wasted trying to find beeps and boops on the Internet in a usable format.) After getting all my sound effects together, I added code to Swat that would play the sounds, and I was set.

Or so I thought. It turns out that the sound player I used was synchronous: it plays the sound and nothing else happens while it is playing the sound. This flabbergasted me. The old Mac 9 operating system supported asynchronous sounds (you start the sound playing, then proceed to other computations so that the sound plays while the interface is drawing the screen or waiting for input.) But Java, a threaded language that supports multiple threads, doesn't seem to be aware of asynchronous sounds. Oh, I'm sure that there are asynchronous sounds somewhere in the libraries. I'm just using the wrong sound library. "Oh!" some expert will say, "you're using the javax.sound.blech library. If you want to use asynchronous sounds, you have to use the javazzz.adgwed.yorch library. Didn't you know that?" Yeah, right.

So I reverted my code to what I had running Thursday and left it at that. To hell with sound, for now. We'll put it in when we can find somebody willing to wade knee-deep through the sewers of the Java libraries.

Trip Report

2006-03-25T13:16:00.000-08:00

On Monday, I spoke at the Serious Games Summit, part of the Game Developers Conference. I was on a panel discussing the incorporation of human characters into serious games. My thesis (presented in 8 minutes and 22 seconds), was that you can't have human interaction without language, and natural language required the inclusion of reality, and reality is too big to fit into a computer. Fortunately, it was possible to build toy languages to match the toy universes we create in software, and I had done just this with Deikto. I invited anybody with further interest to take a brochure; about a hundred people did just that.

Dave and I walked the Expo floor where we waded knee-deep through sewers of techie-schlock. We did, however, examine three technologies for face generation, which I shall refer to by the nationality of the vendor:

1. British: GeneHead, at http://www.genemation.com. Primarily for animation purposes. They have primitive controls for setting emotional expressions. The results look good.

2. Japanese: Motion Portrait. Their website has nothing to show, the product is not yet released. This was the most impressive of the three. They had a camera set up facing a blank background. They sit an attendee down in front of the camera, take a picture, feed it to the computer. The computer crunches for about a minute, and then they begin an animation in which the subject's face is animated with a variety of facial expressions. They do feature recognition automatically! Very impressive.

3. Russian. http://www.lifemi.com. I was not impressive by this group. Their facial models are rather doll-like in appearance.

Now, here is how we evaluate these options. Our objective is to deliver any specified face with any specified emotional expression to our player. If we have a hundred faces and a hundred emotional expressions, that's ten thousand different images -- too many to build by hand. So there are three basic ways to do this:

A. Software that allows us to create a face, and then manually set up an emotional expression on that face. This would require ten thousand separate editing actions on Paulo's part -- rather tedious. Right now, that's the best we've got.

B. Software that allows us to create a face, and separately create an emotional expression, and then apply that emotional expression to that face, and save the result. This would still require ten thousand actions on Paulo's part, but it's a MUCH simpler task, something we can build up to steadily. This is probably the best we can hope for at present.

C. Software that renders the face directly. We simply send it a message saying, "Draw Face #27 with Emotional Expression #83" and it renders the face automatically. This would be fabulous, but at present is not available. However, it is conceivable that one of these products might evolve into something capable of doing this.

Another important consideration is platform independence. All of these products are built for Windows machines and are written in C++. That means we can only use them inside our own studio. It's not a killer problem, but a definite inconvenience.

Thursday was an action-packed day. I drove to Santa Cruz and spoke to a class of 150 undergraduates in a course on games. It's always fun to mix it up with students.

In the afternoon I drove back to San Jose for the rant session on which I was speaking. While walking through the floor, I ran into a professor at a Portuguese university who wanted to invite me to speak at a conference he's setting up for September 26th-30th.

The rant session was illuminating. There were six of us. The first rant was wonderful -- a lady making fun of the sexist imagery that is so common in games. The second rant was disturbing. The ranter, a business guy, ranted about game designers who bring unrealistic financial expectations to the table, failing to understand that a game must sell enough copies to earn its costs. It's this kind of thinking that keeps the games industry mired in its rut. Any entertainment medium that insists that each and every product must be financially successful will surely stagnate. The wisdom that this big shot fails to understand is that a company must be strategically conservative and tactically liberal. You take chances on a wide range of products, and the one hit pays back all the misses.

Another speaker ranted against the people who rant about the lack of creativity in the industry. I am caricaturing his position when I say that he argued that innovation wasn't as important as execution -- but that was the basic direction of his comments. He said something very close to "it's more important to learn how to copy and adapt other people's ideas well than to create new ideas." Are you beginning to see why the games industry is so stagnant?

My rant, that there's nothing to rant about because the games industry is already brain-dead, went across OK. I hit pretty hard, saying that the panel was like a bunch of doctors gathered around the bedside of a brain-dead patient, arguing how to restore her to life and vivacity. I said that I preferred to walk down the corridor to the maternity ward, where there was a newborn infant called "interactive storytelling" that had a much brighter future. I ruffled some feathers and triggered some hostile questions. One guy in particular was pretty exercised, insisting loudly that there's really no difference between games and storytelling. There were also some people who fervently thanked me afterwards for having the courage to say what nobody else would say.

To market, to market...

2006-03-17T08:36:00.001-08:00

I'm off to the Game Developers Conference. I have a busy schedule during my four days in the Bay Area. I shall be speaking on two panels: one on Monday at 11:30 and the other on Thursday at 5:30. Irene is printing up a bunch of brochures, which I shall hand out at the conference. I'll also be speaking on Thursday afternoon at UC Santa Cruz. I have a meeting with Dr. Peter Jenniskens at the SETI Institute about the videotapes we took of the Leonid meteor storm of 1999. And Dave Walker and I have to resolve some very complicated technical issues about Swat and Storytron.

Meanwhile, the software is falling into shape. There are still a lot of gaps, but we have a basically functional Swat right now and Storytron does its core Deikto function correctly. I have not yet brought up the Engine (the third major component of the entire system), but the core routines are already separately operational and the task now is one of integration.

I had wanted to release an alpha Swat by this time, but it looks as if that won't happen for another couple of weeks. I want to get the dictionary in better shape before I release Swat.

To market, to market...

2006-03-17T08:36:00.000-08:00

On To Storytron

2006-03-10T13:20:00.000-08:00

Yesterday I wrapped up a workable version of Swat and shipped it out to the other members of the group; now it's their turn to poke around with it and give me feedback. This is not a major milestone; the really big milestone will come when I release Swat to the general public for alpha testing. Figure two to four weeks for that to happen.

In the meantime, I have begun work on Storytron, the program that acts as the interface between the player and the storyworld. Storytron's most significant feature is the presentation of the Deikto language. I have managed to get it running, but it doesn't do anything yet. Isn't that impressive?

Screen Layout

2006-03-01T17:44:00.000-08:00

We have now an image showing how a storytron screen layout could possibly look like. You can find it inside the storytron page in the overview section, or just by clicking here.

Additions to the Overview

2006-03-01T09:53:00.000-08:00

I've finished writing two new articles for the overview. The first deals with Verb-based dramatic interaction, and the other gives an example of the storybuilding process. The latter was plagiarized from Chris, but I'm not afraid to get sued, mainly because no judge will fail to declare me not guilty by reason of mental defect.

I had two reasons for writing these articles - first of all, these are topics that weren't very clear to me when I was a rookie, and I think that made my learning curve steeper. Second, I presume many of you are intrigued by Storytronics, but right now we don't have much material to offer you. These articles might help satiate your curiosity.

I hope the articles will be up within a day or two. You'll find them in the Storyworld portion of the overview. Remember, they're here for you. Please let me know if something is not helpful, informative, interesting, clear or what have you. Also feel free to tell me if there's anything you'd like to know about that isn't covered.

Doctoring the Docs

2006-02-28T17:00:00.000-08:00

When I got the job of writing the Storytronics overview, reference docs and tutorials, the first thing I did was ask myself: "Why do we need new docs?" The old Erasmatron docs were fine - after all, they taught me almost everything I know about Storytronics. I could just touch them up a little and voila!"

"However", my self replied, "it took you a godawful amount of adjusting, processing, assimilating and defining before you started to see what's what". My self was right - the learning process was one messy business. "This is because your intuition lead you in the wrong direction every step of the way…" he managed to say as my medication took effect and repressed him into the subconscious grotto where he belongs.

This is the lesson I've learned from my years as a Storytronics rookie - our docs need to make effective use of the readers' intuitions, not fight against them. So for the past two months I've been working on the "Storytronics up close" section of the docs, the core portion which explains all the clockwork, trying to make it intuitive. And let me tell you, she's a tough little beast. I've already written two versions which were technically complete, but they just weren't accessible enough.

The catch is that whatever explanation I choose has to present every part of Storytronics in an intuitive way, but it seems that making certain parts clear turns others obscure. That's no good - in Storytronics, either you get it all or you don't get it at all. I've just now settled down on a very good approach that makes the heavy hitters - Verbs, Plans, Events, Options, Inclinations and Roles very clear. The problem? I can't get OTerms (the Subject, DirObject and other constituents of Plans and Events) to fit nicely into this approach. She's giving me a good fight - there's blood all over the ceiling. But it's a matter of days before she succumbs.

Major problem

2006-02-28T15:29:00.000-08:00

I have just run head-on into a major problem. It arises from the various verbs that take secondary clauses: deal, request, advise, command, and threaten. I had intended these to be able to take variable secondary clauses, as in 'Joe deal Mary: Joe give Mary book; Mary kiss Joe.' ("Joe offers to give Mary the book if she'll kiss him.") The problem is the variability in both content and -- more importantly -- syntax of the secondary clauses. The first secondary clause takes the form Subject1 Verb1 DirObject1 Prop2, while the second takes the form Subject3 Verb3 DirObject3 Prop3 -- a different clause structure. Or how about this: "Joe deal Mary: Joe give Mary car; Mary steal book (from) Tom" ("Joe offers to give Mary the car if Mary will steal the book from Tom.") These are completely different clause structures.

Here's the problem: how's a poor storybuilder to specify these clause structures for the verb. What SentenceParts should be assigned to the verb 'deal'? It's pretty obvious that Subject1, Subject3, Verb1, and Verb3 are common to all, but what about Prop3? It's required only for that latter example; how can it be used for the first example?

Right now I am contemplating three possible solutions. In the first, I create some sort of special "clause builder" function that fills in the appropriate sentence parts. I find that a daunting proposition. The second idea is to restrict all these behavior-inducement verbs to just one or two secondary verbs. It would be trivial to make the secondary verbs 'give'; then all these verbs would address only the transfer of props. This solves the problem instantly, but presents a severe constraint on the storybuilder.

The third solution breaks up the process into two or even three steps. First, the Subject creates a single-verb sentence including one of the behavior-inducement verbs. When this Event executes, there's just one role and a set of options for what goes into the first secondary clause. Having chosen those, the next Event supplies the second secondary clause. Only upon completion of this third Event is the DirObject given the opportunity to respond. This approach might be workable but it's certainly clumsy.

Rumplety, rumplety, rumplety...

Busywork

2006-02-28T11:39:00.000-08:00

The last few days have been occupied with busywork. My worklist shows a dozen minor fixes to Swat: I deleted the NullOperator, because it didn't do anything, not even hold a place for an empty Operator. I got the right side menu panel resetting its items properly, got the loading of Event part requirements and audience values for verbs operating properly, and deleted the verb 'do anything' (it existed for theoretical purposes and I have now established that it will not be necessary.)

But I ran into a nasty little problem that will require some cogitation. Just now every verb has a reversed state. Thus, the verb 'sleep' has as its reverse value 'wake up', and 'accept request' reverses to 'reject request'. Sounds perfectly reasonable, doesn't it? But there's a problem: the consequences, emotional reactions, and roles of the reversed version of the verb are not necessarily mirror images of the consequences, emotional reactions, and roles of the direct verb. In some cases, they are reversed ('sleep' sets the value of Unconscious to true, and 'wake up' sets it to false), but in others they are merely negated, not reversed (for example, 'reject request' doesn't reverse the request, it only denies it.)

All my data structures are set up for the direct version of the verb, not both versions. So, should I simply get rid of the reversed versions and just add all the reversed versions as new verbs? Or should I try to preserve the reversal structure?

rumblety, rumblety, rumblety, rumblety...

That's the sound of cogitation in my creaky old mind.

Loading and Saving complete

2006-02-26T10:03:00.000-08:00

Yesterday I completed the code for loading and saving storyworlds. This code has cost us a great deal of trouble, as we wanted to build it right the first time. However, I have decided to just get it working for now, and we can go back and make it bulletproof later. For example, right now the storyworld is stored in eight different files. This is vulnerable to user abuse. If the user somehow goes into the files and swaps an old one with a newer one, it's possible that the code could get confused and screw up everything. This is poor programming practice; a good program protects the user from such mistakes. But for now, I shall ignore that vulnerability and press ahead with getting SWAT up and running.

So at last I return to the matter of adding the last features to SWAT. In all honesty, I'm not sure where to go at this point; there are lots of features to be added but I don't have a clear sense of priorities, so I'm going to spend some time just playing with SWAT, looking for the places that pinch. I'll build a priority list from there.

Comment one, comment all

2006-02-25T04:10:00.000-08:00

Now you don't have to be a blogger member to make comments anymore. Not only that, but now the comment page shows as a popup and the system language is back to english. Let me know if something does not work as it should.

The last two weeks

2006-02-24T13:15:00.000-08:00

For the first week since my return from Australia, I was busy splitting the original SWAT code into four separate parts: Storytron (the user interface for the player); Engine (calculates the development of the story); Swat (the editor for storybuilders); and Uber (containing all elements common to the other three parts). That was a lot of work, disentangling all the various bits and pieces, but now it's complete. For the last week, I have been completely rewriting the code that reads storyworlds, because my original code, although it worked just fine, is brittle and inelegant. With Dave's guidance, I was redesigning that code to make it more elegant and maintainable. When I got it done, it was much better than the original code: easy to read, highly maintainable, and elegant. There was just one small problem: it wouldn't work. It turns out that the Document structure in Java has some hidden features that torpedo my elegant code. After much hand-wringing, I decided to throw away all that work and revert to the previous code. Who cares if it's inelegant, hard to read, and impossible to maintain? That's not MY problem -- it's Dave's!

Ready to go!

2006-02-24T11:55:00.000-08:00

Today the Storytron website opens a brand new and working news page. Soon the whole Storytron team will be able to add posts and everybody else as many comments as they like, thanks to blogger!