That’s the tricky part, right?
That’s one of the central problem spaces for storylets. They are:
-
How metadata is stored. Harlowe, for example, uses the
(metadata:)macro to add extra information to its internal passage object. TinyQBN uses passage tags, saving the information as part of the internal passage object in SugarCube. As you mentioned, MouseQBN uses an array of objects, and my own SimpleQBN does the same thing for the same reasons, separating the storylet data from passage or other data. -
How parts are selected. Harlowe uses a when clause; TinyQBN uses a domain-specific language of hyphens between values and operators in the format of “var-op-value”, SimpleQBN uses a NoSQL-variant, and MouseQBN uses a per-property encoding where, at least as I can tell, the variables, operators, and values are each a separate property.
-
How availability or openness is determined and when. There are three different ways to do this: after a data operation happens (such as a value change in a global store), after a story event (such as passage transition), or when the author/program asks for it (using a macro or function to ask for all or a limit).
One of the things I have been researching is if it was possible to create a micro-language, like how TinyQBN handles part selection, and pair this with a C++ library for usage with JavaScript, C#, and other languages. In other words, if it is possible to solve that part of the problem space fairly well for most use cases and then create a library that could be used in either Node.js, Unity, or Unreal projects based on a plugin to supply object types and expression parsing.
A thing I really like about MouseQBN is how you solved this problem by separating the expression into parts. One for the variable, one for the operator, and one for the value or other variables as part of the comparison. That solution path might be really useful for the C++ library approach I’ve been thinking about.