Sunday, November 21, 2010
The techy post, part 4 of 4
So, here's the Glk and Glulx update plans for 2011.
One of the big gaps in my original Glk spec was in specifying fonts, font sizes, and other text display parameters. On the left hand, I wanted this to be a player preference most of the time. On the right hand, IF authors want to provide a nice customized design for their games. I came up with what I thought was a minimal compromise, but it wound up almost useless from the game author's point of view. (You can't specify a font at all, for example; font sizes are poorly specified and therefore inconsistently implemented; and so on. When I wrote Quixe, I skipped the font-style features entirely, because they weren't worth the effort.)
This has been on my "improve please" list for several years. However, the left-hand-right-hand tension I've described still exists. You see the same thing in web design and e-book design; each of these has reached its own compromise between author preferences and audience preferences.
I'm still not sure I know where the balance should be. (After several contentious discussions in the IF forums, nobody else is sure that I know either.) However, I know where I want to start, which is to let the author include a CSS stylesheet. CSS is the worst formatting system HTML could have used except for all the others, and that's what I want for IF too.
People are likely to already know some CSS, at least.
(You can already use a CSS stylesheet with Quixe; it is a web app, after all. Just edit the included CSS file. But I need to specify this in a way that all interpreters can approximate -- even those that don't have CSS engines available.)
Quixe graphics and sound:
The Glk spec has graphics and sound options, but I haven't implemented them. It just wasn't a first-release milestone. Many IF games use Glulx solely for the extra memory space, but some (e.g. Emily Short's Alabaster) make good use of graphics, and there's no reason a web browser can't handle them.
There are some reasons that it's a hassle, though -- having to do with the way we package IF games and graphics data.
Also, Inform 7 isn't as efficient about its compiled code as it could be. Real CPUs have surged way ahead of IF complexity in the past thirty years, and that gave Inform room to be, well, a little bit slack. Nobody noticed -- as long as they were running native-code interpreters on modern machines. But when we started porting interpreters to cell phones, and web browsers, and microwave ovens, then the inefficiencies became visible.
I want to approach this cautiously. It can't just be a free-for-all of manipulating Quixe internals; that would be a horrible quagmire in the long run. And we do want other interpreters to support these features (where possible).
Glk already has the notion of a rectangular image pane inside the game UI. If we extend that to allow HTML/Canvas/SVG panes, then most interpreters will be able to support them by embedding WebKit or other HTML widgets. So this is possible; but again, there are hassles of packaging to work out.
If you watched Get Lamp you heard from several blind or visually-impaired IF fans. I've always wanted my IF interpreters to be accessible, but I don't know much about the mechanics of screen readers -- I've just assumed that it could be made to work.
We've had some discussion on the topic in the past few months; see this blog post, for example, and this forum thread. I need to go over Quixe and figure out what work it needs.
This will also apply to the iPhone app, too. (If you have not yet, you should read Austin Seraphin's post about getting an iPhone. He was in Get Lamp, the guy talking about not needing a lamp.)
This comes up in two distinct use-cases. First, the ever-sounding siren song of multiplayer IF. This has been tried in various ways (all the way back to MUDs, and more recently Guncho, which is a MUD-like assemblage of Inform 7). But if the game itself had the ability to open (and listen for) network connections, we might get some new angles. (Perhaps go above the TCP layer, and leverage some existing social or gaming network?)
Second, access to web services. Could an IF game usefully query Wikipedia, Wordnet, or your local weather for in-game effect? Maybe.
Assorted random features:
An IF game should be able to read the system clock -- either to display a real-time clock, or measure how long the player has been doing various things.
An IF game should be able to normalize Unicode lines of input text. (If you know what Normalization Form C is, well, we're currently not doing it.)
There are some restrictions on line input that I need to loosen. (These have to do with whether the command line can be cancelled or edited by the game as the user types. It's not a feature of most games, but occasionally it's desirable.)
A way to define whether display panes in the game UI are separated by borders. I've only been promising that for about ten years now. (This ought to be handled by CSS, but boring technical reasons may prevent that.)
I could be doing plenty more, beyond those ideas. Brand-new fully-modern virtual machine? Fill out the rule-based programming language that I've been thinking about since before Inform 7 was released? Finish the kung-fu ninja game?
I'm trying to keep some boundaries in place, though. I intend to sleep occasionally. Maybe go outside once a month.
Post a Comment