TL;DR — SWAT v1.1 released, new “old” storyworld repository available, Storytron Patreon created
SWAT version 1.1
In the five months since the StoryWorld Authoring Toolkit (SWAT) was open sourced there has been progress. Version 1.1 of the software is available here with these new features:
The SWAT menus have been reorganized to make them conform to the File, Edit, etc. application standards that everyone is familiar with.
File Open Menu Item
This one is a personal favorite of mine.
Selecting Open will allow you to select and load an existing storyworld into the editor. Previously, to open a new storyworld you had to quit and restart SWAT.
File New Menu Item
Another personal favorite.
To create a new storyworld with previous versions of SWAT you had to open up the BareBones storyworld and save it with a new name.
With version 1.1 you select New from the File menu to create a new storyworld. In the subsequent dialog you provide a new name for your storyworld and a directory location where you want it to be created.
Selecting Save will create a copy of a starter storyworld in the directory you selected with the name you provided.
Be careful though, you can overwrite an existing storyworld if it doesn’t have a corresponding resources folder (which is automatically named “<storyworld_name>_rsc.”
Edit Menu Change
If you look closely at the bottom of the Edit menu you’ll notice a checkbox menu item called Sounds On. Selecting the menu item will select and deselect the menu’s checkbox, enabling or disabling the SWAT sound effects (the menu item is selected by default).
This menu item replaces the original SWAT > Sounds… dialog box and removes a bit of unnecessary code (always a good thing).
A toolbar has been added underneath the menu bar and some commonly used command buttons have been added (there’s room for plenty more).
From left to right the toolbar buttons are New, Open, and Save. Their functions mirror their menu counterparts.
I know what some of you are probably thinking — some of these enhancements are nothing to shout about and they probably should have been in the application back in the 2000’s. If you’re thinking that you are absolutely correct.
What I think is important about them is what they represent. First, they’re features that I personally wished were included in SWAT back in 2010 (maybe not the toolbar, that was Chris Conley’s idea) and, second, because of open source, I was able to scratch my own personal itch and add them to the code, something I wouldn’t have been able to do when SWAT was closed sourced. And implementing them was an excellent introduction to the inner workings of Eclipse, Java, and the SWAT source code.
Anyone interested in enhancing SWAT can do the same thing — fork the repository, make their changes, and then submit a pull request back to the original repository. I hope you’ll take a crack at it.
There were some enhancements that I was thinking of doing for this release but I decided not to do them
I thought that the 2000’s version of SWAT had a checkbox in the Actors editor that let you select which character was played by the user. However, no screenshot or documentation I could find confirmed that assumption.
I emailed Chris Crawford to see if he could shed any light on that question and he wrote back that at one time it was possible to allow any actor to be the protagonist but he removed that option because it added unnecessary complexity (a text search in the engine code for “protagonist” finds a number of commented out references). When he removed that option he wasn’t 100% sure.
Based on Chris’ information and my inability to determine where this mysterious Protagonist checkbox used to be located in the Actors editor, I deferred re-enabling this feature until a later date (if at all).
Based on my review of the source code I believe that the first actor in the Actors editor list is hard-coded to be the protagonist.
Editors as Tabs
Chris Conley suggested that the Editors menu be removed and the individual editors appear as tabs underneath the toolbar.
Because of my unfamiliarity with the Java Swing library I deferred this feature until later.
I think tabs could be useful. Besides providing a little more visibility into the which editors are available and which editor is currently active, the tabs themselves might be able to host controls that allow an author to switch between various editor “views.”
For example, suppose you’re in the Verb editor. You’ve added a bunch of new verbs and hooked them into your existing verb web and you want to make sure you haven’t missed any connections or you just want to get a high level view of how things connect. Imagine if there a button in the actual tab itself that allowed you to switch to this type of view.
Using it you could quickly switch to this view and drill down into verb details (you can read more about it in the Visual Verb Web View section below).
There’s a new storyworlds repository containing all of the storyworlds that I could find developed by various authors between 2009–2017.
A majority of the storyworlds that were originally found in the /swat/res/data/ directory have been moved to this repository. Only a copy of ChitChat can be found in it’s original location (BareBones was removed since you can now create a new storyworld easily using the File > New menu item).
There’s a list of each storyworld and a brief description for some of them in the repository’s ReadMe. Most of them are just brief “sketches” and some don’t run correctly but they’ll give you a good picture of what was going on in Storytron’s infancy.
I also went through every storyworld and replaced all occurrences of the Protagonist operator with the first actor in the Actor list, i.e. the protagonist Actor.
I’ve created a Patreon page to support future Storytron Org development. Though right now our financial needs are modest I could use some help to defray future expenses and support future efforts.
There are two tiers.
- $2 Supporter — You get these rewards without pledging but your contribution is appreciated and will help us defray expenses.
- $4 Influencer — If you want to join the conversation to help determine the direction that Storytron takes then this is the tier for you.
Details about each tier’s rewards can be found on the Patreon page.
There are two reasons why I created a Patreon for Storytron.
First, while I’m happy (honored?) to spend my time reviewing and making changes to the source code and I’m willing to lay out a bit of money for a URL and an email address, I’m not willing to fund future Storytron plans out of my own pocket. $2 a month, $24 a year, puts $19.02 in the Storytron account for future efforts (the Patreon page lists some of them).
Second, I’ve seen the Storytron community ebb and flow over the years. Everyone’s got their opinions but few are willing to put in the time and do the work.
I want committed people to help determine Storytron’s future direction. But how do you determine commitment when everyone feels that they should be able to state their opinion online and have it given equal weight? Nowadays everyone feels they should get a trophy for participation.
Not with Storytron. You can post your thoughts or opinions to the Interactive Storytelling or Storytron groups on Facebook or tweet to our StorytronOrg Twitter account. Congratulations, you’re involved but you’re not committed.
Commitment is forking the repository, making some code changes, and submitting a pull request (it might not get accepted but it will get code reviewed and commented upon). Commitment is signing up to write some documentation.
What’s that, don’t know Java, don’t have the time to fiddle with code, or can’t write. Well you can still download the code, run SWAT and try to create a storyworld or two. Based on your experiences and background you may have some valid suggestions. Commit to $4 a month, $48 a year ($41.04 to Storytron) and you’ll be able to have conversations about the future of Storytron with equally committed people.
To bastardize Thoreau: “There are nine hundred and ninety-nine patrons of Storytron to one Storytron man.”
That’s it. You may agree or disagree, but that’s how the storyworld works.
As of this writing two patrons have subscribed at the $2 level and two patrons have subscribed at the $4 level (we’ve also got four followers).
Thanks in advance for those of you who will decide to contribute this holiday season.
New Storytron Publication
I’ve created a new Storytron publication on Medium and moved all the stories that were in the old StoryCalc publication to this new publication (the old publication has been deleted so update your links).
The best way to follow future Storytron developments is to keep an eye on the this publication, the Storytron Patreon, or the Storytron Google Group (we’ve also been added to the PlanetIF aggregator so if you’re already subscribed to that you’ll know what we’re up to.
What about social media you say? On Facebook there are two groups — one specifically for Storytron and another for Interactive Storytelling in general. We’ve also got a StorytronOrg Twitter account. Anything posted to those three areas will probably get seen and read and Liked.
Future Development Roadmap
For the foreseeable future the Java version of SWAT will be the primary development platform for Storytronics storyworlds. However, I don’t think it will ever be the way that storyworlds are delivered to reader/gamers.
However the existing tools need some refinement. And I also envision moving some of the current analysis tools into the Storyteller for the runtime debugging of storyworlds.
I also have plans to integrate copies of the Face Editor and Encounter Editor code that Chris Crawford send me into SWAT.
Back in 2009 I wrote this on the original Storytron bulletin board in response to the post “Should Storytron Attempt to Adapt to Games?”
“As much as I believe in the potential of the Storytron technology, I don’t think it will achieve a significant market presence in it’s current incarnation. Storytron’s strength, it’s focus on flexible interpersonal interaction through the Deikto interface, is adversely offset by its primitive output.
While Storytron ‘listens’ and ‘thinks’ quite well I don’t think it ‘speaks’ as well as it could. Emoticubes were a start, dynamic emoticubes are a direction, but to truly engage and move readers (players?), Storytron needs the ability to express itself procedurally in the most appropriate media whether it’s words, images, sounds, animation, or video. Implementing this might dilute the Sapir-Whorf nature of Storytron but I think the potential benefits outweigh the consequences.
Other people like Victor Didra are thinking the same thing today
“One thing I think that would be highly beneficial is compartmentalization. SWAT should have hooks that other engines can use to find out what emotions the actors should be showing, but no or only a basic graphics system itself.
My ideal application of it as an example; I would love to use it with Unity. If it worked with UE4 I’m sure there would be developers that would pick up and use it there as well. Both of these would provide far superior graphics potential, even if the storyworld creator wanted to keep them low rez.
I know there is a thought that SWAT should do everything within itself but I think that’s a mistake. Let the application do what it is good at, and make it accessible to other applications that are good at what they are good at.”
To do this we probably need to apply the Model-View-Controller (MVC) pattern to the existing code, making it so the engine, i.e. Controller, can run within SWAT and also on the platforms where we want to “play” our storyworlds (this is not a new concept, Infocom did it with their Z-Machine back in the 1980’s and 90’s).
In this type of type of implementation, the storyworld file, created using SWAT, is the Model, the engine is the Controller, and the View could be any game framework/platform the developer wants to release on (providing the controller can run on that platform).
While I’m familiar with C#/Mono Kotlin has the benefit of being able to interoperate with Java.
The entire engine code could be re-written in Kotlin and work within the original SWAT Java ecosystem.
This Kotlin engine code could be released as a community StoryCalc engine, allowing us to maximize our investment and only have one engine code base to maintain.
Other Possible Enhancements
Here are some of the other enhancements that we’ll be talking about on the Storytron Google Group.
Should we limit the personality model to five traits for now?
Chris Crawford has narrowed down a good starting personality model to three traits after years of work:
I think it’s a good starting point. In order to keep things simple and manageable for novice storyworld builders should we limit the personality model to five traits total, the three listed above (which could not be removed or have their names edited) and two that the storyworld author could create, tailored towards their specific storyworld’s needs?
I’ve always thought that constraints foster creativity and I think the limitation of five traits for now would force storyworld authors to be rigorous in their creation of their personality model and prevent things from getting out of hand.
“Some storyworld authors are tempted to build a huge personality model containing every possible trait they can imagine. Whenever a design problem arises, they throw a new personality trait into their model — and poof! The problem is gone. This ultimately comes back to bite them, because as they add more and more personality traits, it becomes more and more difficult to determine which traits should be applied in any given situation. A good personality model must be small enough to keep inside your head at all times. If you have to consult it every time you use it, then you’ve made it too big.” Chris Crawford on Interactive Storytelling, 2nd edition, page 194
Talking To Character Attributes
When I was creating Siboot for Storytron I wanted to know two things related to actors on a stage
Which actors weren’t in conversation with other actors and available to be greeted by me.
Which actor I had greeted so I knew who I was currently having a one-on-one conversation with.
Because of SWAT limitations I had to resort to a hack, creating TalkingTo traits for each character in the storyworld’s personality model — TalkingToVetvel, TalkingToKendra, TalkingToSkordokott, etc. I also had to create numerous SetActor consequences in the “greet” verb to handle greetings and responses to greetings. It was a kludge — it worked, but it wouldn’t have scaled.
Talking to other actor is a major part of a Storytronics storyworld so what if, as a new actor is added to the storyworld, a new Talking_To_That_Actor attribute is added to every other actor’s state, and vice versa? This would cut down on a lot of the manual work that I had to do with Siboot.
Replace Swing UI with JavaFX?
JavaFX is the graphical user interface library that was designed to replace Swing, the library currently used to create SWAT’s windows, controls, and menus.
There appears to be a lot of boilerplate code that had to be written to implement the SWAT user interface. I don’t know if moving to JavaFX would reduce the amount of code that had to be written or if just refactoring the existing code would accomplish the same thing.
Some of the existing editors could use some work.
Visual Relationship Editor
The current relationship editor where you set the perceived and confidence traits of one actor for another is painful to use.
It might be helpful to redesign it to present the same information graphically and allow you to see the results by visually manipulating character relationships.
All Characters Traits Editor
It might be helpful to have a high level view of how an actor’s traits relate to the traits of the other actors so you can fine tune the personality models of all the actors in your storyworld
Visual Verb Web Editor
The current Verb editor interface is serviceable but could be improved. While you can see your storyworld’s verbs in a tree view it’s impossible to easily see the relationships between verbs at a glance or drill down to get a greater level of detail
A different view on the Verb editor, maybe tying into the tab icons mentioned earlier, could alleviate this roadblock.
Should we remove the X and Y spatial coordinates associated with each stage?
Should we limit the number of stages that can be created in a storyworld, maybe initially limiting storyworld authors to one or two stages?
Matt Chelen wrote this in Some Thoughts on Interactive Storytelling:
“The author defines scenes and the narrative emerges from the way that the player interacts with those scenes…”
That line stood out because you don’t have scenes in Storytron, you have stages (you do have scenes in Inform 7).
That got me thinking that maybe we should add a similar construct to Storytronic storyworlds. A scene could consist of one or more stages, one or more actors, and a verb web tailored for that specific scene. Maybe scene verbs are only “active” in the scene where they’re defined. Maybe scenes could have start and end conditions.
Having a scene construct might allow multiple storyworld authors to collaborate. One writes the assassination scene, another writes the betrayal scene, and so on. Of course, there needs to be a way to import scenes into your storyworld and link them together. There’s no way to do that right now but open source offers a way.
The creation of this storyworld will be done in tandem with the writing of a new SWAT tutorial.
Chris Conley and I will be creating a new set of documentation focused on the open source version of Storytron, combining the best of the old (here, here, and here) with the new features and functions being developed.
Our initial plan is to create a manual and a tutorial for Beta sometime in the 1st or 2nd quarter of 2019 (both are currently in extreme Alpha). Future plans include engine documentation along the lines of the Z-Machine Standards Document.
I hope some of you are excited about where I want to take Storytron and get involved or committed in some way.
Have a great holiday.
I finally finished staining the bookcase I bought and brought it up to my home office and put all the boardgames that I own in it. 85 to 90 games in all spanning every decade since the 1970’s. I estimate that I’ve probably played 90% of them at least once.
At $50 a game it’s probably a $4250–$4500 investment. Pretty impressive, probably just as impressive as the 198 game CDs I’ve got filed away in my closet.
Last night I went to a group that meets once a week in Norton, MA to play boardgames. I walked in a bit late but managed to get in on a game of Import Export with a group of four other people—Phil, Al, Vincent, and Wayne. It had fun, though I found it took a while to understand some of the rules, particularly the rules around imports and goods.
I ended up buying a copy of the game (I’ve still got a little free space in my shelf in the lower middle section). But I can’t keep doing that. Beside the expense, I don’t want to have to go out and buy another bookcase.
I don’t know why I stopped designing. I still think it’s a good idea. At the very least I haven’t ever seen a boardgame about rock climbing. However, if I were to design it now I would probably make it a single player game initially and then come up with multiple player rule variants if necessary (each person would have to buy their own copy of the game if they wanted to play together).
Another idea related to boardgames would be a mobile app that would allow you to play any boardgame you owned in single player mode. The app would function as the other players so you could play a game that required multiple players even if it was only you.
I wonder what the legal ramification of this idea would be. You aren’t duplicating the game on a mobile device, you’re just programming the ruleset and allowing it to simulate multiple players. The user interface would be bare bones, probably text only. The app would be useless if you didn’t have a copy of the actual boardgame.
Update 07/09/18 – There is a boardgame out there that uses allows the use of a companion app called Mansions of Madness. I bought the game for that reason but have never played it.
On 4 August 2016 a second edition of Mansions of Madness was released. Aside from some minor modifications, gameplay was fundamentally the same as in the first edition but with the role of the keeper replaced by a companion app that would run on PC, iOS, or Android platforms. This app expanded the gameplay in several ways including the randomization of maps and monsters and incorporating and extended range of interactive puzzles into the app. It also meant that the game could be played solo.
I’m just downloading the iOS app. I have some free time this week so I’ll play through one of the scenarios using the app as a game master.
This could be an interesting side project. It ties into my desire to actually play more boardgames. It allows me to delve into the mechanics behind individual games and try and tease out the commonalities. Coming up with a declarative programming language to specify game mechanics would be interesting and programming it in Xamarin/C# would enable me to keep my coding skills up.
Of course, I’ve got a the Legably and Storytron side projects currently active. I have to be aware of not overloading myself with too much work that I don’t do anything well.
TL;DR – The Storytron SWAT source code is online at www.storytron.org.
After Chris retired from actively working on interactive storytelling he decided to make all of the Storytron source code available to the public under a open source license. One repository is currently available at www.storytron.org (with more to follow).
This repository is for the storyworld authoring tool (SWAT) which also contains two other Storytron components—the Engine and the Storyteller. With SWAT you create storyworlds like we did back in 2010. These storyworlds are run through the Engine and played using the Storyteller.
There’s a ReadMe that will walk you through the steps to get the downloaded code running in Eclipse. You’ll also need to install and configure Git if you want to clone the repository.
For Storytron discussion and support we’ve created two groups— one on Slack and another on Google Groups. For Slack access email me at firstname.lastname@example.org (please provide your full name and email address). You can request access to the Google Groups discussion board at that site.
Slack is similar to other online chat programs from AOL, Yahoo, Microsoft, or Facebook that you might have used. It supports direct messaging between individuals and also has individual channels for the discussion of specific topics. The only drawback to Slack is that with our free account we’re limited to searching 10k of messages.
Google Groups is similar to other discussion groups or bulletin boards you’ve encountered in the past. Messages are posted with and the message threads evolves as the back-and-forth discussions develops.
I leave it up to the community to determine exactly how both these groups should be used.
For those of you who are interested in some of the historical thoughts and discussions behind Storytronics and Storytron there are two older discussion boards that you can wander through.
The conversations on the Siboot discussion board are focused on Chris’ most recent attempt at re-imagining his original 1987 Trust & Betrayal: The Legacy of Siboot using an updated version of the 2010 Storytron technology.
The conversations on the Storytron discussion board go back much further and probably span the years from 2008 to 2010. I say probably because this is an archive of the original discussion board and some of the message threads weren’t captured completely. But it’s still an interesting glimpse at what once was.
What can be done with the open sourced Storytron code?
At the very least we can make the existing code easier to use. The current user interface is tightly coupled to the implementation model which makes it necessary for authors to perform an unusual set of mental gymnastics to bring their mental model in line with how the tool works.
But all the changes don’t have to be done at once. They can be done piecemeal, step by step.
For example, it always annoyed me that you were unable to open a new storyworld once you had started SWAT. The program prompted you to select a storyworld when it first ran but to open a new storyworld you had to quit SWAT and restart it a second time.
Without the source code I was out of luck, I would have had to contact Chris and convince him that the change was necessary. But with the source I was able to create a new Git repo branch and add an Open menu item to the existing menu structure.
It’s still a work-in-progress but once I’m finished coding and testing I’ll push my local branch back up to the online repo and merge it back into the master. Then, everyone will have access to this feature.
The same thing could be done to add a New menu to SWAT so a storyworld builder could create a new storyworld from scratch instead of having to open and modify an already existing storyworld and remember to save it under a new name.
The current code implements a client/server architecture, a legacy of the Storytron business model when the engine ran storyworlds on a server. The engine code has been integrated into SWAT but the code could be refactored, making it easier to understand and maintain going forward.
Setting up character relationships using perceived traits was always difficult. Better editors could be created to configure these relationships visually.
The current version of SWAT didn’t support a interstitial stories. It was possible to create them using custom verbs but it was a hack and a bit kludgy. With the Encounter Editor source code it would be possible to integrate this tool into SWAT for a seamless development and presentation experience.
The current version of SWAT only supports displaying a single static image for each character at the bottom of the Storyteller window and emoticubes next to character responses. We could move beyond this and enable storyworld builders to use multiple images for their characters and configure how they are displayed to the player. Again, having the source code available makes this possible.
We could even integrate some of the face technology that was developed for the latest version of Siboot once Chris releases that source code.
All these languages have various degrees of interoperability with Java so it might be possible to rewrite existing Java code in one of them to make it easier to understand, maintain, and expand.
These are just a few things off the top of my head that we could do to improve Storytron now that we have access to source code. I’m sure other people can come up with a few more once they’ve had a time to familiarize themselves with the SWAT code at http://www.storytron.org.
Let a thousand storyworld’s bloom!
Note: Cross-posted to Medium here.
TL;DR: StoryCalc is dead, long live StoryCalc.
In StoryCalc: A New Hope I wrote about developing an open source, extensible platform for interactive storytelling based on Chris Crawford’s Storytronic principles.
I didn’t have much more beyond that when I wrote that post but I felt that by sticking to the basic principles outlined in Chris’ blog posts, books, and videos as well as starting from scratch I could create something that had all of the benefits of Storytron but none of it’s flaws (though I didn’t doubt I’d add a few of my own).
I didn’t think it would be easy and I figured it would take a year or two working part time to get the very basics up and running. I didn’t know what form this first version would take but I envisioned something like Inform 6—you’d write code in a text editor that would be compiled into a storyworld file that would be read by an interpreter targeting a specific device (an architecture used for the old Infocom-style games like Zork or but with a visible parser resembling Journey). I figured I’d probably write it in Python since it’s one of the more popular programming languages out there.
I gave myself some time to think, writing Who Is Chris Crawford? and What Is Interactive Storytelling? In the middle of writing What Is Storytronics? Chris Conley emailed me about creating some small prototype Storytronic storyworlds rather than trying to boil the ocean.
After some emailing and slacking back and forth we decided to use Inform 7 as our back end and some yet-to-be-determined software, either lectrote, quixe, or iosglulxe, as a heavily modified front end for the I7 output. It wasn’t an ideal tool chain but we thought it best to try something with the tools we had available rather than wait for something like StoryCalc that hadn’t even been designed yet. We decided on a post-apocalyptic scenario set in the Hawaiian Islands called Hawaii Coup and started a design document.
I finished writing What Is Storytronics? and Chris Conley worked on shoehorning Storytronics into a tool not designed for it. We both also worked on fleshing out the Hawaii Coup design document. Then, on June 13th Chris Crawford published an essay entitled Why I Am Ending Further Work On Interactive Storytelling (which caught me by surprise since I thought he had thrown in the towel earlier with Not Quite The End).
After reading this latest essay I emailed Chris to ask if he was still planning on releasing the Storytron source code as open source. He posted this idea to the Interactive Storytelling group on Facebook, asking if there was any value in making the source code available since so few people grasped his algorithmic approach to interactive storytelling.
I told Chris both publicly and privately that if he were to release the Storytron source code as open source I would seriously consider putting StoryCalc on the back burner and, instead of writing new code, I would expend the effort making the Storytron code better. But there was one caveat — I wouldn’t work with someone’s proprietary code, I learned that lesson back in 2010.
I also let Chris know that Chris Conley had told me that he was inclined to use SWAT, the storyworld authoring tool, for Hawaii Coup instead of Inform 7 if the code were open sourced.
Long story short, Chris Crawford decided to release all the Storytron software into the public domain starting with SWAT. He wanted Chris Conley and myself to lead the effort after he did a pass through the code to comment any areas that were unclear. He expected to complete this work by August 1st.
Well, the code didn’t need as much commenting as Chris thought and he sent us a copy of the SWAT code on July 12th, ahead of schedule, catching both of us off guard. So far I’ve managed to get the code running in the latest version of the Eclipse IDE for Java Developers and have done some cleanup, mostly removing the old hidden Subversion files that are scattered throughout the directories. We expect to have the code up in its own Github repository sometime in the beginning of August.
So where does that leave StoryCalc? Well, for now, StoryCalc is in hiatus. I don’t see the benefit of reinventing the wheel and writing all that code from scratch when I can work with the original Java code and make it better.
At the very least we can make sure that Chris’ twenty-five year odyssey gets the recognition it deserves so that years from now he is recognized as the Babbage of interactive storytelling. At the very most, we might be able to build on what he’s done and create something sublime . I don’t know right now but I do know that we can get somewhere together.
Note: Cross-posted to Medium here.
You can divide Chris Crawford’s interactive storytelling work over the past twenty-seven years into two categories — Storytronics and Storytron.
- Storytronics is a collection of principles that outline what Chris’ version of interactive storytelling is.
- Storytron is Chris’ attempts to create tools that enable the creation of storyworlds built on Storytronic principles.
Storytronics puts the priority on people and their emotional actions and reactions instead of on things or places.
In a theater play, characters enter, exit, and move around the stage. They converse with other characters. They monologue their innermost thoughts to the audience. While they use scenery and props to support the fictional world they’re creating, their primary focus is on the other characters and their interaction with those characters. The same thing happens in a Storytronics storyworld.
For this to happen in a dramatic way appropriate to the storyworld a character’s motivation, emotions, and history must be algorithmically represented so varied and nuanced responses, not pre-scripted ones, are possible for a particular situation. For this to happen, a personality model is needed.
The personality model is the blueprint that is used to create each character. It consists of several components:
- Intrinsic traits
- Perceived traits
All traits and moods are represented by bounded numbers. A bounded number is a number whose value is always between -1.0 and 1.0. Bounded numbers allow internal calculations to be performed without overflow. In practice a bounded number calculation will always approach it’s upper or lower limit but never reach that limit.
Each actor’s personality is an instantiation of the personality model. Let’s look each of the traits and moods that make up the personality model in more detail.
There are three intrinsic traits in the personality model — bad_good, false_honest, and submissive_domineering. The three traits control how a character will behave in general, independent of how they feel towards another character. They are unique to each actor and they are constant, a character’s personality will not vary during play.
- The bad_good trait indicates how pleasant and helpful to others someone is. A person with high, positive bad_good will perform kind and generous acts; a person with low, negative bad_good will be argumentative and stingy.
- The false_honest trait indicates the integrity and truthfulness of a person. People with high, positive false_honest are fair and true to their word; people with low, negative false_honest are unscrupulous and exploitative.
- The submissive_domineering trait represents charisma and force of personality, not physical strength. People with high, positive submissive_domineering are born leaders; people with low, negative submissive_domineering are meek, unassertive followers.
You can think of these intrinsic trait values as ranking characters relative to the other characters in a storyworld.
- A character with a bad_good value of -0.4 is more generous and friendly than 30% of the population and more mean and unfriendly than the remaining 70%.
- A character with a false_honest value of 0.0 is more honest than 50% of the population and less honest than 50% of the population.
- A character with a submissive_domineering value of 0.8 is more authoritative and commanding than 90% of the population and less charismatic than the remaining 10%.
Because they involve only one character, intrinsic traits are frequently referred to as P1 traits.
A perceived trait involves two characters and is an indication of one character’s perception of the other character’s intrinsic trait. They can change over time. There are three perceived traits in the personality model — hate_like, distrust_trust, and fear_disdain.
- The hate_like trait reflects how good one character believes another character to be. It is linked to the P1 trait bad_good. Noble, friendly actions by one character in another character’s presence should increase the latter’s hate_like towards the former. A character with a high like for another character finds them admirable and pleasant to be around.
- The distrust_trust trait represents how false or honest one character believes another character to be. If one character lies, cheats, or steals from another character should decrease the former character’s distrust_trust for the latter.
- The fear_disdain trait represents how powerful one character finds another. A soldier who is treated well by their commanding officer would have a high fear_disdain for that officer while insubordinate soldiers would have a low fear_disdain.
Because perceived traits involve two characters they are frequently referred to as P2 traits.
Here’s an example to illustrate how perceived traits relate to intrinsic traits. Three characters — Jack, Kate, and Sawyer — are stranded on a desert island in the Pacific. First, let’s look at each character’s integrity and honesty, represented in the personality model by the P1 trait false_honest.
- Jack tries to do the right thing and operates from the maxim that “honesty is the best policy.” His false_honest of 0.50 means he will usually do the right thing 75% of the time but he is no paragon of virtue.
- Kate is a felon with a shady past she is trying to hide. Her false_honest of -0.25 makes her more than willing to dissemble if it suits her purpose but she still has moments of integrity.
- Sawyer is a con man and his first thought is “what’s in it for me.” With a false_honest of -0.50 he will manipulate a situation to his advantage if at all possible 75% of the time. But he is not totally without virtue.
These false_honest values for each character will not change during the entire time that the storyworld is played. They are fixed.
The perceived traits of characters in a storyworld start off set by the author but their values can change as the storyworld is played.
A character’s perceived trait towards another character can change during the playing of a storyworld depending on the second character’s actions towards the first character and how they differ from what they have said.
If Jack continues to behave at his 0.50 honesty in all his dealings with Kate and Sawyer, their distrust_trust for him could increase, approaching but never reaching it’s upper limit of 1.0. But if for some reason, Jack believes it is not in his best interest to continue behaving at 0.50 honesty (which he might do 25% of the time), Kate and Sawyer’s distrust_trust towards him could decrease towards -1.0 and the two of them will behave accordingly.
What holds true for Jack also applies to Kate and Sawyer. Their deeds and words in the storyworld will affect Jack’s distrust_trust towards them.
Moods represent a character’s current emotional state and are self-evident values, which means they can be perceived by other characters. Combined with their P1 and P2 traits, a character’s moods can play a role in determining what actions a character will take when presented with several choices.
Like perceived traits, moods are not static. They can change as the storyworld is played. However, moods seek an equilibrium, relaxing towards zero at a fixed percentage if not affected by another character’s actions.
There are four moods that make up the personality model.
The traits and moods described above are just a starting point. Depending on a particular storyworld’s goal and theme it might be necessary to add or subtract from the traits and moods listed above.
Since Storytronics places a high priority on character relationships and social reasoning above spatial navigation, resource management, hand/eye coordination, or puzzles, faces will be a big part of the storyworld interface.
In order to convey a character’s emotional state these faces need to be linked to the underlying personality model so they can accurately reflect what a particular character is feeling and how they feel about another character.
The facial styles should lean more towards caricature rather than realism since caricature makes it easier to convey emotion and intent.
Over the years Chris’ games have all included a facial component. Here’s a few of the variations that he’s created.
Characters in a storyworld have to communicate with one another for any meaningful dramatic action to happen. To do this they need a language.
Building off a variation of the Sapir-Whorf hypothesis Storytronics maps that language to the reality it represents.
Every word in the language includes all the algorithms and data structures that define its operation in the storyworld. Because of this 1:1 mapping language and universe are one and the same.
This language is tailored towards the specific type of storyworld being created and consists of a web of verbs that the characters can use at appropriate times to construct sentences when interacting with other characters.
Each verb has its own customizable sentence structure made up of wordsockets. There is an upper limit of 15 wordsockets per verb.
The first two wordsockets are fixed — the first is the subject and the second is the verb itself (every sentence always has someone doing something). The remaining wordsockets can contain any of the standard word datatypes (items in Bold are an instance of the type):
- Actor – Vetvel want-to-find Wiki
- Prop – Vetvel read-about mind-combat
- Stage – Vetvel want-to-go-to Kendra-house
- Verb – Vetvel desire-to kiss Zubi
- Quantifier – Vetvel greets Skordokott sincerely
Even with these limitations it is possible to create complex sentences, sentences like “Vetvel offer-to-reveal Gardibore Katsin [if] Zubi [reveals] Locksher Shial.”
Besides wordsockets, each verb also has a set of roles and each role has a set of options. When a sentence is performed, actors react to it by creating plans. A verb’s roles and options determine what plans the reacting actors can make.
Each roles represent a different points of view that an actor might take based on a given sentence. For example, if Vetvel, Skordokott, Wiki, and Zubi are in the same location, and Vetvel says “Vetvel tells Wiki [that] Kendra betrayed Zubi,” there are four roles that are available to be taken:
- The one revealing the betrayal (Vetvel)
- The one who the betrayal is revealed to directly (Wiki)
- A neutral bystander (Skordokott)
- A bystander who is the victim of the betrayal (Zubi)
When actors in the same location react to a sentence, each actor determines which role they best fit into using the inclination scripts associated with the role. If a role is appropriate for an actor they assume that role and experience any emotional reactions associated with that role (this could affect their moods or perceived traits).
Each role has a one or more options attached to it and each option represents an opportunity to react to the original sentence (each option is really a link to a previously created verb).
Once an actor assumes a role, they create a plan using one of the role’s options, the option choice being determined by the acceptable and desirable scripts attached to that specific option.
Once a role option is chosen, the actor fills out their reaction plan, i.e. creates their sentence, by assigned appropriate words to the option verb’s wordsockets. The type of word datatypes available for each wordsocket is controlled by acceptable and desirable scripts attached to the individual wordsocket.
Since Chris estimates that you would need thousands of verbs for a satisfying interactive storytelling experience the person playing would use an inverse parser to select options and create sentences.
Inverse Parser from Storytron Siboot (2010).
Inverse parser from Siboot Remake (2015)
Plans, Events & History
The sentences created by characters come in two types: plans and events. A plan represents an intended action, one that will happen, while an event represents an action that has already happened.
All events are stored in a history book so they can be referenced by actors or by the narrative engine and Fate.
Narrative Engine & Fate
At its simplest, the narrative engine is a loop that starts the storyworld in motion and moves it one sentence at a time to its dramatic conclusion.
To do this the engine keeps track of storyworld time, advances the storyworld clock and, as the clock moves forward, process all character plans created to date. Based on each plan’s verb, roles, and options, it manages the process by which other characters come up with their reaction plans to a character’s actions.
The whole process continues until either nothing happens, i.e. there are no plans to execute, or the story reaches a satisfactory dramatic conclusion.
To help it reach a satisfactory dramatic conclusion the narrative engine has the services of one of the most important actors — Fate. Fate exists in every storyworld.
Fate makes things happen in a story outside of normal character actions.
Fate knows everything that happens in the storyworld and, based on a storyworld’s state or the progress of a particular series of events, it can trigger other events to heighten the drama or spin the storyworld off into a new direction. Fate is the author’s avatar in the storyworld, their deus-ex-machina.
It was Fate that made Han Solo come back at the right time to save Luke Skywalker in Star Wars: A New Hope. It was Fate that brought Gandalf back at the right time to save the fighters at Helm’s Deep in Lord of the Rings: The Two Towers. And it is Fate that will keep an eye on your storyworld’s meta-state and provide dramatic plot points at the appropriate time.
Encounters are vignettes or scenes that provide colorful glimpses into the storyworld milieu while allowing the player to influence their character’s relationship with the other characters. They usually occur based on Fate’s interventions and are handled outside of the normal action/reaction loop. Encounters can use verbs found in the storyworld’s verb web or they can provide more “natural” responses.
Chris estimates that it would take hundreds of encounters to flesh out the storyworld experience properly. One of his last pieces of work was a general purpose Encounter Editor.
Note: Cross-posted to Medium here.
Interactive storytelling is a form of entertainment that uses the computer as a medium to allow players to create and influence a nascent storyline through small, relevant, dramatic actions.
The primary focus of a storyworld should be on character interactions and social reasoning.
Instead of the four tropes that dominate a majority of today’s games—spatial navigation, resource management, hand/eye coordination, and puzzle solutions.
While social reasoning takes precedence in a storyworld, an entertaining storyworld will probably include some of the other four tropes, though they would not take precedence.
Note: Cross-posted to Medium here.