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.
Storytron was Chris Crawford‘s attempt at commercializing his thoughts and ideas about Storytronic interactive storytelling, built off of his work with the Erasmatron.
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. Two repositories are currently available at www.storytron.org (with more to follow).
The first 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. The second repository contains documentation generated from the SWAT source code using Javadoc.
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.
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:
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.
Intrinsic and Perceived Traits—Jack, Kate, and Sawyer
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.
Teen Talk User 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.
Teen Talk Faces (left to right) - Adorable, Great, Nice, Pleasant, So-So, Unpleasant, Not Nice, Nasty, Hateful
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.
Faces in Chris Crawford’s Games (clockwise, from upper right)- Gossip (1983), Trust & Betrayal: The Legacy of Siboot (1987), The Global Dilemma: Guns or Butter (1990), Le Morte d’Arthur (2010), Siboot Remake (2015)
Characters in a storyworld have to communicate with one another for any meaningful dramatic action to happen. To do this they need a language.
Iconic Language from Trust & Betrayal: The Legacy of Siboot (1987). Icons are on tip, icon values are on the bottom.
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 Trust & Betrayal: The Legacy of Siboot (1987)
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.
Encounters from Trust & Betrayal: The Legacy of Siboot (1987)
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.
Anyone interested in delving into any of these topics in greater detail can find a wealth of information at Erasmatazz, Chris’ personal site, or the old Storytron site.
I’ve realized that many people who’ve read StoryCalc: A New Hope might not know who Chris Crawford is or what he’s accomplished.
Chris is a game designer and if it were not for his passion, hard work, and insights over the past thirty nine years I would not be here today attempting StoryCalc.
Building off his early interest in board wargaming, Chris released his first game, Tanktics, through Avalon Hill. Moving to Atari, he programmed Eastern Front (1941), Excalibur, and Gossip for their Atari 400/800 computers.
After the video game crash of 1983 he left Atari and became an independent game developer before there was such a thing. Programming for Apple’s Macintosh platform because of its consistent and powerful user interface he released Balance of Power in 1985. In 1987 he released his seminal work, Trust & Betrayal: The Legacy of Siboot, the first glimpse of what he would later call interactive storytelling.
I dreamed of the day when computer games would be a viable medium of artistic expression an art form. I dreamed of computer games expressing the full breadth of human experience and emotion. I dreamed of computer games that were tragedies, games about duty and honor, self-sacrifice and patriotism. I dreamed of satirical games and political games; games about the passionate love between a boy and girl, and the serene and mature love of a husband and wife of decades; games about a boy becoming a man, and a man realizing that he is no longer young. I dreamed of games about a man facing truth on a dusty main street at high noon, and a boy and his dog, and a prostitute with a heart of gold.
This dream lead him to take the road less travelled.
In a nutshell, Chris took upon himself the sisyphean task to try and drag the entire game industry into an artistic future that he imagined was just out of reach. But the industry wouldn’t listen so in 1992 he left, delivering one of the most passionate and inspirational call to arms that is known simply as The Dragon Speech (you should watch it). After that he “lit out for the territories,” leaving steadiness and security behind to search for the holy grail of interactive storytelling.
The trail becomes a bit harder to follow then. There was his annual interactive storytelling Phrontisterion conferences hosted at his home in Oregon where enthusiasts would gather and discuss how to advance the state of the art. He wrote books and lectured to audiences around the world about his theories of interactive storytelling. He worked on his next game, Le Morte D’Arthur which morphed into various versions of the Erasmatron, his interactive storytelling engine. Work on the Erasmatron morphed into Storytronics/Storytron, an attempt at commercialization. Sadly, this attempt failed in 2010.
It was clear, during Crawford’s period as a game developer, that he was an auteur operating at the top of his form, not always creating commercially successful products, but always pressing at the edges of the possible, always advancing the state of the art. He was an inspiration.
Chris is an auteur in the truest sense of the word, interactive storytellings version of D.W. Griffith, the American writer, director, and producer who pioneered modern filmmaking techniques. While other directors in Griffith’s day were content to churn out 10-15 minute shorts for nickelodeons, Griffith worked to refine this nascent technology, creating a new language of film that culminated in 1915 in the twelve reel, three hour epic, The Birth of a Nation.
“Nanos gigantum humeris insidentes”—I am a dwarf standing on the shoulders of a giant.
For the past twenty-six years Chris Crawford has been fighting the good fight, trying to jumpstart an interactive storytelling revolution. He says he’s failed and that his age, his perfectionist nature, and the complexity of the problem were the perfect storm that defeated him. He retires from the field, promising to put his software in public domain and work on other projects, but interactive storytelling will no longer be his primary focus.
StoryCalc is an experiment to see if it is possible to develop an open source, workable, extensible platform for interactive storytelling based on the principles Chris has outlined using his blog posts, books, and videos (here, here, and here) as primary sources. StoryCalc is not affiliated in any way with Storytron or Chris Crawford.
This experiment will be evolutionary, not revolutionary. I make no grandiose, earth-shaking promises. I am not asking for anyone’s help right now though I welcome feedback and discussion on the StoryCalc Slack group (click here to email me for an invite).