Unscientific survey

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”.)

Speed, speed, speed

Lately I spend a lot of my time wrestling with performance issues under Glulx.

This is partly because most of what I’m working on is, in one way or another, a test of the big conversation library I have in progress, and this is necessarily very code-heavy. But if I’m wrestling with it, that’s not good, because it means other authors using it are likely going to have to do the same — and they may have less patience with the problem, or just find that the whole thing is too irritating. For small projects, the system works fine, but for Alabaster (ca. 250 quips now) even after a fair amount of work, there is a 1-3 second delay on a lot of the moves. That is Just Not Okay.

There are three points of attack here, as I understand the problem:

Optimizing Inform so that it compiles code that will run faster. Several things have come out of my (or other people’s) performance problems in the past — Graham has sped up pathfinding and handling of large “Instead…” type rulebooks, and our recent conversations might conceivably lead to speeding up the performance of object-based rulebooks (which are one of the key pieces of the conversation library, since every piece of conversation has to be consulted to see whether it can be said at the moment).

Optimizing my own source. I’m working on that: finding more ways to cache needed information, minimize the scope of loops, etc. (And, since I mean this to be a released extension down the road, figuring out how to give authors of other work help optimizing their stuff, where those optimizing tricks cannot be folded into the core library but require some per-game customization.)

Speeding up interpreters so that any speed problems that remain are minimized for the end-user. Here Git seems to have a clear advantage over its competitors, but I haven’t had luck so far building it for OS X. (That might be because I have no ****ing idea what I’m doing. I am not exactly an old hand with gcc.) Has anyone else had luck with this? Is there an already-compiled OS X Git (using the latest, January 2008 version of the code) out there that I just don’t know about?

It looks as though Git might be what’s under the hood in Spatterlight (at least, Spatterlight seems to play faster than Zoom, at least a bit) — but if I actually open the Spatterlight package, it doesn’t list Git, only Glulxe. And I don’t see anywhere within the Spatterlight application to find out what version of interpreter it’s using. Which I guess doesn’t matter too much if it does, in fact, play faster… but this is all kind of mystifying.

More About Beta-Testing

Reading through the author’s forum from the recent comp, I ran across some discussion of how mean/unfair reviewers can be; this is no doubt true, though it is also true that people get irked about having their time wasted by a game from an author who didn’t do (what they consider to be) due diligence in writing the thing. It’s a fine balance. (And no, the purpose of the comp is not to encourage newbies. Not as such. It may do that, which is fine, but that’s not the mission of the competition. I tend to think that it’s about producing more cool IF, and in a context where that IF gets noticed and talked about, both inside and outside the community.)

Anyway, the particular bit that caught my attention was this:

Certain reviewers seem to imagine that hoardes of willing beta-testers drop out of the sky at the slightest mention that you’re working on a game.

I kinda wonder how much time these reviewers have spent beta-testing people’s games?

Harry Wilson aka Conrad Cook

Actually, lots of the reviewers have put in significant testing time. This is part of what makes them so sensitive to all the ways in which a game can go wrong. Beta-testing is itself a lesson in game design and implementation: you get an up-close view of what can go wrong and how someone else goes about fixing it. But second: if you are having a hard time finding testers, ask people. You can post a request on RAIF or join the IF betatesting site, but if that is not producing enough feedback, go on ifMUD and find folks; or approach people individually by email and say, “Hello, would you please test my game?”. It helps to include some basic information about what kind of game it is — and, perhaps, an explanation of why you think that person would be a good fit and/or might enjoy doing it. (This latter part is optional, but it might help if you’re addressing someone you haven’t worked with/talked to before at all.)

Sometimes people will be too busy, and will say no. But it’s not wrong to ask. People are much, much more likely to say yes if you ask them specifically and personally than if you put out a general call for volunteers. (Later on when you’ve written some games that people know are good, putting out a general call for volunteers may turn up more testers — but by that point you may already have a team of people you like working with, and not need to do that so much anyway.) Some authors have a rule of seeking as beta-testers the very reviewers that were most harsh on them last time, but that’s certainly not obligatory (and heaven knows you may find it’s more to the point to work with a beta-tester who is sympathetic to your basic vision but has high standards of craft).

Finally, the community expectation in general is that beta-testers will not diss your game in public, will not disclose the errors they found, and will not distribute a pre-release copy; and conversely that you will credit your beta-testers in some way in the finished game. (An ABOUT or CREDITS verb is usually used for this purpose.)

But when all is said and done, it is not unreasonable for players to expect that the game you offer them has been through testing. If you haven’t tested it, you haven’t finished it. If it’s not finished, don’t submit it. It’s that simple. Seriously.

A Halloween Experiment

One of the things I am hoping my conversation system will facilitate is a collaborative approach to projects, in which one person is in charge of managing the code while others contribute content. To that end, I’ve put together a little collaborative authorship experiment.

I’ve written the beginnings of a one-scene, one-NPC game. (Best to keep this simple to start with.) You’re invited to play with it (and look at the source code, if you want). It’s part Snow White, part Halloween story. (Check here for the latest posts on this project.)

If you come to a point in the conversation where you want to say something but your chosen dialogue is not implemented, the system will invite you to write your own dialogue, and will ask you some questions about how that dialogue should fit into the existing scene. It will generate the appropriate source code and store it in a file called NewConversation.glkdata, in the same directory with your game file. If you email that to me, I’ll compile it into the game and release a new version (and add you to the author list). My theory is to do this for about a week (until Nov. 3), then stop accepting new entries, put in some endings based on the conversation directions that emerged. (Though probably I won’t do that Nov. 4. I expect to spend election day obsessively refreshing CNN, and I’d be lying if I claimed otherwise.)

I’ll also welcome any feedback about how well the system works and/or how confusing you find it to use.

It may be that this doesn’t prove very interesting to people, but that would also be useful feedback — if no one wants to participate in projects like this, then at least I’ll know that supporting them isn’t a top priority!

Anyway, if you want to play along, the opening game is here. (It does require indexed text handling, so you will need a recent Glulx interpreter.)

I Should Have Gone to Business School

In the thread developing on Inform 7 and TADS 3 over here, one of the things that is coming up is that VMs other than the z-machine are at a bit of a disadvantage attracting players, and thus at a disadvantage attracting authors who want to reach those players. (And, for that matter, that some of the tools themselves are better ported to Windows than to any other platform.)

I’ve been giving a lot of thought lately to the question of how as a community we might fill in some of our most significant implementation gaps: better, multimedia-friendly TADS 3 interpreters on non-Windows machines, browser-based terps for both TADS 3 and Glulx, and so on. (Selfishly, I would also be pleased to see a TADS 3 Workbench that installed easily and ran natively under OS X. I7 is likely to remain my main language, but I would enjoy educating myself better about TADS 3; booting over to Windows is enough of an disruption of my other workflow, though, that in practice I never do that. I can’t call myself the primary audience for such a thing, but I think it would be great if one existed.)

Continue reading “I Should Have Gone to Business School”

The aesthetics of IF languages

I don’t intend to get into a(nother) flamewar with Steve Breslin, but he’s said some false things about me recently, and some provocatively semi-true ones about IF languages and the state of IF discourse. Though what follows starts out with some newsgroup politics, it winds up as some more general stuff about language design and what I consider the strengths and weaknesses of Inform.

Continue reading “The aesthetics of IF languages”