The project was inspired by Twine but works slightly differently. Twine maintains state by tracking your path through the story (if you watch the URL while playing a Twine story you will see a new number being added for every choice you make. This means that you can bookmark a location in the story and when you return to it, Twine will recreate the state by replaying your decisions. The problem I had with this is that it requires your story to be deterministic. The same choices must always result in the same outcome.
By contrast, StoryTeller records the actual state in the URL (it knows where you are but not how you got there) This means that random events can be incorporated into the story. This allows you to create something more like a gamebook than a basic Choose-Your-Own-Adventure.
For more information go here: http://storytellerjs.blogspot.com.au/p/about.html
storyteller.zip (15.3 KB)
Not sure if I’m misunderstanding here, but Twine totally allows for random events. Sure, if you load a game up the things that happened during that playthrough still happened in your save (can’t imagine why you’d want them to change), but it can be different when you play through again.
I may be completely misunderstanding what you’re saying. That happens a lot.
It has been a few years since I used Twine (the idea for this program has been bouncing around in my head for a long time) so I could be wrong. However, the last time I tried to write a story using it, the state wasn’t actually recorded in any way, only the path which brought you to the current state.
You could include randomness and that would be fine so long as your reader plays the entire story in one sitting. If they were to bookmark their place in the story and return to it later, what Twine would do is actually replay all of the choices they had made to get to that spot. If there had been random events along the way, the outcome of those random events would be forgotten and a completely different set of random events generated when the choices were replayed, meaning the state would not be accurately reproduced.
For example, on one page the reader might place a bet on a horse race. The outcome is randomly decided and results in either an increase or decrease in the variable representing the money the player character has. They then go on with the story, making further choices but have to stop before reaching the end of the story. They create a bookmark and close their browser.
When they return to their bookmarked position, Twine will replay their decisions but has no record of the outcome of the horse race, so it randomly generates the outcome again. The reader then might find that their character’s bank balance has suddenly dropped or increased because history has changed.
However, the developer of Twine may have figured out a way to record random outcomes since the last time I used the program, like I said It’s been a while. I did notice that they have added some HTML5 offline storage features. I was a bit iffy using those myself because I wasn’t sure how nicely they would play when the HTML file was opened locally rather than from a webserver.
You may well be right, and if you are that would certainly make bookmarking pretty useless. I use a Twine header called Sugarcube which offers an awesome solid save function rather than relying on bookmarking, which I never really tested. It sounds like you’re doing something similar.
The “sets and relations” planned feature detailed on your site sounds very interesting. Looking forward to seeing where that goes.
According to twinery.org/wiki/twine_1.4_release_notes , random events are managed properly in the Sugarcane model.
You could also compare with my gamebookformat tool (also on github, but I am too lazy to link on phone). Just yet another way to play gamebooks in a browser (with a focus on also supporting print’n’play). Saving state with localStorage, currently no fallback for ancient browsers. State includes inventory and variables and where you are. Would be surprised if I have 10 % of what twine can do, but I really wanted that option to print and that rules out some dymamic text rendering.
Thanks for letting me know. I’ve added a note to my website so I’m not misleading others about what Twine can now do.
Perhaps I’ll look into the sets and relations a little sooner than planned so that StoryTeller actually has something to differentiate itself from Twine.