Tiny Quixe patch to allow injecting arbitrary Javascript

I was going through some old files, and found this tiny patch I wrote for Quixe (really, GlkOte) to let Inform games send arbitrary Javascript/HTML to the browser. I never got around to doing anything with it, but I figure it might be of use to someone.

In insert_text_detecting() in glkote.js, replace the line: el.append(document.createTextNode(val)); with:if (val.slice(0, 6) == '!html ') { el.append(document.createElement('span').innerHTML = val.slice(6)); } else if (val.slice(0, 4) == '!js ') { eval(val.slice(4)); } else { el.append(document.createTextNode(val)); }Now, you can inject arbitrary HTML/Javascript from Inform 7 like so:say "!html Test of <b>bold</b> text." say "!js alert('Hello world!');"This opens up endless possibilities. For example, you could build an elaborate HTML interface in play.html and update it dynamically with Javascript as the game progresses. A set of extensions like Vorple is another option, but this is left as an exercise for the reader.

I’m not sure that’s a good idea. It seems like it would thwart the goal of keeping the game contained in the interpreter and open up security problems.

It should be safe when you control both the interpreter and the game file.

But if anyone is thinking of publishing a game with this, you should ask Zarf to allocate you a block of Gestalt codes so that you can check whether you’re in an interpreter that supports it.

Well, you have a choice. You can use this kind of simple interpreter hack, and accept that your game is only going to be playable with that one interpreter. (Javascript; hard to download because scraping is a pain; probably no interpreter updates ever).

Or you can do more work to build graceful degradation. Then you have a game file which will work on “ordinary” interpreters, just without your cool JS effect. Dannii’s suggestion of a Glk gestalt code is part of this. (You wind up with a function that returns true on your hacked interpreter and false on all other interpreters.)

There’s no requirement here – you decide what makes sense. Maybe the extra work isn’t worth it. Maybe the cool effect is central and the game doesn’t make sense without it.

Is there an online tutorial explaining how to write an Inform game with arbitrary JS and graceful degradation? Seems like it’s coming up more and more frequently.

I imagine the use-case is similar to the spate of recent games like AlethiCorp or Detectiveland that use a custom HTML interface. It’s understood that these games will only work with the supplied HTML/JS files, potentially including a patched interpreter; this is a conscious design tradeoff by the author.

But graceful degradation is a concern. I think the simplest solution is to separate out HTML/JS with phrases like[code]Use HTML translates as (- Constant HTML_USED; -).

Use HTML.

To emit HTML (outstring - a text):
if the HTML option is active, say “!html [outstring]”.

To emit JS (outstring - a text):
if the HTML option is active, say “!js [outstring]”.

. . .

When play begins:
emit HTML “Test of bold text.”[/code]…and then compile separate versions with the “use HTML” option turned on or off, so users can download either a pure-Glulx blorb or a package containing the HTML-enabled blorb, patched interpreter, and UI files.

Or, you could go down Dannii’s suggested path of gestalt codes, which is more elegant; but since the HTML-enabled blorb would only ever be distributed with the patched interpreter and UI files anyway, it may not be necessary.

(Adding something like this to the interpreter mainline would difficult, for the security reasons David mentioned. But if you just need a quick way to connect an HTML front-end to an Inform back-end, it does the trick, and the patch is designed to be simple enough that it’s trivial to upgrade the interpreter in your package when a new version comes out.)