Zarf Updates

I've been bemoaning the slightly run-down state of IF interpreter software. (The confusing font preference system in Gargoyle is just one example.) The fact is that the big surge of open-source IF activity was the late 90s and early 00s. Since then, coders have been drifting out of the community, and the ones still around have gotten lazy. (I include myself in that indictment, for damn sure.)

As a community, we do not have a tradition of mentoring and fostering new contributors to IF projects. All of our projects were made by people (most often solo developers) who got excited and wrote a whole application or library.

I like to think that we've got a good software stack, which smooths the path a little. You can write an Inform extension or a Glk library port or a Glulx engine core or a Parchment web service, and it will fit into the ecosystem. But it still starts with a person showing up with enough energy to start, build, and finish an idea. If someone shows up who is curious but not committed, we nod companionably and wait to see what happens. The results, over time, are predictable: activity slows down and stops.

With that introduction, you'd expect me to go on and talk about mentoring. But I don't know anything about mentoring. I'm one of the control freaks! I'd rather work on my own projects than collaborate.

Anybody want to think about community-building? (Hopeful look around...)

(Of course a lot of my projects are specifications and tools that interoperate with other people's code. So I kick myself in the ass and make it happen. But my natural talents do not lie in management.)

In this post, I'm going to talk about my plans as a solo IF tool developer. Warning: I will also talk about money.

---

I have a whole list of things I think Need Doing In IF (see footnote) but the one I intend to tackle next is Glk 2.0. This is pretty much the same Glk 2.0 plan I've been planning for years, but since it's been years, not everybody may remember it. (Or perhaps you remember it with bitterness and loathing, in which case I apologize.) In any case, I will explain it from the top.

The plan is: integrate Glk (the Glulx VM display layer) with CSS and Javascript. That is, you will be able to distribute Inform games with custom stylesheets and special display effects (see Vorple).

Why CSS and Javascript? Because they have already conquered the universe, so we might as well give in to our anger and rule at their side. Also, the most commonly-used IF interpreters are written in Javascript, which makes adding these new features trivial. (If we plan correctly.)

So how do we approach this? I'll admit up front that this plan isn't complete. This is a sketch; I have parts of it worked out.

The basic idea is to define a canonical HTML representation of Glk output. Or rather, a canonical DOM representation. (The DOM is the internal data structure that a browser builds when it reads in an HTML file.)

Currently, the Glk spec describes output in terms of windows, text, and text styles. The new spec will explain this in terms of HTML <div> and <span> elements, and the CSS classes for each one.

I don't mean that your Inform code will output HTML. For simplicity, and to maintain a clean separation of concerns, the Glk calls in the Inform library will remain the same. You'll set a style and print some text. The interpreter's job will be to either translate those calls into HTML (as defined by the spec), or do the equivalent job of text display.

Nor do I mean that interpreters will have to support every crazy CSS trick that Firefox is capable of! Far from it. The idea is this: whatever display capabilities the interpreter does have, let CSS guide where it's used.

It's easy to misunderstand this. Let me lay it out in an organized way.

• This is a change to the way the interpreter (Glk library) manages the display, not a change to the way you write your Inform game.
• • But there will be some new capabilities available for Inform games. Mostly this will be about letting you use more styles.
• The display of a stock Inform game will not change much. Any changes will be in the direction of more uniformity between interpreters.
• This should not require interpreter maintainers to rewrite their code from scratch.
• • Javascript interpreters (Quixe) will work by generating HTML information and shoving it into the browser display. This is how Quixe has always worked. I'll just have to add the CSS and make some adjustments.
• • C interpreters (Gargoyle, WinGlulxe, Zoom, Floyd-bot, etc) can continue to work the way they work, by calling OS-native text-display calls (or use SDL or telnet or whatever). However, to decide on text display attributes for each style, they should start using CSS information. I will provide a library to make this easy.
• • Alternatively, C interpreters could switch over to HTML display. That is, they could throw up an OS-native HTML widget and shove HTML into it, just as Quixe does. This is optional, but it has some advantages -- see below.
• The new plan will initially be available through an I7 extension. I expect that some future I7 release will make it the default.
• What new features does this plan give us?
• • A game author will be able to include a CSS stylesheet with the game. This will customize the way the interpreter displays the game.
• • A player will be able to select a CSS stylesheet as an interpreter preference. This will customize the way the interpreter displays the game (overriding the author's stylesheet if necessary).
• • There will be some way to display more and fancier styles. I know we had an argument about this a few years back; let's not restart it in this post. I haven't nailed down the details anyhow.
• • A game author will be able to include a Javascript library (or libraries) with the game.
• • • For HTML-based interpreters, the Javascript will be loaded into the browser page (or HTML widget). It can then perform arbitrary display tricks. Glulx Vorple can be built on top of this.
• • • For interpreters which do not have an HTML layer (i.e. old-style C interpreters), Javascript tricks will not be possible. The game will have to degrade gracefully or give up.

---

Where am I with this plan? Not very far. Even after all these years.

I have a roadmap. I've just finished step 1. It will be a few steps more before anybody else has to start writing code.

1. Write a simple, dependency-free C library to parse CSS. Done! I thought this would be a weekend hack; it actually took many days of work, because CSS is just as horrible as every other Web technology. (No, I didn't search for prior art before I started hacking. Who do you think I am?)
   
2. Nail down the HTML representation and the Glk API changes it will require. Think about how it affects all existing interpreters.
   
3. Update GlkTerm to the new model. GlkTerm is a terminal-window library (it's built on ncurses), so it can only support a few text attributes -- boldface, underline, ANSI color. This is enough for a proof of concept.
   
4. Update Quixe to the new model. (And jQuery, while I'm at it.) Quixe is an HTML-based interpreter so it will allow the full range of CSS and Javascript fireworks.
   
5. Write the I7 extension that enables this stuff.
   
6. Write a lot of demos. (Not just to show off! Demos will let other interpreter authors know they're hitting the mark, display-wise.)
   
7. Update RemGlk and CheapGlk.
   
8. Unleash my reign of terror upon the world.
   

Easy, right?

---

You can reasonably ask how long all of this will take. Especially since I laid out much the same plan at least five years ago, and then again three years ago, and I've just managed to finished step 1.

Well, Hadean Lands is done. That's a big carcass off my plate. Also, for this semester I'm spending one day a week at MIT(*) and that's a nice regular schedule for working on the project.

(* But not this week, because it snowed some. And the Red Line caught fire or something.)

It's still a lot to promise; enough that I feel queasy just posting this post. I hate making promises that I don't keep.

Thus to the subject of money.

Post-HL, I would like to work more on open-source IF tools. I would also like to work on indie games that will pay the rent. (HL does not pay the rent in the long term, despite the stellar reviews I got this month.) There's also contract work and so on. Life balance, it's hard.

One way to converge these interests: find a way to crowd-source IF tool work. But this is not an easy model. It's not a Kickstarter -- it's ongoing work, not one big deliverable. It's not exactly a Patreon, because I can't give backers early access or bonuses. (But some people try this anyway?)

I'm signed up for Gratipay, which started as a tip model for GitHub users (but now supports any developer). I haven't publicized it at all; despite this, somebody is giving me 33 cents a week. (Thanks!)

Are there any other patronage systems which you folks think I should investigate?

(Note: I am not asking for money at this time! I'm thinking about ways in which I might ask for money in the future.)

I realize this is an awkward subject. Many people support IF software. I don't want to be The One Who Gets Paid while everybody else labors away for free. On the other hand, there's a lot of work that isn't getting done; this has been true for years. I can start to unstick this, but not to the exclusion of paying work.

Furthermore, the Glk 2.0 plan isn't the only thing on my plate. I'd love to get back to Tworld (the Seltani engine). I could dig into CocoaGlk and figure out why Mac Zoom occasionally crashes (and why Mac Inform 7 occasionally trashes my skein, and maybe why it occasionally eats somebody's source code...) I could spend some time experimenting with the rule-based language idea, zog help me.

What I'd really like is a patronage-and-voting system, where people could put money into different projects, with the understanding that the ratios determine how much time I put into each one. Does anything like that exist? (No I'm not going to build one.)

...Wow, this post has wandered in circles, hasn't it. A mix of plans, promises, positions, and pleas!

I guess I'm trying to figure out where the next phase of my life falls, relative to the IF community. I have taken stock, and this is what I see. Comments welcome.