March 5th, 2007


Lessons Learned

Every LARP-running experience features some lessons to learn. This one was no exception. The lessons included:
  • If someone says they really, really, really want to play a Jaegermonster, let them. The Jaegers in both runs were *extraordinary*, a major highlight of the game. (The trio in the second run were reportedly novice LARPers, and were better than most veterans I know.)

  • Do not try to move eight-foot-long tables of uncertain stability by yourself. Especially, do not do so by shoving them. Dropping the end of a table on the arch of your foot is not an ideal way to start a day of GM'ing. (Ow, ow, ow...)

  • Dumb casting luck can strike twice. I never thought I'd have a re-run of the Ozma case, but it did almost repeat. The player who was going to play my favorite character of the game (a high-angst, high-romance character with a 15 page character sheet) had to drop on the evening before game run. I almost just ran without the character, but dervishspin stepped up to the challenge. From getting that 15-page sheet 11 hours before the game and knowing nothing about the comic, she came in the next morning, costumed just right, and *nailed* the role. It was a delight to watch.

  • Rocket-powered golf clubs do *not* make a wise demonstration example for Spark mechanics. The universe is listening, and has a wicked sense of humor.

  • Mostly, I determined that not only are adaptation games a bit harder than normal ones, adapting an ongoing, non-episodic story is quite a bit harder still. Oz might have been using other peoples' characters, but at least we had the entire L. Frank Baum corpus in front of us, and knew exactly how much freedom we had to embroider. (Quite a bit, given how internally inconsistent Oz is to start with.)

    But you have to fit a Girl Genius game inside an ongoing story, one where only the Foglios really understand the details. Worse, all evidence is that they *do* know many of those details, and just haven't told us yet. So I had to start with three months of simply evaluating everything that we knew, to figure out where my opportunities to invent were. And it's still likely that at least 80% of the guesswork in the story is just plain dead-wrong. (Although I still hold out hope that my Skifander backstory is at least partly correct -- that was pulling together lots of hints, so I think it's plausible.)
Overall, a good experience, and the game will probably get cleaned up and re-run at some point down the road. But it's good to get to the end of the process, and let out all the steam that's been building up and driving me forward for the past couple of months...

inames -- Threat or Menace?

One of the hot new ideas in the Identity space is the notion of the "iname" -- an identity indirection that serves as a wrapper for your email, URL, phone number and whatever else. You register for an iname, and that gives you a handle that you can pass around (eg, "=jducoeur"), via which people can contact you indirectly, without necessarily exposing your actual addresses or getting rigidly bound to them.

And my reaction to this whole thing is, "This is a good idea why?" It's yet another more or less flat namespace (exactly as hierarchical as DNS, far as I can tell). It's yet another namespace that seems to be open to squatting. It's still dependent on brokers. It seems to be exactly as good as DNS, in pretty much every important respect.

Honestly, I find the whole idea daft -- it fails to solve any of the interesting problems, and seems to be very much yesterday's technology. It adds a layer of complexity for no obvious benefit. (Unlike systems like OpenID or CardSpace, which have their flaws but are at least adding new and useful benefits.) I am completely failing to understand why otherwise-sensible people seem to be enchanted by it. Can anyone explain the attraction to me?

Everything I needed to know, I learned from Kent Beck...

Sometimes, the programming background comes in handy in surprising ways. For instance, today I am finding that the engineering discipline of "Get your damned ego out of the code" is proving very useful. One of the hardest engineering practices to learn, and one of the most important, is the ability to step back from your code and look at it as if someone completely unrelated to you had written it, so you can objectively examine its flaws without feeling crushed by them.

The game being over, it's time for a really critical re-examination of it. It was good enough that I think I will eventually want to re-run it, but not so good as to let me re-run it in its current state. I'd personally give the game a solid B overall -- good, but could use work. My take on it (having really a very limited view as a GM -- the players probably have a much clearer idea of what happened than I do) is that about half the characters and plots are pretty solid, a quarter or so are good but need refinement, and maybe a fifth should be scrapped/rewritten. Which isn't bad, but can't be brushed off, and if I don't write it all down now, we'll simply forget.

So as part of wrapping things up, I'm taking extensive notes on what to change for next time. I encourage all players to send me commentary of what you liked and didn't like in the game, and (more importantly) what did and did not work. Please do that privately, so as not to spoil things for people who haven't played yet. If you'd like to respond to this posting, I've turned on screening so that you can do so here; I'll unscreen any comments that seem to be relatively spoiler-free...