I came out of the Storytron Winter 2018 Update with high hopes, a lot of energy, and a list of SWAT enhancements, bug fixes, and other related tasks. Since then the Storytron Google Group has seen some spirited discussions (we even had to ban someone who couldn’t “play nice” which I guess is a milestone of sorts). We also picked up three new patrons on Patreon. Progress.
But work on my initial list, which I’ve redrafted several times, has stalled. Though I’ve fiddled around with this piece of source code or that piece of source code, I haven’t made a single GitHub commit since December 1st.
We’re still two months away from the March 2019 Update so I’ll just have to pare down my initial list, probably focus on bug fixes and some code cleanup. But this downtime has also given me time to think about what is best for Storytron, what are the next effective steps to move it forward.
The original goal of Storytron was to kick start an interactive storytelling revolution—introduce people to the technology, show them a kick ass storyworld, and then step back while they sweep the barricades and changed the world of gaming forever.
It didn’t happen. While people might have understood the concepts behind Storytronics—a concise personality model, a dramatic verb web accessible via an inverse parser, a narrative engine controlled by Fate, using faces to convey emotional information, etc.—only a handful of people ever attempted to build a Storytronics storyworld of any substance.
Coming back to SWAT after a nine year hiatus I forgot the significant level of mental effort required to weave storyworld elements together into a dramatic whole. The SWAT user interface is usable but kludgy and the code that runs everything works but is a mess under the hood and could use some serious refactoring to make it easier to understand and maintain. The tutorials and author’s guide are woefully out of date.
I’ve come to the conclusion that redesigning screens, tinkering with user interface elements, porting the engine, etc. are premature. They’re important, but they also smack of rearranging deck chairs on the Titanic—it’s appears like progress but the ship is still slowly sinking.
So I’ve decided to focus my efforts on these four tasks.
Create a tutorial storyworld called Popularity & Prejudice
Integrate some form of the Encounter Editor into SWAT
Integrate some form of the Face Editor into SWAT
Rewrite the engine to make it cross platform
Popularity & Prejudice will be based on my previous work with Teen Talk (which was based on Chris Crawford’s 2012 re-imagining of Gossip, his 1983 game for Atari). There will be a companion wiki on the GitHub site that will walk an author through the process of creating a very basic conversational storyworld in five to ten lessons. The storyworld will be constructed using SWAT version 1.1.
The next step will be to integrate an encounter editor into SWAT based on the code that Chris Crawford has shared with me. At this point I don’t know what it will look like or how it will integrate into the rest of the verb web (I initially thought that encounter verbs should be tightly coupled to the rest of the verb web but that might restrict team storyworld development). SWAT with an integrated encounter editor will be version 2.0.
The third step will be to integrate a face editor into SWAT that allows the dynamic display of actor emotions. When I write “dynamic” I don’t know whether the faces will be a series of static graphic images swapped in or out or something more animated like Chris Crawford was attempting with his re-imagining of Siboot. SWAT with an integrated face editor will be version 3.0.
Between these major releases of SWAT there will probably be point releases that contain bug fixes, unit tests, code refactoring, and, yes, maybe even some minor changes to the user interface. But I’m not promising anything on this front and a lot will depend on the community of developers.
As the encounter and face editors are integrated into SWAT I’ll update the tutorial storyworld and write additional lessons to the wiki tutorial.
At the start of 2018 I had a goal to write 140 words a day. Done consistently for 365 days would have resulted in 51,100 words written for the year. In 2018 I wrote 86,760 words.
I first came up with the idea of writing 140 words a day back in 2017 after attempting to write a novel in one month the previous year. I’ve always been extremely anxious about writing fiction, whether screenplays or prose, and I thought getting into the habit of writing each day would help me get over that anxiety. Even though I don’t have any detailed statistics I know that I didn’t succeed in my goal of writing 140 words a day in 2017.
I used to be quite diligent about coming up with a list of goals at the start of each year as something I could measure myself against when the year ended. I’ve got detailed lists spanning 2012–2015 (I didn’t do write up any goals for 2016 and 2017 because I felt the process was counter-productive).
At the end of 2017 I was talking with an old friend from film school about his list of 2018 New Year’s resolutions (“drink less, write more, volunteer”). While the simplicity of his mantra-like list appealed to me, the list of goals I wrote up for myself for 2018 were a bit more specific.
One of the items on my list was, you guessed it, write 140 words a day, probably inspired by my friend’s “write more” haiku. In order to measure myself I created a spreadsheet that I could use to track my daily word count (because an unexamined life isn’t worth living).
Initially the spreadsheet was just a place to enter the number of words I wrote that day as well as categorizing subject by color. Later on I added some monthly statistics at the top that allowed me to see at a glance how many words I had written each month, the number of word remaining to be written that month, and total words written so far.
This design worked but towards the end of the year I wanted to create some charts from my single years worth of data and I found that the design I came up with at the beginning of the year didn’t lend itself to chart creation.
So I created a new worksheet that I could use for both entering daily word counts and reporting on progress. Across the top are the categories, still color coded, and below them are the monthly totals of words (individual day’s statistics are in the hidden rows underneath each month’s totals). Categorization is done by entering the number of words in the correct column. For graphic flair I also added a spark chart to the right of each month to give a quick idea of monthly frequency at a glance.
With this arrangement it was easier to create several different types of charts to give me a bird’s eye view of my progress throughout the year.
Some things are immediately apparent. I met or exceeded my writing goal for seven out of twelve months in 2018 and even for the months when I didn’t make my goal for that month, I still wrote something.
Almost 70% of my writing was in two categories—Journal and Storytron. I pleased that I got into the habit of writing in my journal every month. My Storytron writing was greatest in the months leading up to the announcement of my StoryCalc project in January, my overview of Storytronics in May, the open sourcing of Storytron in July, and the Storytron winter update in December.
Legably writing was confined to the beginning and end of the year. From January to May it was probably related to our aborted June release. From September to December it was getting user stories and documentation ready for future development.
In the months where there was a word deficit I can remember these events that probably diluted my focus.
On June 1st, just as we were about to go live with version 1.0 of Legably, Payoneer, our escrow payment provider, decided to leave that business abruptly. During the rest of that month and July we were focused on removing the Payoneer integration code, replacing it with Stripe Connect (we went live with version 1.0 on August 8th).
From June 4th to July 9th I was traveling between Rhode Island and Kansas City, Missouri for an Appirio strategy project (Appirio was my 925 job).
On July 9th I was let go from Appirio and I spent the rest of July and August looking for a new job, which I found at the end of August.
Don’t have any insight into the April and October deficit causes.
For 2019 I still have the goal of writing 140 words a day on my list. I’ve kept the four 2018 categories—Journal, Storytron, Legably, Other—but have added a fifth one, One Act Play, for a one act play that I’m going to write. Wish me luck.
The Sea of Ice (Shipwreck of Hope) – Casper David Friedrich
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.
Mockup – Editor Tabs
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.
Mockup – Editor Tab Buttons
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.
Involved vs. 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).
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).
This means that the engine needs to be ported to another language for storyworld distribution. The two languages that I’m considering are Kotlin or Microsoft’s C#/Mono Xamarin framework.
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.
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
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.
Current SWAT Relationship Editor
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.
Mockup – Visual Relationship Editor
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
Mockup – All Characters Traits Editor
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.
Mockups – Visual Verb Web Editor
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?
“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.
I’ll be creating a Gossip storyworld based on the iOS game Teen Talk that I developed with Chris Crawford back in 2013 (which itself was based on his 1983 game for Atari and his 2012 re-imaging).
Teen Talk – iOS
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.
Wanderer above the Sea of Fog – Casper David Friedrich
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.
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.
To learn how to build Storytronic storyworlds the original Storytron Author’s Guide and Tutorial are still available online.
For Storytron discussion and support we’ve created two groups— one on Slack and another on Google Groups. For Slack access email me at email@example.com (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.
Current Storyworld menu on the left; new Storyworld menu with an Open menu item on the right.
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.
A future Storyworld menu with a New menu item added.
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 Relationship Editor on the left; possible designs for a visual relationship editor on the right.
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.
An attempt at an interstitial story in the current version of SWAT on the left; an example interstitial story from Trust & Betrayal: The Legacy of Siboot (1987) on the right.
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.
Mockups for different ways to choose what character images are displayed to the player and how they might be displayed.
We could even integrate some of the face technology that was developed for the latest version of Siboot once Chris releases that source code.
Looking beyond Java, there are languages like Scala, Clojure, and Kotlin that are designed to run under the Java Virtual Machine or JVM.
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.
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.
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.
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.