#19: Hobgoblins, Part One

by Shannon Appelcline

February 1, 2001 – "Consistency is the hobgoblin of small minds." It's a well-known quote that derides our attempts to make order from chaos. It's so well-known, in fact, that one can just say the word "hobgoblins" and invoke an entire mood of displeasure toward careful organization, as Windom Earle does in one of my favorite television shows of the last decade.

It's a well-known quote, and it's wrong.

What Ralph Waldo Emerson actually said was: "A foolish consistency is the hobgoblin of little minds." What a difference a word makes.

And I agree with Emerson. Foolish consistency can just restrict creativity, but a certain amount of consistency is necessary, and I think that's especially true in online games.

Once upon a time, in a Silicon Valley far, far away, a single programmer could sit down and write a game en toto by himself. Time went on and games became more complex and soon you needed a team of people working on a project. Two or five or ten or fifty. Recently I read an article on Diablo II, which mentioned how they'd done a year of work beyond the point were they thought they were just about done, and I realized what a big task building games is nowadays.

And then there's online games. We had a team of about half-a-dozen people who worked on various parts of the initial design of Castle Marrach. But that wasn't the end of things. We've done considerable more work since the beta release, and if all goes well we'll still be doing work on Marrach five years from now.

A single programmer could be sloppy and not worry too much about whether his code was consistent, because he was the only person who'd ever have to look at it. There was a lot more need for consistency in the world of large programming teams, but you could still get away with being a little flaky, because you could wander around and tell people about your latest kludges. But in the world of online games, you have to be consistent enough that five years down the line people you don't know can figure out what you did.

That's a new level of need.

As a result I want to talk about consistency in the StoryBuilding process of Skotos games. There's two areas where consistency is of special interest: verbs and inheritance. This week I'm going to hit verbs and next week I'll move on to inheritance and expand the discussion into some more general areas of StoryBuilding. I'm going to talk a lot more in-depth about how our system works this week than I usually do. If that bores you, you should skip down to the bottom of this article, where I mention how inconsistency has caused real bugs in Castle Marrach.

For the rest of you, let me draw back the curtains a little bit and introduce you to The Wizard ...

The Problem with Verbs

You're no doubt familiar with verbs in online games. They're those imperatives that you invoke to make your alter ego do things: bow, smile, reply, state, etc. You're probably not familiar with the fact that implementing them in a text-dominant game can be a tricky thing. Traditionally there have been two ways that you could implement verbs in text-dominant games: globally and locally.

You'd find global verbs in DikuMUDs or Infocom games. As the name suggests, they're implemented at a global level. If you want to introduce a new verb, you dig deep into the code and program it in. Afterward the verb works everywhere, whenever the conditions are right.

How Global Verbs Work: Your players have been clamboring for the "sashay" verbs. You implement it and afterward everyone can glide about whenever they want. In addition, you've been quite clever, and you've flagged the new "sashay" verb as an "elegant" type of movement, allowing any NPCs anywhere in the game to react appropriately. The Queen might be impressed, the leader of the thieves' guild less so. Everything works everywhere.

How Global Verbs Don't Work: In the Maze of the Queen of Hearts there's a giant chessboard. If you "sashay" across the chessboard a tunnel is supposed to open up in the middle of the chessboard, allowing passage to the secret catacombs below. The only way to implement this is to go back to your global "sashay" verb and to write a special case for sashaying in the Maze of the Queen of Hearts. A couple of dozen secret passages later, and your "sashay" verb is a mess.

How Local Verbs Work: You create a wall of thorns that's hiding a cave entrance and decide that it can be burned away. You attach the "light" verb to the wall of thorns, so that if someone types "light wall of thorns" and they're carrying a torch, the thorns will be burned away.

How Local Verbs Don't Work: Another StoryBuilder creates a similar puzzle, where some curtains can be burned away to let light into a room. He attaches the "burn" verb to the curtains, so that if someone types "burn curtains", and they're carrying a torch, then the curtains will be toast. So now people have to play guess-the-verb to figure out how these two different puzzles work, even though both "light" and "burn" should probably work in both cases.

How Local Verbs Really Don't Work: As you'll recall, our local verbs don't appear at a global level, so when someone finds a torch in his adventures, he may try and type "light torch" or "burn torch". He sees "What?" in response. Neither verbs works outside of its very local constraint, yet we've given players the idea that the verb is actually understood by the system, when they're actually only understood in really specific cases. (To light the torch, the player might have to actually type "ignite torch", when, once more, all the verbs should have been OK.)

But verbs can also have specific local effects. We have a minor programming language called BILBO which can be used to make objects react to specific verbs. Remember the goblets from the Winter Ball that fill with wine if you tap them? That's a BILBO script. A local version of the "tap" verb is built into the glass so that it reacts appropriately, but since "tap" must also be a global verb it has appropriate effects elsewhere.

We can actually program verbs into people too, so that the BILBO script goes off whenever the person uses the verb in question. Remember the kissing curse, which caused someone to become mute when he was kissed by someone who was muted by the curse already? That was BILBO too (in an early form). The local definition of the "kiss" verb jumped from person to person.

So by combining the two systems, we fixed one major problem, but not another.

• Verbs will always work. You'll never get "What?" because verbs have to be created globally if they're to be used locally.
• But, we're still vulnerable to people making similar objects react to different verbs, as in my ignite/burn/light example above.

• Consider whether a local definition of a verb should actually be made global.
• Make sure that all of our local definitions match up.

In other cases, though, I'd just need to be very careful. Tappable wine goblets probably don't belong in the global definition of tap. So, I'd need to make sure that the verb "tap" was used for other similar local actions, and I might also need to allow more verbs than just "tap" to work if I did similar things with different verbs elsewhere (or, really, if any StoryBuilder in Castle Marrach does.)

As I said earlier, this is a lot more in-depth than much of what I write. However, if you end up StoryBuilding a game at Skotos, this will eventually be of concern for you. Let me offer one quick rule: Do generic things with global verbs; do specific things with local verbs, but do it consistently. And, let me also offer a more global idea: Be consistent in your game design.

Next week (unless something else gets in my way) I'm going to talk about inheritance, another major consistency problem for StoryBuilders, and try and expand the whole issue of consistency to a few more general concerns.

In the meantime, however, I promised a bug.

The Problem with Codpieces

In designing Castle Marrach we very carefully designed a bulk system. This is a system that sets out how big things are – width, depth, height, weight, etc. – and then takes appropriate actions based upon an item's size. This prevents you from stuffing swords into your belt pouches, and also ensures that fifty people can't jam into a room with a maximum capacity of twenty-two (which is greatly appreciated by the Castle Marrach fire marshalls).

We were very clever and created a bunch of formulas so that the system could figure out lots of numbers on its own, reducing the burden on the StoryBuilder, and we used metric, of course.

We managed to end up with a system, at least as its currently implemented, that isn't very intuitive. We have some slightly nonintuive variables (like "maximum frontal area") and the metric system is unfortunately nonintuitive to most of us Americans (and to some Europeans, as the recent case of the Metric Martyr shows). And this has caused inconsistency.

Some of the objects built for Castle Marrach have bulk data that's just plain wrong because a StoryBuilder didn't understand what one of the bulk entry fields really meant. And some have numbers that are way off, either because the StoryBuilder thought things were in English units rather than Metric or because he did his conversion wrong.

These errors became really obvious to us a few months ago when Ali Jahib made his first appearance in Castle Marrach. If you were with us then, you'll recall that Ali was a few hours late. Much of this was due to the fact that he was packing his trunk full of goodies just before his visit and he began to have problems fitting items in, because were too big (or too long or too deep or whatever), thanks to our inconsistent use of the bulk system.

Poor Ali's player kept having to run back to our developer interface and resize objects to the correct sizes.

The worst came when Ali tried to store away a fur codpiece that had been created specially for his visit. It wouldn't fit into his travel chest.

So, he went into the developer interface to face the recalcitrant codpiece and discovered ....

... that it was five feet tall.

Once more, I'll leave you to come up with this week's punch line.