When I was first working on Inform 7, one of the things I was a bit skeptical about was the map index. Yeah, it was cute, but did I need it? As a real IF designer, wasn’t I perfectly capable of keeping my own notes and maps? And wouldn’t it perhaps exert an undue influence on designers to use a square-grid map, just because that’s what indexes best?
The latter point may be a fair complaint (though at the same time I am kind of in favor of comprehensible map layouts). But I was totally wrong about the first point. When I wrote the early speed-IF version of Bronze, I was able to put it together quickly only because I could add rooms, refer to the map, see where the holes still were, add, recompile…
Primitive as it is, the graphing ability of Alabaster is proving reasonably useful too. The graph isn’t especially pretty — I don’t know whether I’d get something better out of Graphviz than I can get out of OmniGraffle and a .dot file — but it conveys a lot of useful information. In particular, it’s possible to glance at the graph and find bugs that might take hours of testing to detect in the game. Colored nodes show where conversation dead-ends. Lines that go to the wrong places show where some connection has been screwed up in the system.
The main problem is that this image is (a) insufficiently eye-candy-ish and (b) too big. With Alabaster we’re approaching 300 conversation quips, and I suspect we’ll exceed that number before it’s done. Which isn’t really surprising — that’s about on a scale with Galatea, and though Alabaster has fewer avenues of conversation, each individual one can be pursued in more depth, so the balance comes out similar. I think this will turn out to be a fairly normal, not-at-all-extraordinary size for a conversation game. So clearly the fact that the graph is getting ugly is a problem.
I’ve been thinking on and off about what I want to do about that. I’m eager enough to finish primary coding on the game that I haven’t gone off to investigate new graphing options — the current graph provides enough diagnostics to do what I need it for — but I’ve been thinking on and off about what I think it a conversation-visualizer should look like and do in an ideal world. The fact that Processing 1.0 was just released has also been affecting my thinking. Wouldn’t it be neat to be able to view a conversation tree as a dynamic structure, something you could zoom into or away from; or to be able to pull one piece of the conversation tree away by itself to view it in more detail; or to switch visualization modes and instead see a chart of which facts and subjects were most important, or which quips functioned as gate-keepers by providing access to large portions of the rest of the conversation tree? In fact, mightn’t such a tool actually be useful for optimization problems too (since it would make it easier to discover where the conversation tree could profitably be broken into chunks for the purpose of limiting the search range)?
But I’m focusing on finishing the primary coding, oh yes.