Tuesday, February 28, 2006

Doctoring the Docs

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

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...


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.

Sunday, February 26, 2006

Loading and Saving complete

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.

Saturday, February 25, 2006

Comment one, comment all

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.

Friday, February 24, 2006

The last two weeks

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!

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!