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.
- 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.
- 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.
- 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.)
- The author should have broad-based, fine-grained control over typography, layout, on-screen activity, and embedded media.
- Only one programming language should need to be learned.
- 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.
- 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.
- The programming language and authoring system should be well documented.
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).
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.
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!