#7: Hosting on Your Toes

by Shannon Appelcline

November 2, 2000 - Last weekend I met with five of the Skotos Seven and taught them how to use StoryBuilder Toolkit. With all those game designers gathered together, there was a huge amount of brewing creativity – it was quite invigorating. Even cooler, it allowed me to begin to see the shape of the future Skotos community, with a large set of games rising up where there's now only one.

In some future column, I'd like to talk about how our developer interface works and our plans for creating a huge community of games. If our vision comes to fruition – in the next two years or so – we'll have created the premiere roleplaying site on the Internet, and it'll be amazing. For now though, I'm simply writing myself a note on my list of possible future columns because, as usual, I've got a bug in my ear ... and I want to get the darned thing out!

The Role of the StoryHost: Fact or Fiction?

I've written quite a bit about StoryHosts. You can read some of our basic ideas about them over on the StoryTellers page. I've mentioned them on occasion in this column as well. StoryHosts are those folks who keep our games running after they've been built. In particular, they play NPCs and move forward plots.

I've written quite a bit about StoryHosts, but I'm still not sure exactly what they do. I've had lots of ideas, sure. I'd been kind of envisioning them as engineers. They take the blueprint that's laid out for them – a plot or an event – and then build what's on that blueprint. Easy; no fuss, no muss.

That's actually a pretty far cry from what really goes on. In real (virtual) life, there are all these things that get in the way. Annoyances like player free will and game systems that might not do what you expect. The engineer was actually a pretty bad metaphor. A StoryHost is really a juggler, trying to keep lots of pretty colored balls up in the air, and the whole time some damned archer is shooting arrows at him.

And this was all made pretty clear to us last week.

Thursday evening there was a duel between Armsman Roland and the duelist Eduoard. I don't want to spoil our story arcs, but I think I can safely say that we had some specific plans for how things were going to turn out. We had certain outcomes that we were planning for and certain plot points that we wanted to get across. We didn't know how things were ultimately going to be resolved, since that depended on player response, but we knew at least the first three or four steps of the path.

Unfortunately, we were cruelly betrayed by the dueling system. It did some things that we didn't expect and before we knew what had happened we'd ended up with a wounded Eduoard stumbling around the Castle. No matter what we might have planned for that Thursday night, this was not one of the expected outcomes.

I'm going to pause for a second and let you in on a dirty secret. I play Severin. You know, that annoying, cynical, and obnoxious apprentice? That's me. I was playing him last Thursday when a wounded Eduoard and a terrified Faer were suddenly dumped in my lap. I'd been expecting a simpler role that evening – something to the tune of "He's dead, Jim" after the duel to the death was finished. A bleeding chest wound just hadn't even made my itinerary for the evening.

I stood around stunned for a few minutes. I wasn't the only one, as anyone who saw Eduoard's state immediately following the duel can attest. Around me, there was a cacophony of demands from the other StoryHosts: "Have him die slowly", "Have him explode, like Roland", "Let him live." I felt fairly paralyzed. How was I supposed to provide a good diagnosis of Eduoard when we couldn't decide what the outcome was supposed to be?

Slowly, stumblingly, we made do.

Eduoard finally dragged himself off to the duelist's room and we StoryHosts managed to decide what should happen. I gave my diagnosis. He was unusually weak, but would live.

Time began to move forward again. Eduoard's sword was confiscated and a hoard of players swarmed down upon Launfal's office. There was blame and recriminations.

It was a great evening.

But I think we all gained a new understanding of just how much improvisation is required by StoryHosts. The plots never work just like you expect them. You can't even depend on the computer to do what you expect. Just like a tabletop gamemaster – perhaps even more so – you need to be ready to make split-second decisions, and that's complicated by the fact that you're working with a group of other people, trying to sketch out one consistant reality.

So, this week my advice is for StoryHosts. It goes something like this:

1. When you're working with multiple StoryHosts, try and designate a central StoryHost – the person who'll be making decisions when things go awry.

2. Whenever you're acting as a StoryHost, be ready to improv on a moment's notice.

3. If you see another StoryHost improving, and you're StoryHosting too, do your best to support that person's improvisation. In-scene, it's critical to create a consistant reality. Afterward, you can work out the repercussions for your game as a whole and figure out how you want to direct things long term.

The Obligatory Bug

The bug I'm going to talk about this week isn't that terribly funny, but I think it highlights a weird world view that we're required to have here at Skotos. It's entirely bizarre what you have to discuss when you're trying to create a virtual world that's a pretty good estimation of reality.

Would you believe that we've discussed whether or not you can take off a shirt while wearing handcuffs?

Would you believe that we've discussed the pluses and minuses of various bulk systems for describing compact critters like armadillos versus non-compact critters like porcupines?

Both true.

Last Saturday I was taking a rest, sitting down for a few minutes while the Skotos Several were building objects using our development system. One of them looked up from his computer and said, I quote:

"I can't eat a detail."

Take that out of context, imagine it being said by a gentlemen at a Dunkin' Donuts, and tell me you wouldn't promptly head in the other direction.

In case you're heading in the other direction right now, let me take a second to explain: most objects in our games have details, which are intrinsic, unremovable parts of the object. Our developer had created a table which had three details: legs, a tabletop, and coffee stains. He'd marked the table as edible, and then tried to eat the coffee stains. No go. He could eat the table itself, but not that brown caffeine stain on the wooden surface.

The scary bit is that there was no pause, no misunderstanding, no lack of comprehension after those words were uttered.

It all made perfect sense.