Today I posted the beta of Lectrote, a new IF interpreter application for Mac, Windows, and Linux. This is both more and less exciting than it sounds!
If you're familiar with the IF scene, you know that there are several applications which can be used to play these games. Zoom (Mac), WinGlulxe (Windows), and Gargoyle (multiplatform) are the most commonly used. And then there's Quixe, which is a Javascript-based interpreter used on iplayif.com and other web sites.
When I was looking to release Hadean Lands as an app, I found that none of these were really what I wanted. Zoom is unmaintained and buggy; WinGlulxe is weird about scrolling; Gargoyle has problems on hi-res displays. (I'm summarizing, it was a long messy story.)
Quixe had the UI that I wanted -- no surprise; it's the one I wrote the UI for! -- but it wasn't really meant to be used as an app. It exists as a web page, or a component of a web page. Also, it's slow. So I put it aside and went with Gargoyle.
However, the long messy story didn't end there! A few weeks ago I was gazing over the endless cycle of dev-tools and noticed Electron. Electron lets you wrap up a Node.js tool as a standalone app for Mac, Win, and Linux. And Node.js is, well, I don't really know what it is but it's a web thing. Seems ideal, right? Stuff Quixe's web page into Electron and we're done.
It wasn't quite that easy. Node.js has full filesystem access (unlike a web page), so I had to extend Quixe's load/save system to deal with ordinary files. (So you can exchange save files between Lectrote and other interpreters.) But that was still pretty easy. I stuck the IF postcard in a menu, too.
And now you can try it.
So what does this have to do with getting Hadean Lands onto Steam? Well, it's a very simple tweak to drop a Glulx game file into Lectrote. Then you've got a Mac/Win/Linux app that plays a single game. And it looks nice and the text layout is pretty and you can adjust the font size without editing a text file.
I haven't done that yet. I'll have to adjust the menus -- knock out all the support for opening multiple games.
More important, I'll have to add autosave. Right now, if you're playing a game and you close the window, your game is gone. Hope you typed SAVE! That's okay for an interpreter (used by IF habitués), but it's not ideal. It's really not acceptable for a Steam standalone game release.
Autosave for Glulx games is a bit of a nuisance, but I got it working on iOS. I will get it to work with Quixe. It will just take a few more weeks.
...oh, and then there's the speed. I mentioned that Quixe is slow, right? It's faster than it was but it might not be fast enough for Hadean Lands. If you own HL for Mac/Win/Linux, try it! In particular, try loading a mid-game save file and typing a command which requires many stages, like GO TO BAROSY.
(If you don't own HL, may I remind you that it's on sale for the next two days? I probably don't have to. But I do it anyway.)
Anyway, I may try plugging a different Glulx VM into Lectrote to speed it up. I can probably run RemGlk/Glulxe as a subprocess of the Node.js server... We'll see.
For now, Lectrote is a multi-platform interpreter app which has the UI I want, and that's a good start.
Very cool! Looking forward to see how this evolves.
Nice! I tried out Electron and NW.js for a project a while back, trying to see which one I liked better. I found Electron's design to be quite a bit cleaner and more flexible at the time, especially where zero-window applications are concerned. (I was exploring video processing and didn't necessarily want a window open all the time.) I think Electron will serve this project well too.
It's nice how easy it is to adapt JavaScript code to various distribution models these days. Now if we could just compile JavaScript to the Z-machine... Kidding! :-p
Looks cool. I might look into the theme support, like a set of dark/light CSS themes for the player to choose from.
Yes, I want to add theme and font-choice support. I also want to add the ability to just drop in a new CSS file and use that. These options all kind of interfere with each other, though. :/
Funny, I just started an Electron project myself - it's a great platform, though there is some weirdness. But the Node ecosystem is very strong and full of useful stuff.
I do really recommend using Babel; at this point I'm not sure you could force me to write non-ES6 JavaScript.
We're up to release 0.1.2, by the way.
https://github.com/erkyrath/lectrote/releases
Does it have a maximum memory size coded in? I found with version 1.1.4 under Linux it failed like this when I tried to load Trap Quest (just the gblorb is 158MB, BTW):
49 ms: Scavenge 2.5 (9.0) -> 2.5 (9.0) MB, 1.1 / 0.0 ms [allocation failure].
93 ms: Scavenge 3.9 (11.0) -> 3.7 (13.0) MB, 0.6 / 0.0 ms [allocation failure].
171 ms: Scavenge 6.1 (14.0) -> 5.3 (14.0) MB, 1.5 / 0.0 ms [allocation failure].
258 ms: Scavenge 7.5 (15.0) -> 6.4 (15.0) MB, 2.7 / 0.1 ms [allocation failure].
298 ms: Scavenge 8.6 (16.0) -> 8.1 (20.0) MB, 2.0 / 0.0 ms [allocation failure].
==== JS stack trace =========================================
Security context: 0x17b2b7113a49
1: load_named_game(aka load_named_game) [/home/.../progs/Lectrote/Lectrote-linux-x64/resources/app/apphooks.js:~11] [pc=0x1a5dc38ef68c](this=0x23604cc04399 ,arg=0x257855142c71 )
2: /* anonymous */ [/home/.../Lectrote/Lectrote-linux-x64/resources/app/apphooks.js:263] [pc=0x1a5dc38e6a35](this=0xd2667c6d229
There is no memory size limit coded in, but there is a maximum memory size because of the way I am loading the game file. I don't know exactly what size it chokes at. Somewhere between Counterfeit Monkey (15MB) and 158MB, obviously.
I see you have found the bug report: https://github.com/erkyrath/lectrote/issues/76