Introducing Elm Story - a new tool to visually compose and publish interactive storyworlds

Hi everyone,

I would like to share a project we are working on, concerning interactive narratives and worldbuilding: https://elmstorygames.itch.io/elm-story

Elm Story is our free design tool that helps authors, designers and students visually compose and publishing immersive interactive storyworlds. Featuring a virtual storyteller (DM), audiences experience branching narratives tailored to player choice.

Coming December 10th is the Elm Story 0.6 release featuring comprehensive revisions to our data taxonomy and the introduction of the Character Manager which will help you to manage characters and design their unique personalities. You can learn more reading our devlog on itch.

You can join us on our mission to revolutionize interactive storytelling!
Thank you!
https://twitter.com/ElmStoryGames

6 Likes

Hi Leonardo,

I’ve just watched your introduction video, it looks like a really powerful tool! I’m looking forward to watching the second one and also learning more about the character manager.

Are you aware that there’s another interactive story tool called Elm Narrative Engine? I initially thought you were posting about that.

Jason

2 Likes

Hi, nice to meet you!

Thank you for your interest in our project. There are a lot of changes that will soon be released with 0.6 (here is the roadmap: https://elmstorygames.itch.io/elm-story/devlog/318819/elm-story-is-growing-team-roadmap-and-community-updates). If you are interested, we are glad to invite you to our community

We are not the same tool, Elm Narrative Engine is based on the Elm language, right? We used the metaphor and myth of the tree to give the tool its name.

4 Likes

Thanks for sharing this! Not sure a 72-minute “introduction” is the right length for a video :stuck_out_tongue: but definitely will download this and tinker around with it.

Also a bit curious if “dark mode” is the default for this app.

1 Like

Hi Sam, I’m glad the project is interesting to you.

You are right about the length of the video! We are just waiting for the 0.6 release to fix the documentation because the changes made to the UI will be substantial.
We will also implement a “light mode” later on :slight_smile:

Feel free to follow us and provide your feedback. Our goal is to listen to designers/writers and improve together!

1 Like

Hope you don’t mind reading a long response because I took the trouble last night of downloading your ES app (Mac version) as well as watching the entire introductory video (which seemed as though it were filmed live, but I couldn’t quite figure out to whom you were talking :stuck_out_tongue: )

For the past five years, I’ve made a living as a chatbot designer and now, consultant. Perhaps the easiest way to think of a chatbot is a “boring IF game that serves a business purpose.”

But it’s precisely because of that business purpose (i.e. profitability) that chatbots have fantastic visual drag-and-drop design tools. I highly, highly recommend that you try at least one of them so that you’re not reinventing the wheel with ES, so to speak.

In fact, my advice is to go tinker around with Landbot (they have a free no-card-needed tier that’ll let you play around with the system without paying).

Oddly, the chatbots that Landbot creates are ugly AF, but the design tool is quite beautiful and easy to use. Furthermore, it’s intuitively simple to use, and it certainly doesn’t require a 60-minute video to get started :grin: .

For example, simply clicking on a leading node and dragging it to an empty spot allows you to instantly create a new node (“passage” or “jump” in ES-speak). That’s far easier than having to type in a shortcut or moving the mouse to click on a menu option.

I fully understand ES is not completed, and I salute your efforts to build a better IF creation tool, something I strongly agree is needed, which is why I invested my time in exploring it, but it’s far too early to start asking people to pay for downloads.

My thoughts on what you’ve got so far:

  1. There is no need whatsoever to have routes get their own name. Just let the computer assign one for internal purposes.
  2. Just ditch the hot reloading option. Way too much work to code, and it only takes a second for the author to click “reload” after implementing some changes.
  3. I don’t like how the selected choice remains visible on the screen after it is selected (during gameplay). I recommend deleting it so that the text of the story reads seamlessly.
  4. Currently, there’s no option (and no talk) of what chatbot folks call “A/B testing” and what is more accurately designed as random path selection. In other words, some ability to randomly (either purely random or weighted random, as in two-thirds of the time, it picks path A and 1/3rd B, etc) select a path for the story to progress.
  5. Why does this matter? At the moment, your system is unable to create a game as simple as Rock-Paper-Scissors. Every time a client asks me to create a chatbot in a new format or with a new tool, the first thing I do is create an RPS game just to see how flexible/inflexible the system is.
  6. It’d be far better to see the text inside a passage when looking at the main scene editor screen, instead of just its title. If you’re worried about overlong passages clogging up the editing screen, then just truncate them at n characters.
  7. It’s frustrating that you can’t rename a passage while editing that passage. Instead, you have to click somewhere else.

Obviously, there are many more things I’d ilke to see, but I know you’re still working on them, such as customizing colors, fonts, and adding media. Again, though, Landbot has got this down pretty well, so I highly recommend you explore their way of doing it.

I will say this, though, and it’s something that every visual drag-and-drop system will encounter sooner or later, even purely design tools like Botmock: once you get more than n number of boxes and lines on the screen (as well as images), the tool starts using up tremendous amounts of computer memory.

I’m not a programmer so I can’t say why this is so, but it’s a big problem. Even with ES far from complete, my advice is for you to create a fake game with 50 or 75 nodes (passages/jumps) to see if you start experiencing the same issue.

Unlike IF games, most chatbots are relatively short and simple, but I shudder to think what a full-size IF game would do to my computer if I designed it with Landbot (or an equivalent tool, such as Manybot).

Lastly, it’ll really help promote your system as well as attract Patreon backers if you write and complete a full demonstration game. That half a game about turning on a lamp isn’t enough.

I realize that most IF writers have to be, at least on some level, programmers, so I am enormously excited to see you working on creating a purely no-code authoring tool. I entered a piece in IFComp this year that was written with such a tool, and while mine wasn’t particularly successful (LOL), I feel like there are a lot of authors out there who could benefit from not having to debug their games and wrestle with stubborn syntax when all they want to do is create a fun story.

In other words, I really hope that ES succeeds. But before you paint yourself into a corner by laboriously recreating a Landbot clone, I recommend you tour through the many chatbot creation tools out there to get a feel for what works and what doesn’t, especially, as I said, which ones end up consuming vast amounts of computer memory when they get bigger than 30+ nodes of content.

Can’t wait to see you finish ES and create a stable publishing platform so that no-code IF games finally have a chance to compete with ones authored by legacy programming tools!

6 Likes

Sam - Thank you so much for your time evaluating our tool and providing your experience and thoughtful feedback!

In addition to development, we’re currently focused on expanding our documentation (https://docs.elmstory.com/) for the 0.6 release coming next week. Really appreciate your patience with the recorded livestreams! :grin:

As early access freeware, we ask for optional tips/donations to help support Elm Story development.

We’re planning to keep the ES tool as freeware forever (always works offline and does not call home, collect analytics or require account signup), with an optional hosting service (ESC) coming next year.


For example, simply clicking on a leading node and dragging it to an empty spot allows you to instantly create a new node (“passage” or “jump” in ES-speak). That’s far easier than having to type in a shortcut or moving the mouse to click on a menu option.

Completely agreed, as it combines both operations: node creation and connection.

This simplified and intuitive option is high on our priority list (0.7-0.8) for early access. For now, it’s possible to use the menu (as you mentioned) or right-click to where you’d like to drop a passage/jump node.

  1. There is no need whatsoever to have routes get their own name. Just let the computer assign one for internal purposes.

We also don’t see a current need and have disabled the UI for the 0.6 release.

  1. Just ditch the hot reloading option. Way too much work to code, and it only takes a second for the author to click “reload” after implementing some changes.

ES supports runtime patching (including world state) so that the designer can rapidly iterate and continue testing without the need to reload. This is a common and highly requested feature for modern development tools and game engines.

We’re planning mirror support to external devices which also makes this capability desirable. I can see use cases where a designer would like to toggle hot reloading and would prefer manual reset. In some cases, the Storyteller (engine runtime) requires this from the designer.

  1. I don’t like how the selected choice remains visible on the screen after it is selected (during gameplay). I recommend deleting it so that the text of the story reads seamlessly.

This is a great recommendation. We’ll likely make this an option for the designer/audience.

  1. Currently, there’s no option (and no talk) of what chatbot folks call “A/B testing” and what is more accurately designed as random path selection. In other words, some ability to randomly (either purely random or weighted random, as in two-thirds of the time, it picks path A and 1/3rd B, etc) select a path for the story to progress.
  2. Why does this matter? At the moment, your system is unable to create a game as simple as Rock-Paper-Scissors. Every time a client asks me to create a chatbot in a new format or with a new tool, the first thing I do is create an RPS game just to see how flexible/inflexible the system is.

Random is currently supported, with designer-defined, weighted random planned for a future release.

I’ve put together a quick, 1 scene demo and exported the game if you’d like to import and take a look. [dropbox link]:

image

  1. It’d be far better to see the text inside a passage when looking at the main scene editor screen, instead of just its title. If you’re worried about overlong passages clogging up the editing screen, then just truncate them at n characters.
  2. It’d be far better to see the text inside a passage when looking at the main scene editor screen, instead of just its title. If you’re worried about overlong passages clogging up the editing screen, then just truncate them at n characters.

On the list for our 0.6 release! :raised_hands:

I know you’re still working on them, such as customizing colors, fonts, and adding media.

0.7 is our multimedia update, coming in January. ES will initially support per-scene/passage background images and audio (with transitions) as well as inline passage content images.

0.6 is our first release supporting multimedia in the form of character portraits.

image

image

Exported games (as PWA) in the current release support audience-selectable light/dark mode and editable CSS variables for the designer, but we’re planning to bring these presentation options (customizing styles) to the tool itself.

image

Even with ES far from complete, my advice is for you to create a fake game with 50 or 75 nodes (passages/jumps) to see if you start experiencing the same issue.

Important consideration. Our current suite stress tests 100s of nodes in a scene for us to keep an eye on how everything is performing. Our maps leverage the GPU to further improve performance.

We design for and recommend more modular scenes with less nodes per scene, making the storyworld easier to manage at scale. This gives us the added opportunity to optimize multi-tab display and larger map views, given the context.

For example, the 0.8 release in February will introduce a new smart composition system that includes an optimized storyworld map view of every connection (potentially hundreds of thousands); limited editing features, but useful enough for bird’s eye, branch testing and drill-down functionality.

Lastly, it’ll really help promote your system as well as attract Patreon backers if you write and complete a full demonstration game. That half a game about turning on a lamp isn’t enough.

Completely agreed. Elm Story is unproven until we hit this milestone.

Our current demo is a simple and short game we built in the second livestream (2h15m :upside_down_face:) called Terminal Access.

Can’t wait to see you finish ES and create a stable publishing platform so that no-code IF games finally have a chance to compete with ones authored by legacy programming tools!

Thank you so much. We’ll do our best to deliver!

4 Likes

interest suddenly increases

I apologize I haven’t clicked extensively on the provided websites. Is there a demonstration story or prototype available to see the engine in action?

(EDIT: I am watching the intro video now and I just got to the part that a showcase is upcoming…)

1 Like

Our current demo (Terminal Access) shows off most of the current engine features in 0.5.1.

https://elmstorygames.itch.io/terminal-access

You can also see it hosted on neocities.org. Design walkthrough (2h15m).

Amber Shores is an episodic storyworld only available as a preview. Our Storyteller engine supports game updates and persists state, so I’m planning to push more content as I’m able to work on it.

Rock, Paper, Scissors… is the demo I put together earlier today.

Including some additional docs links for importing, exporting and more info on exported PWAs.

Exported games are bundled with a tailored version of our Storyteller engine. In addition to game updates and world state persistence, the engine also supports full offline and install capabilities.

image

More info on our Storyteller engine, also referred to as ESRE, from the 0.5 devlog:

ESRE is designed using an event-based, time series architecture ready to support custom bookmarking, rewind and fast forward and (most excitingly) shared, global game state between separate games, moments and more. I’m planning several devlogs on how ESRE serves as an intelligent DM, with long memory capabilities.

Until then, read more about quality-based narrative design (QBN) via Emily Short’s Interactive Storytelling blog.

As of 0.5, ESRE supports an auto-bookmark feature that saves and loads the player’s most recent game event, persisting game state between sessions. To improve on-going player experience, ESRE also remembers prior events to be progressively leveraged as Elm Story matures.

We are planning a port of @sith’s Ink + JS (inventory) game, The Masque of the Red Death.

I’m really excited that we’re bringing character support next week.

From our Patreon preview, the character manager provides a personality compass for creating truly unique characters. This will further expand the Storyteller’s procedural potential.

character-personality

3 Likes

I am in awe of your UI development skills :slightly_smiling_face:
How do you feel about the proposition that authors who are motivated to create text-based games might not wish such a rich graphical environment, but would rather work directly in text themselves?

2 Likes

Not to speak for the OP, but aren’t there are already choice development systems that are authored in a text editor? Springing to mind are ChoiceScript and Tweecode for Twine. Also regular Twine is pretty much text-based except for the flowchart-style arrangement of text passages.

The primary question always asked to developers of new systems is “What does your authoring tool do that [existing system] does not, or how does it do it better?”

I haven’t watched all of the video, but what looks impressive about Elm Story so far is a similar type of flowchart interface as Twine, but there is also an outline view/navigation on the left, and instead of one massive weave of passages, the UI divides the game into “scenes” which each have their own separate navigable flowchart. Also pretty cool is the way the windows in the UI tab split and tile so authors can look at multiple scenes simultaneously. Also a separate console for variables (in the video he quickly just creates a variable without having to set it in a passage) and what appears to be all kinds of error-checking and real-time side-by-side authoring/testing.

I’m not for sure, but it appears as though this attempts to remove a lot of the in-passage scripting commands and split them out into drop boxes sort of how ADRIFT and Quest do for a parser game. At some point I found those systems a bit tedious when you’re having to fill out forms and checkboxes and drop-downs when it would be much easier to code if $a > 10 ... else ... but that may appeal to a lot of authors.

Along with future support for images and audio multimedia, as well as export for multiple apps, web/browser play, Unity integration, versioning and (it appears?) a way for an install to ping for game updates, and native offline installation tools on multiple OSs, this looks as though it takes into account many of the elements most authors ask for and puts them all together.

5 Likes

@tundish: How do you feel about the proposition that authors who are motivated to create text-based games might not wish such a rich graphical environment, but would rather work directly in text themselves?

As of 0.5.1, the writing experience is fairly basic. Double click on a passage header to edit content.

image

However, the underlying architecture is quite advanced and is ready to support an editing experience you might be familiar with if you’ve used tools like Notion. As we continue to build out content writing, our top consideration is to avoid the need for find and replace.

@HanonO: I’m not for sure, but it appears as though this attempts to remove a lot of the in-passage scripting commands and split them out into drop boxes sort of how ADRIFT and Quest do for a parser game.

Our design philosophy for Elm Story is to strike a balance so that the UI doesn’t get in the way of writing. For example, ES expressions are written inline, but we’re planning code completion and auto-refactoring (i.e. updating expressions when variable names are changed) similar to tools like Sublime and VS Code. We will also expose portions of the the internal Storyteller API.

It’s undocumented now, but it’s possible to do something like variableName.upper() to uppercase the display of the instance value to the audience. The method does not change state.

image

Our approach is functional/declarative to storyworld (game) composition, limiting the amount of imperative code the designer needs to write to achieve the desired result. This helps reduce side effects that are otherwise more difficult/slow to statically analyze and troubleshoot.

It is unlikely we will allow expressions that modify world (game) state, as this is better managed with path (route) conditions and effects.

@HanonO: […] what appears to be all kinds of error-checking and real-time side-by-side authoring/testing.

Yes! :raised_hands:

image


The second part of the character update (late-December) will support inline references using @, similar to tagging users on this board. Following is an early design artifact for how this might work.

image

Like every other storyworld element (component), this enables character edits without global find and replace.

character-info


Our 0.8 update (planned for early February) is focused on improving the writing experience.

You can track our progress and participate in discussion either on our community Discord server or via our issue board: 0.8.0 — Customization · Milestones · Elm Story Games / feedback · GitLab

Using a single shortcut, Elm Story will toggle to a contextual mode suited for focused content writing and keyboard use: distraction-free mode.

Early design artifact:

image

In this mode, Elm Story hides all other UI elements to focus on event (passage; term changes to event in 0.6) content writing. The remaining UI elements outlined in gray hide when the designer is writing and display with keyboard shortcut and mouse use.

We’ll have more on the UX soon!

1 Like

Though there aren’t any 3rd party tools that (we know of) support Elm Story data (e.g. Unity), our data schema is completely open to enable this.

[…] versioning and (it appears?) a way for an install to ping for game updates […]

Yes! Relinking for context: https://elmstorygames.itch.io/elm-story/devlog/311136/elm-story-051-seamless-game-updates-in-the-browser

image

When a player first visits your self-hosted game, ESRE installs and registers a service worker with the player’s browser. The worker is responsible for installing (pre-caching) and detecting revisions to your game’s data and assets.

Each time an online player returns to your game, the worker will inform ESRE of any changes to the engine and ESRE will prompt the player to update. During gameplay, in the background, the worker will periodically check for revisions every hour.

If the player’s device is offline, your game will continue to work.

https://docs.elmstory.com/guides/data/pwa/overview/#game-updates

2 Likes

Sorry if I got the unity stuff wrong, I thought I saw the logo on one of the slides, my bad!

1 Like

OK, well let’s celebrate that when it arrives.

There’s a reason why an author-side text representation is an important feature.
It is to protect the author against losing his work.

Data migration presents real challenges. A service provider has to do data migration if they volunteer to be the guardian of creative work which was written in version 4.5 when they are promising new features (hence a new schema) in 4.6.

An author-side text representation of the work is an insurance policy against the service provider failing to resolve any issue which locks the writer out of their new updates.

I’m learning about this system in development by watching the videos, and I’m not a programmer, but as I understand you can export and import a json project that is human-readable? Is that something that produces text code that can be archived and catalogued?

1 Like

Hey, Hanon, I was exploring just as you were :slightly_smiling_face:
The JSON schema I saw looked to me like configuration for the GUI editor rather than an archive of the work itself.

If I’m wrong now, I’ll stay as wrong until you point it out to me otherwise, so please let me know what you find!

1 Like

Questions about potential later features:

  • Text variation / randomization? This system totally lends to hub and spoke structure and if the player revisits a passage it would rawk to be able to mix up the prose on repeat.
  • Inline prose links to other passages / popup windows? I understand Elm Story is mobile-forward and the texting paradigm works well, but sometimes it’s nice to focus on a word or phrase of the prose rather than always selecting just from a list of authored boxed choices. Even if that box didn’t allow further links. (I love these in AXMA, and even Infocom had popup quotation boxes. So you can center something, or display an inventory image…)
  • Text Formatting? At least basic italics, bold, underline. Dare I ask for headings for chapters or titles?

I really like that a passage with no choice-link out just automatically gets a return link, that’s real handy.

I also really like that you can route a choice to multiple passages, and barring conditions the engine will choose one randomly. Using the conditions, you can weight that choice like a QBN…

I would also really like an option to choose whether the text starts at the bottom of the screen as it does or from the top, but that may not be viable with how the engine generates text.

2 Likes

1 Like