A development system is the constellation of programs that a developer uses to create things on the computer. Many development systems consist of a single program like Adobe Photoshop. You can do everything you want to a photograph with Photoshop. However Adobe also offers an entire genus of programs called the “Adobe Creative Suite” that includes programs for a number of related tasks. Similarly, web developers typically use a collection of programs for creating and managing their products.
The most complex development systems are those used by programmers. Two of the biggies here are the Microsoft Visual Studio and Eclipse, an open source system. Each of these includes a zooful of programs for managing the creation of a complex program.
Interactive fiction has a rich suite of development systems, such as Inform 7, Twine, Quest, ChoiceScript, and TADS. However, these are systems for interactive fiction, which in my judgement falls well short of interactive storytelling in terms of dramatic interaction between actors.
SpiritAI has an especially impressive system for use by games companies. It is complex and concomitantly powerful. However, I have not invested the many hours required to appreciate its operation, so I can offer scanty opinions based only on what I can glean from their website. It certainly looks ambitious. I do have qualms arising from their business model, which appears to be selling their technology as middleware to existing games companies. This is not the path to interactive storytelling, because games companies don’t want interactive storytelling. They make their money selling conventional games with the four standard challenges that have driven all games since the early 1980s: hand-eye coordination, resource management, puzzle solution, and spatial reasoning. They want to dress up their games with some apparent storytelling, but they certainly do not want to subordinate the primary challenges of their games to dramatic interaction.
Interactive storytelling technology can be built using standard programming languages, but the task is so complex that it requires its own development system. There have been a number of such systems developed over the years.
The SWAT development system
I built the SWAT system over the course of twenty years. Here I’ll explain some of the features of the SWAT system that are worthy of incorporation into a future interactive storytelling system.
Specific Editors
SWAT sported seven editors:
Most of these editors are fairly standard collections of checkboxes, radio buttons, text entry boxes, and sliders permitting the storyworld author to set the various parameters of the components of the storyworld. The most interesting editor is the Sappho script editor (which I have previously described), inside the Verb Editor.
Lizards
During the 1990s there was a fad among user interface designers for “Wizards”, features that would automatically handle complicated tasks for the user.
The idea is fundamentally flawed; if something is so complicated that it requires a wizard, it should not be there in the first place. The worst of these was “Clippy”, an intrusive and seldom-useful agent who would butt in at the most inopportune times offering help:
Clippy was easily the most derided feature in the history of user interfaces. Everybody hated Clippy. I think it had something to do with the smug grin he sported.
I was caught between the Charybdis of storyworld complexity and the Scylla of wizard-based systems, so I had to include some wizards. However, wizards were seldom smart enough to handle their assignments; many users found it easier to figure out how to solve the problem themselves than to navigate their way through the wizard. Recognizing this, I dubbed my own versions “Lizards” to indicate their relative stupidity. As the Storytron technology matured, my Lizards evolved into necessary supporting tools.
Storyteller Lizard is the most heavily used lizard; it allows the storyworld author to playtest the storyworld. It runs the storyworld in precisely the same way that a player would experience it. Indeed, the final product would be played on a standalone version of the Storyeller Lizard.
Log Lizard
Storyteller Lizard also fed data to Log Lizard, one of the best ideas in SWAT. After you playtested your storyworld in Storyteller Lizard, you could review every single step in the operation of the engine as it told the story. I’m not kidding: you could examine every single calculation made for every single decision that the engine made, right down to the smallest step. You might think that this would require the storage of multi-megabytes of data, but in fact only a small superstructure of data was required. This was done by means of some absolutely genius-level programming by Facundo Dominguez. Log Lizard recalculated every intermediate step of the calculations by consulting the existing scripts — but only as required by the storyworld author. Let’s walk through the process, using my storyworld “Balance of Power 21st Century”. Here’s the first view of Log Lizard after I played through a part of the storyworld:
Log Lizard presents the information in the most condensed form to squeeze as much information into a line as possible. Look at the line starting with “Page 19:” It shows the USA moving for ‘large’ sanctions in the United Nation against Iran for building a centrifuge facility. Further down, on Page 32, China votes against the sanctions motion. Suppose that we want to know why China so decided. To find out, we look at the Causal Event, where the decision was made. The Causal Event is presented at the very end of that line: it was the event on Page 30: “Fate calls the vote on sanctions”. China’s decision is inside that event, so let’s look inside it by clicking on the teensy-weensy “open sesame!” micro-icon on the left edge of that page:
I have highlighted the crucial step in yellow: China reacted to the calling of the vote. Let’s look inside that:
Once again I have highlighted the crucial step. China had just two options: to vote for the sanctions or to vote against them. The Desirability calculation for the first Option yielded a desirability of -0.5407673, while the Desirability for voting against the sanctions was 0.0. China chose the Option with the higher Desirability: voting against the sanctions. So the question is, why did China get such a negative value for the Desirability of voting for the sanctions? Let’s open up that decision by clicking on the micro-icon:
The Acceptable script yielded a value of ‘true’, so the Option was accceptable. The Desirable script looked at the BDifference of two BSum3 operators. Let’s look inside those:
This is obviously a complicated calculation, but note that I can check every single detail right down to the smallest one. Every step is plain to see.
This represents a huge leap forward in fixing and tuning software. Nowadays we use something called a “debugger”, which allows us to interrupt the operation of the program at a critical point in order to identify the source of a problem. But a debugger permits you only the option of catching a problem when it happens, not after the fact. You have to work backwards with a debugger. First you identify the most obvious place where the bug appears, and you set a “breakpoint” there. The program runs, and halts at the breakpoint. You examine all the relevant variables, and sure enough, one of the numbers is all wrong. But how did it get to be so wrong? You have to stop the program, remove the breakpoint, and put in a new breakpoint at the place where you think that the variable was miscalculated. If you’re right, you’ll find that something else caused the miscalculation, so you must now go another step backwards to find out why that something else was wrong. This process can take hours as you slowly trace the process backwards to the error. It’s similar to the process a detective uses to figure out who committed a crime: using the initial evidence at the scene of the crime, the detective works backwards by a slow, tedious process, eliminating all sorts of alternatives by careful collection of evidence, until at long last the detective isolates the culprit.
Log Lizard is like a video recording of everything that ever happened in the story, with clear markings of the causal factors for every single event. There’s no guesswork, no tedious examination of false leads. All leads are correct, and there’s no guesswork. This is the way development systems should work.
Rehearsal Lizard
This fellow looks great on paper, but in practice I didn’t use him much. He runs the storyworld ten times, using random numbers for player inputs, and accumulates statistics on how the storyworld develops. His accumulated statistics are quite impressive: he tells you what percentage of the time different options were chosen; you can jump from verb to verb, following the action in a graphical format. He’ll also point out every case in which Poison struck, and even tell you about two potential problems that arise with story worlds: Threadkillers and LoopyBoobies.
A Threadkiller is an Event that generates no subsequent Event. Usually this happens because the Options for that Event were all Poisoned. You need to know about Threadkillers so that you can insure that the story keeps going.
A LoopyBooby is a cycle of repetitive events. Joe punches Fred. Fred punches Joe. Joe punches Fred. Fred punches Joe. This can get boring. While it’s easy to prevent two-step LoopyBoobies like this example, you can generate more complex LoopyBoobies that involve many steps in the cycle. The LoopyBooby detector in Rehearsal Lizard will give you all the details you need to identify and prevent LoopyBoobies.
ComeFrom Lizard
It’s easy to see the possible consequences of an Event; they’re just the Options of the Roles of the Verb. But sometimes it’s nice to be able trace the causality backwards: what Events might lead to a particular outcome? ComeFrom Lizard will tell you:
Just click on any item on this list and it will beam you directly to that script. Shazam!
Role Search Lizard
This guy isn’t often needed, but when you do need him, you REALLY need him. We often use similar names for similar Roles. So we might have a Role called “Bookkeeper” that represents how a Bookkeeper might react to a particular situation. Rather than hunt through all the Verbs looking for one or more with a Role called “Bookkeeper”, you can just use Role Search Lizard to find all occurrences of that Role.
Operator Search Lizard
This is another lizard that you won’t need often, but who can be a lifesaver when you really do need him. All he does is provide a list of every Operator (a Sappho word) in all the scripts in the entire storyworld:
On the left is a list of all the Operators, and next to each one is the number of times it is used in the storyworld. If you click on one of the buttons, you’ll see a list of the scripts using that operator:
Again, if you click on any item on this list, you’ll be teleported to that script.
Notes Search Lizard will find any text phrase among the notes you attach to scripts. This is a good way to mark special situations. Lastly, Sniffy Lizard will check through all your scripts to make sure that everything is copacetic. While all scripts default to perfectly legal forms, sometimes we’ll start to make a change, get interrupted, and forget to complete the job. This leaves a hole in a script. Sniffy Lizard sniffs out all those little nits and gives you a list of them. Most of the time he comes back and says, “Nothing wrong!” This is another feature that should be built into every development system.
Conclusion
The key point here is not that SWAT is the greatest, most splendiferous act of genius in the history of the universe. The key point is that SWAT contains a number of good ideas that should be built into every development system. Most programmers will dismiss my claim with the correct observation that SWAT can do these things only because the entire design is built around some highly contrived constraints. I entirely agree that the many clever ideas built into SWAT could not be used on a general-purpose programming language. But storyworld authors shouldn’t be using general-purpose programming languages; they should be using systems built around THEIR needs, not the programmer’s preferences. Don’t settle for a programmer’s language; demand a language that fits YOUR needs.