[MUD-Dev] FW: Article on Global Verbs & Bulk Bug

[Christopher Allen]

I thought that you might enjoy this week's article from Shannon Appelcline's
ongoing series "Trials, Triumphs & Trivialities" at
http://www.skotos.net/articles/TTnT_19.html and comments at
http://www.skotos.net/ubb/Forum4/HTML/000019.html

In the article he discusses:

   * Global Verbs vs Local Verbs
   * An amusing bulk bug

-- Christopher Allen

------------------------------------------------------------------------
.. Christopher Allen                                 Skotos Tech Inc. ..
..                           1512 Walnut St., Berkeley, CA 94709-1513 ..
.. <http://www.Skotos.net>               o510/647-2760  f510/647-2761 ..


#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.

You'd find local verbs in LPMUDs and AberMUDs (though these tended to have a
small set of global verbs as well). With a local verb, you implement verbs
only where they actually work, as opposed to everywhere in the game.

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

The Skotos system actually combines these two traditional types of verbs.
All verbs must be defined globally. For all of our "social" verbs (things
with minimal game effect, as opposed to "action" verbs like "north" or
"duel" or "sign") this is really easy to do. Any non-programmer can add a
new verb by defining what type of verb it is. Can the verb be used with an
object ("hit wall")? With a preposition and an object ("point at the wall")?
With an evocation ("say 'The owls are not what they seem.'")? A
non-programmer just enters this information into some web-based forms and
... voila! ... the verb is globally defined.

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. And that's the
first place that the question of inconsistency enters our world today. As
StoryBuilders, we have to be very careful and:
	Consider whether a local definition of a verb should actually be made
global.
	Make sure that all of our local definitions match up.

In the case of my pyromaniac verbs, I'd probably do best to go to my global
definition of "ignite" and use SAM, another minor programming language, to
define the verb a little better. I could tell it to have a specific reaction
(or maybe a few different reactions) if an item was marked as burnable, and
then I'd just need to go to my individual items and note that each indeed
was burnable. Afterward, I could set "burn" and "light" to be alternative
names for that same burn verb.

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.




_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev