I’m making a CYOA engine for my game idea because Twine doesn’t please me. But before I commit to a minimum of 2 years of intense development, here are my goals and aim:
Offline static website
Highly accessible, as a main focus
Source code is linearly written with very minimal markup
Fully customizable, can run arbitrary CSS/JS inline, no major hoops
I already do a lot of this, but who satisfies these goals? Most likely accessibility is the biggest qualifying hurdle for engines today who see it as an afterthought, e.g. Atrament from what I saw of the demo (and that is an otherwise promising engine!)
Does anyone do it all? If not, any other good mentions? Thanks!
You might want to check out ChoiceScript and Squiffy, but neither of them allow for inline JS/CSS from what I remember.
I’ve been using Rez and it’s great for simple and complex choice games alike. You can package whatever JS or CSS libraries you want with your games. It’s about as programmer friendly as it gets and has been under active development for quite a while now.
If you really want bare-bones, you can use iffinity. It uses EJS (get a VS Code extension for it) as the main syntax so you can mesh CSS and JS together seamlessly into your content. Though it hasn’t been updated in a while, the last version works fine. I never had a compilation error when I tested and used it.
Both developers for Rez and iffinity are super nice and professional.
It sounds like you just want to make you’re own engine though. Maybe that’s your passion and the game is an excuse to make the engine… and that’s okay too.
Ink is general-purpose enough that you could fairly easily make a template/custom front end for Ink that supports these goals. “Offline static website” and “source code is linearly written” are both supported by default, and it’s pretty agnostic about the front end so I think the accessibility would mainly be limited by your own web design ability. I’ve done both inline CSS and inline JS in Ink, with minimal custom JS that I would not describe as “major hoops”.
This would be more involved than using an engine with a complete front end built in, but much less work than building something entirely from scratch.
You mention Atrament, which is already a front end built on Ink. If you find Atrament “otherwise promising” but want a more accessible front end, then you can probably get most of the promising parts from Ink directly.
Squiffy does let you inline JS - any section or passage can run JS, you just put it at the start and indent it with four spaces.
For inline CSS, text is just Markdown so you can include HTML with style tags. I guess outputting whole style blocks would work too for updating styles - not tried that though.
Thanks, pointing out status quo helps a lot. And it’s the golden path almost all the time, so contributing to existing engines is probably the best method, and just getting used to the minor syntax quirks I don’t like, as long as they actually support what I need.
I will say how it goes. So far, I’ve got inline HTML and JS by overriding marked.js parsing of codeblocks, and fork links by extending markdown hyperlink syntax, and it works, so it’s pretty yummy. Accessibility built-ins are mostly done, and that chunk is extensive.
I’m mostly just writing a story with it now and finding edges to smooth. If it ends up being worth competing with the 9999 interpreters that exists, I’ll make a post one day
