When I started making this framework, I had planned for it to be completely code-driven. I took inspiration from other code-based storytelling tools, such as Inform 7 and Ren’Py. I put a lot of attention into making a very clean and simple API for story authors.
I also originally designed the framework to be very opinionated about what types of stories it would tell, and how they would look, without giving much control to the story authors other than defining their story world and how it progressed.
In my ElmConf presentation, I casually mentioned how using Elm and a data-driven could allow for neat things, like making a visual story editor. It was an interesting point, but not one that I took too seriously.
Then five things happened:
- My friend kept challenging me to “open up” the framework as a general purpose story-telling tool, allowing for more customization.
- After my presentation I received a couple intriguing comments along the lines of, “There’s something bigger here that you have tapped into that you don’t see yet.” What could they mean?
- I met Greg Ziegen, who is building a RPG game engine. His requirements and approach overlaps with mine, and we spoke about the challenges and implications of making a truly data-driven framework.
- I was contacted by a person who made their own story with my framework, who wanted a way to embed the story engine inside his existing Elm app, which was an interesting request. I also found it very enlightening to see a story built by someone else, and in in particular, the unanticipated, but delightful customizations he made.
- I had the awesome opportunity to do an api design pairing session with Evan Czaplicki, creator of Elm. Besides improving the code, talking with Evan stirred up many new, exciting possibilities for a more involved and fully-featured Elm Narrative Engine.
All of these points of inspiration bounced around in my head, and eventually it became pretty clear to me where I wanted to take this.Read more...