refly
I’ve been working on a new parser-based IF platform for a little bit. Still extremely early and more in design mode than actual development mode.
The platform itself I’ve tagged as “refly” meant to work on .NET Core C# and I’m looking for interested dev/gaming partners. The repo is at: https://github.com/ChicagoDave/refly.
Some of the top design goals for refly is to start from scratch on a parser-based interactive story platform. That means dropping all of the limitations that are present in current platforms by using modern design patterns and adhering to a loosely-coupled philosophy. Things like parser, world-model, language, context, input, output, and more would all be thought of as bound contexts and designed as such. There would be clear integrations between upstream and downstream contexts.
One of the primary complexities of such a design is how to construct text “on the fly”. In most IF systems, we simply PRINT things that get concatenated throughout the execution of a “turn” while also doing some template-based transformations. I’d like to break this process down to its core components, come up with as many scenarios as possible, and model a text-emission process that provides a high level of flexibility and minimal restrictions.
izyuk
There’s a second project to implement an IF-oriented in-memory graph database. I’m sure there’s a Venn Diagram for overlapping access to a graph, but I also think there is potential for IF-specific access. I’d like to explore this project, but could use help on the graph implementation side of things. All the work would be in .NET Core C# and the repo is at: https://github.com/ChicagoDave/izyuk.
The primary goal of izyuk is to replace the virtual machine model of current IF platforms and move to a database model. “Game Files” would be deserialized versions of the graph. The graph would contain everything needed to run the story, including grammar, language, world-model, actions, and events. The “Game Runner” would be a C# program that loaded the DB into memory. A second in-memory database would contain player commands and turn-by-turn results. This would likely be a simple key-value caching mechanism.
A graph implementation of a world-model and other artifacts makes sense. One of the things that can be done is to alter what is “in-scope”. Instead of calculating what is in-scope during turn-execution, graph commands could explicitly calculate scope for every object in the graph based on “senses”. Senses are the obvious ones, but authors could add new senses (magical ones).
That’s just one of the scenarios that might be improved in a graph database. I’m sure there is a laundry list of such things.
If anyone is interested in pitching in, drop me a note or reply with questions.