I missed this earlier, but:

  1. Make an “admirable” game in the system (not just a technology demo). Historically, the first “admirable” story for each now-successful IF platform was typically either written by the platform authors themselves, or directly funded by them. (Twine’s first admirable story by Anna Anthropy is the only exception I’m aware of.)
  2. Make it work on the web, and especially on mobile web. People keep sending around systems that only make games that work on desktop PCs; this is especially bad for IF systems developed in Python. (It’s even more rare to have a game development system that lets you develop on mobile.)
  3. Make a tool, not just a language. “You can implement your game in any text editor” is not as appealing to IF authors as some people seem to think it is.

Gruescript has checked all of those boxes.


Nothing about Graphic and Sound? Even with Inform, people keep asking about showing graphics, maps or otherwise. Certainly Twine features graphics as well.

As far as Tools go, I sense there’s a preference for Graphical Tools. Even mapping, where it used to be just index cards suffice.

That’s an interesting point! I recommend that @robinjohnson port Detectiveland fully to Gruescript, including graphics and sound and whatever else would be required to make it work.

(I assume that today you’d have to do that with the js “cheat” command…? But anything Detectiveland does should be doable in Gruescript without cheating.)

1 Like

Interesting problem. As soon as you’re telling Gruescript to refer to something external like an audio file, or an image, or a font, the author is going to have to upload their music/images/fonts somewhere. This probably also means they’re going to want to do their development offline. (Unless Gruescript, and the games it produced, lived on a server that they could upload the music/images/fonts/ to… which I’m not doing.)

I could put in some commands that play a sound or show an image, using a relative url (probably declared in the header-ish “game block”.) My reservation is that I have trouble knowing what someone without a technical background is going to think of that. As you’ve said to other tool creators, nobody’s going to learn technical skills in order to use my system. As soon as I write “put your files at this relative path, and set your browser to allow local file access, and develop offline” in the manual, suddenly it feels like I’ve made Gruescript less accessible. And the people who could do that can probably do it anyway by saying raw HTML, or cheating with js, or just hacking around in the exported file.

Maybe the answer is to make those commands and document them in a technical appendix. Hmmm.


I would definitely recommend adding those commands.

As for how they would work in the tool, the ChoiceScript IDE “solves” this problem by asking the user to login with Dropbox and synchronizing files with Dropbox. You can then provide a UI to upload an image that just drops the file in the Dropbox folder; when running the game, you serve it directly out of the Dropbox. When exporting the game, you can generate a zip containing all of the files, or you can a single-file HTML file containing all of the assets embedded as data: URIs.

EDIT: Dang it! I opened Detectiveland one too many times today and now I’ve got the Main theme thoroughly stuck in my head.

baaaaah DOP! bah, bah-du bah-du bah-du bahhhh DOP!
bum BUM bum bum, bum BUM bum bum …


Harry, the .ne./.ge. you cite is the logical IF, the one I cited was the arithmetic IF, now deprecated (don’t ask me why, but I have around 1960s Fortran IV/66 listings…)

Best regards from Italy,
dott. Piergiorgio.

1 Like

The latest update (github diff) adds the conversation system used in most of my pre-Gruescript games. I’ve rewritten the “NPCs” example to use it.

I believe this makes Gruescript, if not quite Detectiveland-feature-complete*, at least Zeppelin Adventure-feature-complete.

* although you could add manual CSS styling and abuse say to include multimedia stuff