What would you say is the no. 1 reason that someone should look at
if-frameworkover Twine? Is it a desire to use TypeScript, for example? Or something else?
I can’t really decide between Svelte and Typescript, but I guess Typescript is a bit better for me personally. Reasons:
- Instead of having to play the game, a mistyped variable is immediately caught by the editor with nice red squiggly lines.
- Typescript enables more editor support, like variable name completion and function parameter types
- Most editors should also display the documentation for any function or variable. You don’t know how long I’ve scrolled through the SugarCube docs… It takes me 16 scroll wheel turns to go from one end of the sidebar to the other alone…
Reason for Svelte:
The Twine story formats are nice to write in… as long as what you’re doing is supported out-of-the-box that is. I made a character editor in Sugarcube, and because the macros aren’t reactive, I had to manually run an update function every time I changed a variable that set the raw HTML via jQuery… Not a nice developer experience.
In contrast Svelte is build with reactivity, you have stores when variables can be changes outside of the component, but as long as you change them inside the component, Svelte magically inserts the needed update code for you.
It works even better than I though, I didn’t think the local and global variable passages in my example would work, especially the automatic save on input change. For that I had to help Svelte a bit though: It only re-runs reactive statements when it sees they contain the changed variable, and since the save code doesn’t need it I added a simple if check that’s always true.
If you compare if-framework to Twine, I’d aim it to be a more modern (the example has Babel configured to transpile the code to support all browsers within the last 2 years, so you can use all moderns JS features) and feature-rich alternative to Snowman (e.g. I provide a saving system, and something similar to the checkpoint system of Snowman happens automatically on passage transition: A save is stored in the browser’s session storage, where it can survive page refreshes).
The thing I have which I wish all Twine games had: Offline support. Maybe I should make the service worker for that and the updater available to Twine users, that’s a pretty independent part of if-framework. You can just drop the service worker file and config wherever you deploy the story and the updater block in the story JS and it works. The updater checks for an update on each page load, if you increment the version field in the config the service worker caches all files again, sends a signal to the page and the updater displays a nice notification on the bottom right to refresh the page. The refresh then loads the new version. As a bonus that also enables your story to be installed as a PWA on supported browsers (pretty much everything except Firefox desktop). You can see that in action if you play my Cloak of Darkness port: Chrome displays it as an icon in the URL bar on desktop, click it to install it as an app.
Smart move to include examples, include a conversion of CoD, right off the bat. I wish I had been as smart!
I just made a post asking what I should use to test the engine, and Cloak of Darkness came up.
As one “alternative to Twine” author to another well done on building & releasing something. Also, welcome to the world of being the massive underdog in a one horse race
What alternative to Twine have you made?
Edit: Nevermind, found it on your profile. So, what’s your number 1 reason someone should look at Rez over Twine?
I also noticed you made a post about it in “Authoring → Other Development Systems”, maybe I’ll make a post there, too, once I have it a bit more polished and ready for actual users.