IF Interpreters and Separation of Concerns

As a software architect in the business world, one of the prerequisites to any system is to adhere to certain rules. One of these rules is “separation of concerns” and it’s meant to ensure that different types of logic remain separate from each other.

One of the common implementations of this rule is the separation of user interface and data. In the Interactive Fiction world, this would mean breaking apart the standard interpreter into two things. One to handle the story execution and one to handle the user interface. Luckily we have the ability to adhere to this rule with browser technology.

One of my primary reasons for building FyreVM, even in its original C# implementation, was to support the implementation of SoC. This is just good system design from my perspective.

I was able to achieve this on the Windows side of things and even to some degree in a browser using Silverlight, but that was never going to be something to which the average author would gravitate.

So that’s when (and why) I procured glulx-typescript through a Elance/Upwork project.

And as mentioned, having just the VM wasn’t enough. It had to have a full implementation to show how SoC works with Interactive Fiction. The Cloak of Darkness story in my fyrevm-web GitHub repository does just that.

But it really only shows the very basic requirements of SoC. There are elements of the IF interpreter that are tightly bound to the platform we use to develop stories. These include:

  • text styling
  • window or panel creation and management
  • images/video
  • sound
  • menus
  • modal popups
  • text location
  • link creation and intent

In developing fyrevm-web further, it’s my plan to make extensions for all of these types of UI communication. So the author won’t manage windows, but she might target a component with a particular set of text or she might say a panel should open or close based on story progression. But the actual window management would be entirely in the browser. The same would hold true for these other aspects of an IF interpreter. The HTML/browser would care and feed UI elements and the story file would just manage story, thus we reach separation of concerns in IF.

This is the rationale behind glk, so it’s not a new concept in the IF world.

Yes, but it defines a set of UI constructs intended for hardened interpreters and it’s limited to its own design and implementation. Some web niceties have been added, but I still consider glk a bottleneck to any open html development where IF is concerned.

HTML, CSS, and JavaScript have their own specifications and tool sets outside of Interactive Fiction. I think that’s the aspect of SoC that I’m really talking about.