[ANN] GemIF - Simple Interactive Fiction engine for Gemini

[Norm MacLennan]

On 12/2/20 10:28 AM, Nick Thomas wrote:
> I recently got sucked into Stay: https://ejadelomax.itch.io/stay -
> which is built using a not-web-specific IF engine called Ink: 
> https://www.inklestudios.com/ink/
>
> While reading up on the language, I did find it quite gemini-like.
> GemIF looks interesting, but I'm curious what you think of the ink
> approach, and whether a gemini exporter (like the existing web
> exporter) for the existing editors would make more sense? If not, you
> might find the language used by Ink more compelling than a  yaml file.
>
> I do find myself thinking that it would be fun to play Stay on Gemini
> rather than the web ^^.
>
> /Nick

Hey Nick,

I'm not familiar with Ink, but it looks pretty cool.

I haven't looked into how the project is persisted on disk nor how
exporters work, but I bet making an exporter for simple Ink stories into
a Gemini static site would be possible. But it looks like Ink has some
more advanced features like conditions and variables which wouldn't lend
themselves to a static site format and would require a server to keep
track of gamestate (where I assume the web exporter does everything
client-side with Javascript).

In that case, unless I'm missing something, a Gemini exporter would
basically need to scaffold and generate the entire server for each story
- at least for stories that require conditions and variables. In which
case it might make sense to build a pre-made server to be the engine and
just generate configuration for the individual stories to keep the
exporter relatively simple. Probably you can see where I'm going with
this, but once GemIF has rough feature parity with Ink it might be
interesting to look into making a GemIF exporter that generates the YAML
from your Ink project.

But I haven't really looked into the structure of Ink projects or the
full feature-set beyond basic syntax to know what that might look like
or if it's even feasible. Maybe once I do I'll find a better
configuration format than YAML, cause I agree giant YAML files are the
worst. But I figured it was halfway between human readable and machine
readable and I could build some tooling to generate it from something
easier to read and maintain in the future.

Thanks for linking me to this, if nothing else it will give me more
prior art to draw from but potentially also shows a valuable integration
for the future.

Thanks,
Norm