I almost posted about this a few weeks ago, but then didn’t really like the way the post came out, so killed it. But Chris’ post over here made me realize I’m still curious, if anyone feels like answering:
What is the biggest thing getting in the way of finishing and releasing your favorite WIP?
(In my case: I need to finish and release Alabaster before I go back to working on the older, bigger piece that relies on the same conversation extension. Which I guess could loosely be translated “lack of focus” or “bad habit of thinking that I can whip out small projects in between working on big ones”.)
So I’ve been working more on the Alabaster graphics — really the main thing that is still left before release.
(Re my complaints back here, I think I have fixed the very worst speed hangup with optimizations in my own code, and then David Kinder has awesomely put in some work that will lead to the acceleration of all Glulx games produced by I7. Graham and I have discussed some further optimizations in the way I7 handles relations that might streamline the behavior of the underlying conversation library yet further, but that will have to wait until later builds of Inform. I am hopeful that the result will be something that remains usably fast even for fairly large games. As I suspected, that involves approaching the problem at all three levels — terps, I7, and the individual library.)
Anyway, about the graphics, I’ve been thinking more about what graphics should do in this game, and about what I like in successful uses of graphics in other IF.
The remaining significant work on Alabaster consists of building the graphical status line on the left side of the screen. My original idea was that this image should give hints about Snow White’s current state of mind (or your state of mind about her), by showing her with different expressions. Daniel Allington, who is contributing the line drawings we’re using, offered a considerably more interesting suggestion:
What if there were just half-a-dozen freehand line drawings that were then collaged in different ways? (eg. zoomed in, zoomed out, combined with other images, superimposed, folded in on themselves, washed-out, erased, over-written, etc.) Cropping the same images in different ways to achieve the 1×4 ratio would be another way of using them to contribute to the storytelling. I like the way that collaging and re-collaging can create continuity – a bit like the illustrations in City of Secrets, incidentally.
I really liked this idea that the status line would be procedurally developed and dynamic in the same way that the conversation itself is. Besides, this idea allows for considerably more movement and change in the window than if we were sticking only to literal-minded facial portrayals. So I’ve been working on some code to place, zoom, and superimpose the images that Daniel sends my way.
There’s a lot of work still to go in order to get the diversity of effects I really want to see here, and a certain amount has to be done by creating effects in Photoshop rather than applying them procedurally in Glulx (given the narrowish set of graphical tools Glulx provides), but it’s coming along.
One of the fun (or, depending on how you look at it, annoying) aspects of polishing an IF game is working on the disambiguation. This usually involves combing through beta transcripts and seeing where the tester plainly meant X and the game instead understood Y. Sometimes the fixes are trivial things — you left out a synonym, you didn’t set a pronoun at the right time, etc., so the code didn’t have all the information it needed to make the right determination.
The more interesting cases are the ones that challenge you to think more deeply about how language normally works, though, and come up with sensible working rules about what the player probably means.
A lot of my recent work on Alabaster has been to tie together plot threads from different contributors and try construct something that produces a coherent narrative. I’m a little nervous about this process, since I’m doubtless taking some of the contributions in a direction that the contributors didn’t expect; if anyone objects wildly, we can talk it out in the beta-stage. But I think I do now have a viable, consistent story and plot structure.
This level of organization is impossible to capture on the conversation tree, because some of the outcomes depend on other actions than conversation. So I need something else — another kind of chart — and this one can’t really be automatically generated from the game source. Here it is drawn by hand (though note that if you click through to the full thing it will necessarily be a bit spoilery):
Diagram of significant outcomes in Alabaster
Currently there are 18 ways the plot can end. Dashed lines indicated endings that aren’t fully implemented yet (so you can’t actually reach that outcome); a number in a box indicates that I’ve written a test command to test it. The ending test commands are named things like “end-1”, “end-2”, and so on, so one can go through and try all of them. The colors of the outcome boxes indicate how likely the player character is to survive that ending. Red endings kill you instantly; orange endings indicate that long-term prospects aren’t great; yellow endings are more optimistic. The one green ending doesn’t kill you at all, but it’s not optimal for other reasons. So the best endings from the story perspective are the yellowish ones down at the bottom center-left; they take the greatest amount of plot-traversal to reach, which (I think) is as it should be.
It’s possible that I would be able to autogenerate a puzzle and completion map if I were using Aaron Reed’s Intelligent Hinting extension. Since that explicitly tracks puzzles and the relationship between them, one might be able to create a .dot file for that as well. In fact I did a little preliminary experimentation with the idea, using Aaron’s hinted implementation of Adventure. It partly worked, but it wasn’t as clear as I would have liked; I think I was misunderstanding how he was using some of the relations. Nonetheless, that is something that could probably be done given some effort.
Something that’s always necessary to think about in a replayable plot where the player is unlikely to get the “good” outcome the first time around: how do we indicate after a failed playing what he should go back and do in order to get a better outcome?
Partly one needs to leave enough clues in-game that there are other options one hasn’t pursued, but I think a certain amount also depends on the hook-iness of the writing of the unhappy endings. They shouldn’t just be generic failures; they should be interesting failures that give enough information to reward the player for reaching even that far, while improving his understanding of the world and giving him some new directions to try once he gets back into the game. So the chart helps me think about this: in particular, a negative ending should point at the next thing the player could have done to get a more interesting outcome. Endings 1, 2, 3, and 6 could leave some hint about waking the hart. Endings 4 and 5 should suggest that there is more to know, that you didn’t find out everything from Happy after all. And so on. It’s pretty unlikely that the player will wind up hitting all the less-optimal endings before getting to the better ones, but I’m hoping that consciously structuring things this way will provide more impetus to keep going.
Shamus Young has some interesting comments on parsing in IF and how he thinks it could be improved; Mike Rubin has a response. Partly this comes down to an argument in favor of juiciness in IF games, with some crowd-sourcing ideas for how to accomplish that juiciness. Eric Idema’s ifrotz project seems actually fairly relevant to all this, since it looks as though it might enable some of the things Shamus imagines, in terms of group testing.
This is all potentially valuable. It touches on only part of the quality-assurance problem, though, as this year’s comp crop reminded me. We tell authors to have their games tested thoroughly and to give themselves lots of time for the testing process (all of which is good advice), but in my experience it is difficult even for diligent testers to get a game up to an ideal state of polish if the author hasn’t done a certain amount of anticipation to start with.
Emily Short's Interactive Storytelling 