Refly (new IF platform) & izyuk (in-memory IF-oriented graph database)

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.

2 Likes

I find your approach to defining the game in a fluent interface intriguing and would like to subscribe to your newsletter.

1 Like

I so agree that focusing on a fluent interface and storing the story model in a graph data structure is the way to go! So much so that I’m also working toward those goals but using JavaScript. (I won’t hi-jack this thread by talking about it here though.)

Regarding the graph component, what do you suppose the fluent interface will eventually look like for making queries? What are the types of queries that folks would want to make in the context of IF? Does your graph implementation support weighted edges? For example, could you store the distances between cities and calculate travel time?

My experience with graphs comes from Neo4J, so allowing properties on both edges and nodes should be implemented. Given that, you could easily have an attribute between two nodes that offer “travel time” between two location nodes.

As for the types of queries, I don’t know. I haven’t dug into it that far since the entire graph-select logic breaks my brain. Hence the search for a technical partner.