The writing process.

It occurred to me that I haven't explicitly stated the process I use for creating content for my chat-bots. I have written about the process in multiple posts but in this one I'll condense all of that material.

• I decide on a topic that needs to be covered. Sometimes the topics are a matter of 'imperatives' (things the chat-bots should or must know e.g. What is the topic of Atomic's PhD?). At other times they are 'descriptives' (topics that say something about their character and personality). And on other occasions they are topics suggested or attempted by the audience. 

• Pandorabots offers a service called Pandorawriter  that converts dialog to AIML categories (http://bandore.pandorabots.com/botmaster/en/pandorawriter). In that on-line interface I write a 'traditional' script - each character gets a line in turn. This script always starts with Romeo delivering the topic. Usually this line is just the topic rather than a complete sentence or thought. For example, I'd start with 'sex' rather than 'Do you remember having sex?'

• The script develops over 26 lines. Each line is a single sentence - this is one of the constraints of the Pandorawriter. This is actually a very positive constraint. It does mean that I have to use some non-standard punctuation and comma splices are common and you'll see a lot of dashes in the dialogue. However, on the upside it forces a consistency, economy and brevity on the tone of their language.

• Originally I had decided on 20 lines of dialogue for each script. However, after several months of writing I found that I kept blowing through this self-imposed upper limit. It was when I was writing a file called 'swearing_option2' that I knew I had to increase the limit. In this script Atomic and Romeo play out a Rosencrantz and Guildenstern like game of 'tennis' where Romeo alphabetically lists all the body parts that Atomic no longer has. It ends with Atomic admitting defeat but Romeo adds one more shot.

 Romeo - Just one more - no zygomaticus.
 Atomic -  Hey, I smile on the inside.

This is a '5% Gag', only five percent of the audience will get it, but those that do will really appreciate it. The zygomaticus is the cheek muscle that allows us to smile.

•  The scripts are now 26 lines long. I try to use some structural device that will bring the script to a conclusion that is hinted at by the topic or the introductory remarks. Circular closure of a three-part structure. However, there are times when a character will simply have a bit of a rant - a pet peeve will be allowed out of the box.

•  Once the script is written I covert it AIML. This file I save with the Atomic prefix e.g Atomic_swearing_option2.aiml. Then I delete the first line of the script and convert the file again, this time with the Romeo prefix e.g. Romeo_swearing_option2.aiml. This simple strategy is really useful. Deleting the first line changes the order of the lines in the AIML categories - pattern becomes template and vice versa. Therefore, output from Atomic becomes input for Romeo and vice versa for the entire script. The Romeo file contains an empty template tag at the end that I manually fill - usually with a bland, generic phrase. Any other editing is done in a program called TextWrangler - it's free and very good at dealing with the XML structure of AIML.

• Each file is then uploaded to the appropriate chat-bot. It only took one mistake in the uploading before I decided to strictly conform to my file naming convention that includes the chat-bot's name.

• This is when the fun begins. I start rehearsing with the chat-bots through the Flash interface. I watch the performance. Occasionally, and its happening more often the more scripts I write, the output from one bot will trigger a different topic in the other. Sometimes this is joyful serendipity - other times it's just rubbish. I go back to the AIML files, adjust the content for both halves of the script, upload again - and rehearse again.
• The final step is designed to allow Atomic to start the appropriate script from a multitude of possible inputs. Anything that contains the topic should fire the script. So ''Do you remember having sex?' and 'Do you have sex?' should fire the sex script. However, there are scripts that cover 'sex and food' and 'sex and sport' which should not be triggered by a question about sex alone. All of this is controlled by a file called 'Atomic_srai-01.aiml'. This I'll talk about in another post because it is too big a topic for here.

A little post-modern gesture

I've added another response for Romeo to use when Atomic says "I have no answer for that". Romeo suggests that the people watching the show could contribute topics. Initially Atomic is offended - he prides himself on his knowledge. However, the thought of Romeo adding things to his knowledge base so disturbs him that he addresses the audience directly and pleads for people to leave comments.

The other little element I worked on today is based on jokes. Atomic can now respond to lines like "Tell me a joke" or "Do you know any jokes?". However, I wanted to make sure that the insult, "You're a joke" was handled differently. I created a short five line sketch that captures the intent of the line and then subverts it by having Romeo suggest that maybe the audience was actually asking for a joke. This, using the recursion tag in AIML, then starts the generic 'jokes' sketch.

The interesting moment in this is that I have already had Romeo use the line - "You're a joke" in the generic 'jokes' sketch. As I have a particular turn of phrase so to do Atomic and Romeo. This sketch now has a circular structure that emerged from the process. I had forgotten that Romeo used this expression - this truly was an unplanned moment and the sketch is all the better for it.

The duck-rabbit again...

Of late I've been working on my exegesis. There have been some interesting posts on the International Society for Humor Studies (ISHS) bulletin board on the topic of incongruity and resolution. This has been troubling me for some time. Resolution sounds so final, once a joke is resolved its affect is completely discharged. On a second hearing the less funny or  not funny at all. This does not seem to capture the social nature of the process. Jimmy Carr in the book he wrote with Lucy Greaves tells of the comedian Peter Kay he tells the oldest of old jokes as a way of interacting with the audience (p. 137).

To use a visual example of incongruity and resolution, Wittgenstein's duck-rabbit encapsulates two incongruous images into one visual statement. In his Philosophical investigations I believe he argued that the viewer can resolve the image to represent the image of a duck or to represent the image of a rabbit. Also, the viewer can examine the image itself purely as a shape that represents the form described by the tone and weight of the lines.

For me the truly interesting idea is that the image resists final and complete resolution. It is possible and, to a degree, desirable to flip between the two (three?) versions of the image. Just because the image has been resolved as a duck, for example, this does not remove or delete the possibility of the rabbit. Also, the third version (neither duck or rabbit) is a view of structure. This is akin to the linguistic structure of a joke - it is itself anything but funny.

Maybe this helps to explain why old jokes, ones we've heard tens if not hundreds of times before, still have an effect. Sure it may not be the same as the original / initial effect but it is an effect nonetheless. It also suggests that the structure of the joke is necessary but not sufficient to generate the affect of humour.

I agree that the duck-rabbit is not particularly funny. The version Wittgenstein used was the simplest of line drawings as opposed to the more 'realistic' renderings - Margaret Rose uses one of these more detailed versions.  The simple line drawing does away with all the extraneous detail. I do find the wistful upward gaze of the rabbit charming - it has a Luenig-like innocence.

As a metaphor for incongruity and humour I am still drawn to the duck-rabbit (please ignore the possible pun). One of the three viewings of the drawing is purely structural - the drawing as a shape representing neither the duck or the rabbit. That for me is a powerful metaphor for structuralist approaches to humour. The structure can tell us the HOW of humour but it is not in itself humorous. This is 'dissecting the frog' to use another famous animal analogy. Likewise, the removal of extraneous detail is akin to the need for brevity or economy in humour.

As you pointed out the big WHY question is much harder to get at. I would argue that the text alone, regardless of the method of dissection, can not provide that answer for us. The answer to the WHY question (if there even is a single answer) must then exist somewhere in the interplay of the psychological, social and cultural elements of a system that encapsulates both production and reception.

Version 13 - update based on comments

This latest version includes the following updates / improvements:

• I had a conversation with a colleague, Harry Criticos, about the chat-bots. He said that he found the delivery of the text too quick - that the text would move up the screen before he had time to read it. Harry has had a long career in radio and has done a lot of voice work. If the text is being delivered too fast for a professional reader, that is, someone who reads and presents text for a living, then it will be far too fast for most people. I tend not to notice how fast it is going as I know what to expect. In this version I've slowed down the delivery of the dialogue from the server and the text that is held in the Flash interface. My ball park figure that people read at about 52 milliseconds per character (roughly 180 words per minute for screen-based media) is a little off. This version allows 65 milliseconds per character (roughly 150 words per minute) plus another 200 millisecond of generic delay. This is a buffer that stops short lines (say 10 characters / two words or less) being piled on top of a previous short line.
• Version 10 of the interface broke through the 100KB file size barrier. Since then I've been worrying about the need for a pre-loader. I may be showing my age here but I've long maintained that any file delivered via the Internet that is over 100KB is a 'large' file. Of course I realize that with the advent of broadband speeds a 100KB file is not actually big at all. However, imposing an upper limit also imposes a particular kind of discipline in my use of Flash and other web technologies. In this case I thought it was important to develop a pre-loader. However, doing this took quite a bit of research. The interface uses an Actionscript class stored in a . as file. The class declares and defines elements on the stage. Here's the problem - a  preloader want to load all the attributes including the class file, however the class file contains references to objects that do not yet exist. This took a while to sort out - but I finally got there.