Introducing iffinity, a new minimal IF engine with iffinite possibilities!

[HAL9000]

First off, glad to have you back, Sotiris!

Thanks for the in depth reply. Lots of good stuff to digest!

iffinity is a programming framework. It’s not an IF authoring application. Things can get complicated beyond expectations in a browser environment (as you illustrated). As I’ll explain in a bit, iffinity doesn’t necessarily enforce any particular way of presenting a game so it’s totally understandable restoring a game is outside the scope of iffinity.

---

@MightyPigeon

…I had no idea Twine supported that out-of-the-box - what story format are you referring to? I’d like to take a deeper look.

I’ve only really used Chapbook and Harlowe (both do this “auto-restore on refresh” thing). Chapbook would be my suggestion to look at. I found that it’s easier to look under the hood in Chapbook’s GitHub repository. It’s built by Chris Klimas @klembot who also built Twine (so he would definitely know all about this refresh scenario). Chris also built Snowman.

---

Kind of unrelated…

In addition to saving/loading the game state JSON (which I haven’t done yet either), I may implement storing the innerHTML of the entire page because if game logic alters any HTML content after the snippet is drawn, that information would be lost/unknown to the game state as well. (You could rebuild everything manually upon restoring… but HTML is just a text string that describes everything anyway. It seems like the easiest thing to do as long as the string length isn’t ridiculous for a browser to handle.) To my knowledge, no Twine story format does this innerHTML save/restore thing, though I am not familiar with SugarCube (the most popular Twine story format for intermediate/advanced authors).

I do like to make things difficult apparently.

[MightyPigeon (Sotiris Niarchos)]

Very interesting remarks.

I’ll definately check both Chapbook and Harlowe to see how they implement this (I’ve only used Snowman to be honest).

Storing the whole innerHTML is a nice idea, albeit a bit “hacky”, in the sense that you must make absolutely sure that restoring the HTML leads you to a stable state. In my previous game which had a ridiculous amount of state management and logic, I generally tried my best to abide to the following 2 rules, which I list here in case anyone else finds them interesting for their own projects/design processes:

1. Make sure that the game state at the beginning of each snippet is stable and reproducible i.e., given the specific state you can “load” the game from this snippet without any problems and be able to continue from there (crucial if you want to implement a full-fledged save/load mechanic for game).
2. Try to make state changes snippet-changing or, if that can not be done in your particular case, try to figure out whether these changes really need to be reflected on your “global” state or whether you can keep a smaller, “local” state for your snippet and then, when the “big” change comes, change the snippet (and the actual, global state).

These are just rough guidelines that I try to adhere to because I feel they make my life a bit easier, by turning (the beginning of) snippets into well-defined checkpoints.

@HAL9000, I’d be really interested to see whether you make something interesting out of this innerHTML-caching idea. Also, keep in mind that you can always use some kind of compression - there are numerous JS libraries that implement these and also in Snowman, when you save your state (similarly to iffinity), it doesn’t return a JSON but an encoded string. I also thought about doing the same in iffinity but, again, that would contrast its main idea: it should offer the basic functionality (“here’s your state as is”) and then you can do whatever you want with it (compress it? cache it? etc).

[MightyPigeon (Sotiris Niarchos)]

So, I was thinking about whether iffinity should incorporate some kind of mechanism to ease the handling of multimedia (sounds, music, images, GIFs, etc), and I would love to hear comments/feedback on this from this thread.

I’d like to especially address @anon7585926 because I took a peak at their game Messages From the Universe Graveyard and I have to say it looks quite intriguing and well-polished (I hope the server-side has been working smoothly so far!). I hope to find some time in the following days to actually play it. For now, I took a very brief look and I also browsed part of the codebase, mainly to see how you handle your many multimedia assets.

So, would you feel that there could be a way for iffinity to maybe streamline the inclusion of multimedia (while following its main “philosophy” regarding simplicity and, as @HAL9000 nicely put it, more-of-a-framework-than-an-end-product approach)? While working on your game, would you feel that the engine, as you experienced it, could help you in managing your assets?

I’m specifically referring to @anon7585926 because of their game, but obviously the request for feedback is open to all!

[sandbags (Matt)]

Given that we’re working with multi-media content I took the view, when creating Rez, that handling of media assets needed to be built in.

So there is an @asset element to specify e.g. an image, sound, or movie file and asset_tag & asset_path filters for working with them in templates. E.g.

  @asset foo_image {
    file_name: "foo.png"
  }

  @card with_image {
    bindings: {img: #foo_image}
    content: ```
    ${img | asset_tag}
    located at: ${img | asset_path}
    ```
  }

Would generate the appropriate <img /> tag with width & height (we get this data when we compile the game) and display the path to the asset in the compiled game. The compiler also manages finding the image in the project and putting it in the right place in the dist folder.

The two drawbacks of this method are (1) you have to specify your assets in advance. If you had a lot of assets that might be a pain, and (2) each asset has to have a unique file name.

With those caveats in mind I have found this makes media really easy to work with and enjoy not having to muck about with file paths.

[jkj_yuio]

@MightyPigeon

iffinity should incorporate some kind of mechanism to ease the handling of multimedia

Absolutely! I would argue there is no point making a new IF system that didn’t handle media. Things like;

• pictures
• sounds
• ambient sounds
• animation (at least simple types)
• video?

Regarding pictures and sound, you don’t really have to support many formats. In fact you could just have WEBP for images and OGG for audio. In reality they are the best deployable formats in any case (at current time).

[MightyPigeon (Sotiris Niarchos)]

@jkj_yuio

I would argue there is no point making a new IF system that didn’t handle media

In principle I agree, but I’m not particularly sure whether that is required for the bare-bones approach of iffinity.

Let me elaborate on that: iffinity produces a single HTML file as its output. So, in principle, you can handle your assets as you would in any HTML: have the according tags (e.g. <img>) with the appropriate paths and just distribute the output HTML along with a folder with your assets. The question, then, is whether iffinity should:

1. Give you an automated way to do that (i.e., to create a dist folder with everything inside and handle the file paths, for example, or even copy them from all over your machine to the dist folder)
2. Provide any other tools or mechanisms (that I’m currently not aware of) that could somehow streamline the default asset-handling process that I described in the previous paragraph.

[jkj_yuio]

OK understood. In that case, it should automate the dist output as you’ve suggested.

I think a big problem with web deployment is managing the source media and the dist media. Let’s say your source images are large and in editable formats such as PNG. Your “publish” feature should convert those images to lower resolutions (with various options) and to deployment formats such as webp or jpg. And copy those into a dist folder with the appropriate paths adjusted.

[sandbags (Matt)]

@jkj_yuio

Your “publish” feature should convert those images to lower resolutions (with various options) and to deployment formats such as webp or jpg.

That’s an interesting idea that I hadn’t thought of. I could definitely build this in myself, although it’s annoying having dependencies on external binaries (one of the reasons I dropped Handlebars.js for my templates). But in this case I guess the fallback is don’t convert to a “deployment friendly” format.

[jkj_yuio]

What I’m doing now is converting my “edit” format images to a set of lower res ones with various compression factors. The web runtime chooses which one to fetch depending on what system you have. I also measure the time taken and adjust downwards accordingly.

So usually mobile devices have terrible bandwidth, so i jump straight to low res. Desktops are normally good, but it could be a laptop on a slow connection, so here i adjust down systematically.

Regarding depending on external tools, i completely agree. This is always the weak point. My plan now is to make the system also the tools. So the system itself performs this deployment process with no dependencies. Of course, the code to do this is only in the tools build version and not in the release runtime, to avoid bloating it.

[HAL9000]

@MightyPigeon

For me, iffinity seems practically complete already. When I started using iffinity, I had moved down the Twine path of Harlowe, then Chapbook and was just starting to learn Snowman. Snowman requires a level of coding competence that dealing with media becomes trivial. In it’s current state, I like that iffinity doesn’t get in the way or carry extra bloat that I will never use. I don’t even have to override any “built-in” CSS properties. It’s really a clean slate. So I think that’s why I enjoy iffinity so much because you developed it, and I came at it, from the same Snowman mode of thought. When you have a user that ignores the other story formats of Twine and wants to use Snowman… what does that tell you about what they are looking for?

I had a problem with Harlowe where running its built-in Harlowe listener caused flickering of other HTML elements. Even in Harlowe’s current mature state, problems arise due to the complexity inherent in browsers. I couldn’t use Harlowe after that, unfortunately.

There is a saying…

“jack of all trades, master of none.”

---

This is not to put down any desire to evolve iffinity. I’m just thinking that you should keep a version of iffinity that remains true to your current vision… and do it well. It might already be there, in fact. However, there’s nothing stopping a new fork or repository of iffinity…

There is a funny saying when we try to “outdo” each other. Like when we say, “I love you infinity.” And the other replies, “I love you infinity… plus one.” Maybe iffinity +1 is the more robust, user-friendly, media savvy app!

[sandbags (Matt)]

@HAL9000

I like that iffinity doesn’t get in the way or carry extra bloat that I will never use. I don’t even have to override any “built-in” CSS properties. It’s really a clean slate.

I think this is a brilliant summary of a use case.

[pinkunz]

GIF support would be nice. You can do a lot with some cleverly designed GIFs. My initial take on ADRIFT had the astronaut slowly spinning in empty space, with the sun lazying by his vision every few seconds. I built a whole GIF for this from scratch only to realize that the non-Vorple image support for Inform 7 can’t handle GIFs and I had to backpedal and actually rewrite a large chunk of the game late in the process due to this. My fault for not checking first, but, yeah, GIF support would be nice.

[anon7585926]

It’s really cool to hear you checked out my game! I personally didn’t have any issue managing visual assets, at least not on the level that I wished iffinity could help. It was easy to make an assets folder in the export folder, dump all my assets in there, and just refer to them with url(assets/examplepath.jpg) or whatever when I needed them.

@pinkunz

GIF support would be nice.

iffinity compiles to HTML, which being HTML, comes with built-in ways to display images and GIFs! And videos too, if anyone wants to go that route. It helps a lot.

Managing audio was more complicated for me. Not in terms of where it was stored (I just had a assets/music_real folder for everything), but playing it in-game. I ended up installing Howler for background audio, and then writing my own function to slowly fade out the the background track that’s currently looping and slowly fade in the new background track when you enter the appropriate area for it (code here). I’m not entirely sure it’s the most efficient way to do things, I think the way I have it loads all the looping audio at the start of the game even if most people will only hear a few tracks at best, though I could be wrong.

Still, I’m not sure how helpful it would be to add audio support. Sugarcube has a bunch of audio macros, though they’re more limited than Howler’s options, and still pretty complicated to set up the way you want once you get into it. If I remember right, they don’t have a macro for “slowly fade out the the background track that’s currently looping and slowly fade in the new background track”, so if you wanted to do that in Sugarcube you’d have to make a function for it anyway, using their notation.

I like the relative minimalism of iffinity since it’s far more customizable and lets you specify exactly how you want things. I only wanted background audio for my game, no one-time sound-effects, so I didn’t have to worry about adding in anything for sound effects.

TLDR: Adding more support for visual/audio assets wouldn’t hurt, but I’m not sure if I’d use it. It does depend a lot on how it’s executed, though. In general I agree with Hal’s preference for iffinity’s relative minimalism and don’t think adding new stuff is all that necessary at this point.

---

Things I did find myself thinking “this would be nice to have” while working on my game… Sugarcube has a <<replacelink>> macro (or someone made one and I put it in all my projects because I liked it so much), where you can click an element and it gets replaced with another element. I actually replicated that behavior with a function of my own (which is much jankier in practice), since I liked it so much. Maybe built-in support for something similar would be nice?

Two other things I made were menu panels that open when you click a specified element and automatically come with a close button, and code to add wrapper html around the iffinity snippet since I got tired of copy-pasting the same HTML divs (used for CSS purposes) around the unique contents of every snippet.

Even if those things didn’t get added, I could just use my own code for it. Anyone else could too, though they’d have to add the extra esbuild stuff that I’ve been using. Actually I ended up making my own iffinity template folder that has starter files and a bunch of extra stuff/modules I found helpful in my iffinity projects, and I should maybe put that on Github at some point.

---

Also, re: the refresh thing, I was thinking about Sugarcube which I’m pretty sure does this out of the box. It’s honestly not that important for me, though, since most browser games reset your progress when you refresh. Twine is more the exception than the rule there. And it is somewhat convenient, but still runs the risk of e.g. if you refresh on a page that increases a variable by 1, the variable would increase again (at least I feel that’s what would happen. Haven’t actually tested that kind of thing). It’s deceptive because it seems like nothing has changed, but if there’s complicated game logic it might disrupt the internal workings.

Glad to hear you’re doing okay! I wish you a happy Master’s-obtaining-experience and a less hectic schedule. Sounds rough out there.

[pinkunz]

@anon7585926

@pinkunz

GIF support would be nice.

iffinity compiles to HTML, which being HTML, comes with built-in ways to display images and GIFs! And videos too, if anyone wants to go that route. It helps a lot.

Sweet!

[MightyPigeon (Sotiris Niarchos)]

Thank you SO much for your input, it really means a lot, especially since you’ve made a complete game with iffinity.

I’m particularly interested in the things you mentioned that could potentially be supported by iffinity:

1. The <<replacelink>> functionality sounds nice for a built-in feature; maybe another iff-tag. I’ll open an issue for that in GitHub and will definitely come back to it.
2. Your issue with Howler was actually something I was thinking of but never got to deal with it. Obviously, an author may need external libraries. It’s what I tried to do with the library scripts/styles, but when doing this I was thinking of actually downloaded libraries, like a minified version of jQuery, for example, that would eventually be part of the output HTML. An idea here is to give an option of defining library CDNs in the config file, so that they are used directly when playing the game, with no need to download/pack them in the output HTML. The only drawback to this is that your game will then only work online, but I’m not sure whether that is an actual problem. There could even be a boolean flag offline in the config file and when that’s true, instead of appending the CDN(s) to the <head>, iffinity would actually download and pack them (as it already does with jQuery, for example).
3. What you describe with the menu panels and the need to wrap the default iffinity HTML is what I think could be described as HTML templates, right? I was actually thinking about it. The reason I didn’t directly do something to support this is because (for no good reason) I relied on using the tag system and the different levels of scripts to produce HTML via JS. I realize now that this is something that is neither user-friendly nor scalable. Correct me if I’m wrong, but I guess the idea is that you would like to have an HTML (sub)component (eg the HTML code for your menus) that should be part of some/all of your snippets, right? So I guess what iffinity could do about this is give you the ability to define such an HTML (sub)component and then declare whether a snippet should include it or not. In other words, a system similar to what is now being supported for code and styling, but for HTML (sub)components (or even redefining the very structure of the page under the <iff-story> tag in a template-like fashion?). Does this sound like an interesting way to go? Obviously not very well-shaped yet, but I’ll get there!

Looking forward to your opinions on any/all of the above!

[HAL9000]

@MightyPigeon

What you describe with the menu panels and the need to wrap the default iffinity HTML is what I think could be described as HTML templates, right?

When you mention HTML templates, I think of the interface design surrounding a <snippet>. Am I off the mark?

For example, in a JS file I did something like this…

( Click to show code... )

/*** INTERFACE CONSTRUCTION ***/
let _body = document.getElementsByTagName("body")[0];
let _interface = ' \
<div id="_top"></div> \
<div id="_middle"></div> \
<div id="_bottom"></div> \
';
_body.insertAdjacentHTML("beforeend", _interface);

/*** (!) MOVE <div id="iff-story"> INTO "_middle" ELEMENT ***/
let _iff_story = document.getElementById("iff-story");
let _story = document.getElementById("_middle");
_story.appendChild(_iff_story); // <== (!) appending an existing node MOVES IT to a new parent (associated JS variables and references still work)

[MightyPigeon (Sotiris Niarchos)]

Yeah, exactly. I may have made a mess before when trying to explain my thoughts, apologies. It’s a bit fuzzy in my head as well. In fact, it’s not a matter of HTML modules; these you can make as regular snippets and then just include them in another snippet via the renderSnippet method. Thus, the real question is whether iffinity should support altering the default HTML structure, in order to accommodate use cases like the ones you mentioned. I think it should; not clear at all how right now. I feel that “template” is the correct buzzword, but I’ll keep processing it and see if I end up with any concrete idea. As always, open to feedback/ideas/objections/whatever comes to mind!

[HAL9000]

I have to admit, I need to play around more with the iffinity API. After I posted, I thought about nested snippets too. To be honest, that is easier than what I did, but that just goes to show how many ways there are to skin a cat.

Eventually, after a few more games come from iffinity, I think a page from Twine can be taken with its Cookbook. (I linked to the first page of the cookbook.)

I like that it suggests basic logic practices, and fun things that might appeal to most authors. I think iffinity would benefit from something like this and, in a weird way, it would allow iffinity to remain bare bones, yet still robust because people could just copy and paste code from the cookbook.

If you think this would be a good idea, I’d be willing to help with that. For example, nested snippets to achieve a new interface design, how to handle audio, saving the game state JSON to local storage, changing a specific snippet when multiple exist, etc. These sound like good recipes!

[HAL9000]

Oh, I have another question. With <a> tags being the default rendering of link markup [[ ... ]], I find that I don’t like seeing the javascript:void(0) “URL” showing up in the browser window on hover. I’ve removed the href programmatically after it’s rendered in the browser and this works, but it no longer exists in the keyboard tabbing focus DOM list, though the link still works. The best way I see to get my desired result, keeping browser accessibility and screen readers in mind, is to not use <a> tags, but use <button> tags with CSS to make it render inline, like an <a>.

Question 1: Can I somehow edit the rendering of the [[ ... ]] markup to use <button> instead? …or should I just use my own HTML/JS and call the iffinity API as needed?

Question 2: Kind of related, can I somehow make my own markup (shorthand code) using iffinity’s method of replacing markup? Like, even if it was just HTML output and not doing any other internal stuff.

[MightyPigeon (Sotiris Niarchos)]

The Cookbook sounds like an awesome idea actually, and could also be a collaborative/community-driven project (dreamming big, I know, but why not ). I’ll definitely add this to my todo list. It could even be just a GitHub repo hosted via GitHub pages where people just add their own iffinity recipes. Thanks for the idea!

Answer to Question 1: Very good point and one I’ve also struggled with. Truth is, that is one of the few design choices that had to be made while building iffinity. The story goes that I just “copied” what was done in Twine/Snowman, where the [[...]] passage links where rendered as <a>. Nothing more than that, actually. I also didn’t like seeing this javascript:void(0) in my Snowman game (it happens there as well), but I didn’t give a lot of thought to it. You are right, though; it’s not nice.

To directly answer your question, unfortunately no, you can not edit the rendering of the [[...]] markup to some other HTML tag, at least not without using some (hacky) coding. But I agree that it could/should be changed. The reason I decided to stick to the rendering of <a>s for the snippet links was the way it is rendered in browsers by default i.e., as a well-recognized link (underlined, different color), which is actually a side-effect of the void href attribute. But I now realize that this again is a design choice that there’s no reason to take away from the author. But because buttons have a rather involved “default” CSS, I’m thinking maybe about <a>s without an href. In this case, they are still machine-friendly links, but with absolutely no default style imposed. So, that makes it the responsibility of the author to make them look like however they want, even including whether they want the cursor to turn to a pointer or not on hover (via CSS). Do you think that this is a better approach than using <button>s or is there any advantage that I’m missing? I’m trying to figure out the most barebones and customizable way to implement this, while still not breaking stuff (like the browser accessibility and screen readers that you mentioned).

Answer to Question 2: I’m not sure I get your question. Something different than what renderSnippet does? Can you maybe provide an example?