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.