First the video.
Now the flowchart (more flowcharts here).
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.
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.
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.
TL;DR — SWAT v1.1 released, new “old” storyworld repository available, Storytron Patreon created
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.
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.
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.”
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.
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.
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.
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.
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.
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
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.
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.
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.
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
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 love this video.
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.