I have developed a sixth sense about scams and consumer technology disasters on the internet. Let someone, me, who lost $185 on a fake Q*bert wiring harness scam provide guidance. This is never going to exist.
We also already had the word “Ink” mean something in the text game space, so the person(s) involved either didn’t know or didn’t care. If that account ever posts about the project again, I encourage simply setting money on fire, rather than get involved in this thing. Or I guess you could just leave it in the bank, either/or.
Folly’s a fun proof of concept. How well it works for folks in practice seems to depend on how similar their handwriting is to mine or the twenty or so folks I could find in freely licensed datasets… there weren’t (aren’t?) any good open-source handwriting recognition models available so I had to work something up from scratch.
I still think IF on eink makes a ton of sense, and I’d love to see more projects in the space. OTOH I do think that the interface needs to be pretty fundamentally reworked for that sort of platform, and it’s not clear to me that the person behind this is on the right track yet. Will see how it evolves!
Not having an e-ink device, I’m ignorant of what sort of formatting doesn’t play well. Do you have some examples? Is it italics? Bold? That sort of thing? Or the colours/underlining on links?
“Formatting” was probably not the right word; I guess “styling” would have been better. But no, things like bold/italic/underline aren’t a problem.
Basically, what you want is very simple styling of the sort that would print easily on and look good on actual paper. There are some things choice IF often does that are at odds with this:
Most e-ink displays are monochrome, so using color to indicate things or make text stand out is a no-go, and contrast issues can be exacerbated.
Super lightweight fonts like the one Ink’s default styling uses don’t read well.
The displays aren’t designed for white-on-black/light-on-dark color schemes (which is probably the thing that takes out the most substantial chunk of games).
Color graphics don’t look good, and if they’re not just decorative and you’re supposed to be getting some kind of information from them, they might render badly enough to make that difficult. (I think even on a color e-ink device, they’ll still look less than great if they’re not designed for color e-ink specifically, but I can’t personally vouch for that because color devices are expensive and I don’t have one).
E-ink devices also have a slow refresh rate and are prone to having lingering traces of whatever was displayed previously, so any kind of text effects/animation/screen transitions can cause problems, as can graphics that change frequently. (Even ebook apps don’t always take this into account, much to my chagrin, but that’s a different story.)
I have to admit that I’ve never tried to create an “e-ink friendly” version of the CSS for my own games, so I’m not sure how much of a pain it would be to do overall. (Although maybe I should try it, so that next time I get a migraine close to a comp deadline I can test on my Boox instead of turning my screen brightness all the way down and hoping I don’t mess myself up too badly.)
E-ink displays are low-resolution, mostly monochrome, and refresh slowly. (I understand that there are color ones now, but they cost more.) The project page described using a monochrome 7.5-inch screen, 800x480 resolution.
(For comparison, an iPad Mini has a 8.3-inch color display with 2266x1488 resolution.)
Aside from color, any text formatting should be fine on that sort of display. You do have to think about how much text you can display at once. Three or four long paragraphs will fill that screen.
The hitch (literally) is refresh time. Redrawing the screen causes a noticeable delay. Even moving a cursor will feel laggy. So any system that relies on animation is right out.
I would think that ChoiceScript and Ink (language) games would be doable on that display. For ChoiceScript, you’d have to think about UI for displaying the stats block on a small screen. (Perhaps a dedicated “switch to stats page” button.)
Twine, well, Twine is a bunch of formats which are hard to separate from their Javascript implementation. I suspect that you could create a format translator that converted a Twine format into a non-JS, non-animated data structure that would then work on an e-ink interpreter. (This isn’t too different from the Twine-to-printed-book translators which I think exist.)
Reading the above two messages makes me think the sort of Twine to PDF process that I use for CYOA books is exactly what you need for e-ink displays. They also assume that state tracking is something user takes care of (if it’s needed) rather than the display device, so they would work fine on the sort of e-readers that can’t run other software.
Right. Except that the e-ink tablet software can do state tracking. You just have to translate the Twine logic into some format, and then write the tablet software to deal properly with that format.
Yeah, I think choicescript and ink should transfer fine. You’d still want take some care with the interface design… probably choosing lightweight, minimially-animated UI and oganizing text into pages that fill from top to bottom instead of scrolling like most modern interpreters do. (So the only text you need to refresh is the text that changed, instead of the full screen.) Not totally dissimilar to what you’re doing generating PDFs, presumably.
The additional challenge for parsers is that typing tends to be painful, since latency is so high. The handwriting recognition in Folly was one way to deal with this problem.
Admittedly I’m on record complaining about default Ink’s super-light font weight and low-contrast link text even on regular screens, but I do think they’re worse on e-ink and would want to see that addressed. I suspect default ChoiceScript would be fine right out of the box, though!
FWIW, I regularly play Z-code and Glulx games on a jailbroken Kindle 3, and the experience is delightful even with the slow refresh rate. This only works because it has a built-in keyboard, however, and no one has made an E-ink reader with a built-in keyboard for years.
My Pangamebook script can be used to generate static EPUBs. I am never going to look into adding JavaScript to support hidden state tracking, as most EPUB readers lack support for that anyway (plus I want books to be static text!).
There has been some discussions on this forum in the past about adding state to a static book. It could be done by adding some mark-up for “set flag” and branching on “if flag” later. A script could analyze the graph to duplicate nodes automatically, as needed (only nodes that can be reached both with and without a flag would have to be duplicated, and only for nodes that have a path leading to some node where the flag is checked). So an EPUB could track that the player picked up a key earlier in the story when they encounter a locked door. A bit wasteful perhaps, but solves the problem without requiring any read-time scripts in the book.
I did some design on an algorithm and mark-up for that, but never got around to implement it.
One of the Twine Discord users was working on a story format to generate such a game, with the intent of allowing a book that essentially tracks choices in the manner you describe (which is very much like the original CYOA books, which never merged paths). I don’t know the current state of the project, but it had definitely got as far as producing at least one sample game.
