Look Through Telescope

Yesterday I summarized the problem: The existing delivery systems for interactive fiction (a.k.a. text adventure games) are mired in the 1980s. The early 1980s. Today I’d like to toss out a few ideas about what, ideally, ought to happen in order to bring the presentation of IF forward into the 21st century.

Broadly, there are two ways to move forward: either a massive extension of an existing authoring system, or an entirely new system. Both courses are fraught with difficulties; neither is a stroll in the park.

Let’s take a brief look at the characteristics such an authoring system would, ideally, have. The list below is not intended to be exhaustive — I may have left something out. It’s intended to serve as a starting point for discussion.

1. The games produced using the new system should be playable, and with an essentially identical appearance and functionality, in MacOS, Windows, Linux, and mobile platforms.
2. Convenience for the end user should be emphasized. The user should not have to download and install separate interpreter software or a self-contained app.
3. The authoring system itself should be available on all three desktop platforms, and without too great compromises in terms of utility. (No use of a command-line compiler should be required in one OS, for instance, if it’s not required in another.)
4. The author should have broad-based, fine-grained control over typography, layout, on-screen activity, and embedded media.
5. Only one programming language should need to be learned.
6. The authoring system should include a decent library that implements a modern world model and other IF essentials such as save/restore, undo, and transcript collection; it shouldn’t just be a raw programming language.
7. The author should be able to choose, implement, and modify a player input system as needed — command prompt, clickable links, pop-up and drop-down menus, whatever — or combine two systems, or (with more effort) invent and deploy something entirely different.
8. The programming language and authoring system should be well documented.

Criteria 1, 2, and 4 would seem to indicate pretty conclusively that the delivery system will need to be based around a standard Web browser. Really, given the limited amount of development time available within the IF community, no other course seems feasible. So Javascript will be involved in some central way, whether or not the game author knows or cares about it.

As far as I can see, there are only two practical possibilities: Either IF authors buckle down and learn Javascript (not impossible, but not a charming idea either), or the new system will need to utilize Inform 6/7 or TADS 3 as its authoring back end.

Going straight to Javascript has a few points in its favor. Javascript is well documented, excellent extension libraries are readily available, no compiler would need to be written, and the game author would get direct access to all of the presentation tools that Javascript provides. Technically, Javascript, HTML, and CSS are three different languages, but they’re so intertwined that we can consider them a single language with respect to criterion 5.

Alternatively, a new game delivery system could be built on top of Inform or TADS. I’m not sure exactly how this would work. From the authoring side, such a system might look exactly like an Inform 7 extension: The author includes it and uses the new syntax it defines, and the extension takes care of the messy details of producing … some sort of output file, which would then be run in the Web browser in some manner (either client-side or client-server).

This is an attractive idea. The I7 IDE and I7 world model already exist. (The same can’t be said of T3, unfortunately, as its IDE is Windows-only.) But writing an I7 extension that would expose all of the presentation features of Javascript/HTML/CSS to the author would hardly be practical. At best, an extension would “pave the road.” It would provide some sort of basic, default presentation in the browser, which the ambitious author could then customize as needed using Javascript. Possibly Javascript code could be included within I7 code using a syntax similar to what is used now to include I6 code. The methods that Inform authors would need to use in order to do such customization would have to be fully documented, in such a way that the Inform author (not, in most cases, an experienced programmer or proficient in Javascript) could use them.

On top of which, a game delivery engine would have to be created that would take the Inform output file (which might still be vanilla glulx) and run it in a new manner in the browser. Maybe time and energy could be saved by basing the new engine on the code in Quixe; I don’t know. The Inform IDE would have to be reorganized somehow to allow a game produced using the new tools to be displayed in the game panel, and the skein would surely need to be changed as well, in order to keep track of a game that was being tested in the IDE using mouse-clicks rather than typed commands.

The development process would probably be easier with TADS 3.1, thanks to its WebUI features, which already exist. If you select Web delivery for your project, T3 will produce a game that can function as a “virtual server.” The player’s browser talks to this virtual server, receives responses, and outputs the responses to the screen. (So far, so good.) By default, the WebUI produces a traditional command-line interface. Apparently you can customize this as needed using embedded Javascript — and knowing what a brilliant programmer Mike Roberts is, I have no trouble believing that the possibilities are mega.

The difficulty, and it’s a deal-killer, is that there is no documentation on how to use the WebUI. None. If you want to do anything other than a standard command-line game, it’s up to you to study Mike’s .html, .css, and .js files and figure out what to do. Learning TADS is already complex enough that very few game authors ever tackle it. Add to the equation the need to learn another layer of complexity that is undocumented. Then (a note for programmers) add the fact that Mike seems to have put all of his JS functions in the global namespace, which is not best practice, because it could potentially cause problems with 3rd-party Javascript libraries that you might want also to employ. On balance, I would have to say that the WebUI is unlikely to be the wave of the future. There just has to be an easier way.

On balance, I lean toward the idea of starting from scratch and developing an IF world model and other IF utilities (save/restore, etc.) in Javascript. This method has, at least, the virtue of simplicity. The author would have to learn Javascript, but could then do all of the game development in one place, rather than having to use Inform or TADS for the basics and Javascript for the fine-tuning and customization. The team developing the new authoring system would only need to do one thing — build an IF engine within Javascript — rather than two or three (create a large, complex Inform 7 extension, write a new Javascript-based interpreter that would be able to process the code created by the extension, and revise the Inform IDE so it could run the new interpreter).

I’m not a good enough programmer to do either of these things by myself. At best, I could function as a team leader — recruiting a couple of programmers, doing a little fund-raising, and so forth. Maybe I’ll do that. Have to think about it for a few days first. If you have any thoughts about all this, I’d absolutely like to hear them!