The one where Dave experiments with a new IF Platform .... again.

A long time ago in the early days of my passion for Interactive Fiction (text adventures, story games, etc) I was much more focused on building stories. I still have several ideas that have reached varying stages of non-completion and will eventually finish at least one of them. But even after a few years within the “IF community” I have always been drawn to the idea of creating my own Platform. One that suited whatever ideas had percolated into my brain from my professional evolution as a software engineer and application architect.

Eventually I realized that creating an actual compiler was not where my interests lie. My interests are about how an author constructs a story, how the engine runs, and how the text is emitted. Having used TADS, Inform 6/7, and even Twine, I realized that none of those platforms do what I want. Inform 7 is a great tool and I will likely continue to use it, but it has some limitations that I’d like to explore breaking down in a new platform.

My experiences as an engineer and architect in the past ten years have been heavily influenced by the C#, Cloud architecture, Domain-Driven Design (DDD), and Fluent coding styles. C# is just my natural programming language and has reached a cross-platform open source status, as well as garnered many functional capabilities. The cloud provides an interesting platform to enable scalable software. DDD is a discipline that helps us reduce complexity and also focus on behavior and events as primary design criteria. Fluent coding with dot-syntax editor capability is a great way to enable an author or developer the ability to just figure things out as they go. For the moment, I’m not inclined to build something exclusively for the cloud, but whatever I design, should be portable to the cloud.

So I recently inflated another C# solution for my R&D platform called refly.

My current thought process is questioning boundaries. Are there any boundaries in an IF Platform? Some of the domains include World, Parser, Language, Map, and Object. If we dig into each of these, we can determine what’s "sticky” (A common DDD question).

The World would seem to be the root aggregate of an IF Story. It encapsulates everything that is created and altered.

The Language would seem to be an immutable structure of one’s preferred language, whether that be English or another language.

The Map is clearly a graph of every location the Actor can see or visit within the World, so likely a sub-domain of the World Bound Context.

An Object is a universal thing, but probably an Entity since objects in a real world can be manipulated.

Some things may be immutable within the world, like Scenery, defining them as a Value Object.

The Parser is a tricky domain since it needs to ingest all of the World data and the Language structure to tokenize a command and effect change upon the World. Alternatively, the Parser is a sub-domain of the World root aggregate, but not as data, but as a processor. This makes sense since anything “transactional” that happens to the world is controlled by the World Bound Context.

There is an encapsulating aspect to the World Bound Context in the sense that we need to tell it what it contains. So there is a Story domain which would contain all of the custom elements of the authors story.

Again, the Story domain is likely another sub-domain of our World Bound Context, since everything we build has to be known to the World.

The Output domain is a special case and is definitely a separate domain. The World will eventually need to report status and changes to the player. In all IF platforms to date, this is embedded within the World, Standard, and Parser domains. In my platform, the World would construct a list of text to emit with meta data. That structure is sent to the Output domain where the text and meta data are run through rules to construct the final text output. The author will be able to override the default behavior of this engine. Things like conversations, interruptions, object state change, description change, and other things can be directly identified as a part of the text emission process.

This brings us to how we practically build an IF story in such a platform. It’s likely not going to be a black box where you send in a story file and run it. It’s more likely going to be a set of coding libraries we compile together into something that can be executed from various user interfaces (command line, website, or custom).

So as the platform developer, I’m responsible for various client implementations, along with Language, Standard, World, Output, and Parser. The Author would be responsible for Story and any alternate Language library.

In the end, we’re compiling Client + World + Parser + Standard + Story + Language into one thing that the author can share.

Much of this is “thinking out loud,” as it is mostly R&D. If and when I take this seriously, is another question. I dig into it for a few hours here and there, but it is not a priority at the current time.