#8: Electoral Ramblings

by Shannon Appelcline

November 9, 2000 - It appears that we're not the only ones with bugs in our system. As I write this column it's late Wednesday afternoon. The U.S. presidential election, which was declared for Bush late Tuesday night, just before I went to bed, is now up for grabs again. The final count on Florida had Bush winning by three-hundredths of a percent, and as goes Florida, so goes the country. It's recount time.

About when this article comes out, on Thursday at 3pm, Florida should be reporting on their recount. My personal pundicity says that Florida is still going to go to Bush and that he'll become the next President of the United States. And that's where the bug comes in, because as of early Wednesday morning, it looks like Gore won the popular vote. Not by a lot, but apparently Gore got about 250,000 more votes than Bush, and he's going to lose the election. How about that?

The weird things is, this is exactly how the system is supposed to work, due to the electoral college. These oddities have to do with a constitution written two centuries ago, when the public was less well informated, where there were no political parties, and when long-distance communication was difficult. Lots of stuff that's no longer relevant.

If I were the QA Manager of the United States I'd file the electoral college right into the priority one bug file – to be fixed at our earliest opportunity. We'll see what the public thinks if the numbers end up the way they look this afternoon.

What's A Bug?

This raises an interesting question: what's a bug? I personally find the electoral college system to be a bug – a problem based on outdated electoral hardware – but when I started talking to the Skotos CEO about it this morning, he advocated some political theories which state that the electoral college is a good thing. I believe what Christopher says – that even in today's America there's good, sound theoretical reasons for an electoral college. I also believe that if Gore wins the popular vote and loses the election – something that hasn't happened in 112 years – a lot of Americans are going to be outraged.

Is something a feature because it espouses correct theory or is something a bug because most people don't like it? We face that question every day in Castle Marrach.

A hot topic in the forums recently has been free-form emotes. This is the ability to type an arbitrary string as output ("Dolfin gestures toward his linens, then pretends to toss them into the fire"). Free-form emotes would be a great way to express emotions in Castle Marrach, more powerful than what we've got right now, but we've made a deliberate decision not to allow them.

There are some very good theoretical reasons for this. If we constrain emotive ability then we can program CNPCs (and environments) to react to what players do. Also, we feel that an environment where everyone is speaking in very erudite emotes will cause there to be a high barrier of entry for new players unfamiliar with text-dominant games.

So, despite the fact that we know some players want free-form emotes, we come down clearly on the side of our constrained emotes being a "feature".

But, we're not always right.

In designing the Skotos StoryBuilder Server, we came up with a neat system where you could use ordinals (first, second, third) to select objects. So, if there were three Denebian Mudslugs in a room, and you typed "take mudslug", you'd be asked "Do you mean the Denebian Mudslug, the Denebian Mudslug, or the Denebian Mudslug?" and the obvious response would be "take first mudslug". It was a terrific system that made sure you never selected the wrong gastropod.

Our players found it terribly unintuitive. After getting the message asking if they wanted "the Denebian Mudslug, the Denebian Mudslug, or the Denebian Mudslug", people got stuck. The noun phrases were all identical and a fair number of our players had no idea how to differentiate between them. The idea of using an ordinal was not immediately obvious.

Denebian Mudslugs went untaken. It was a tragedy.

So, we backed off our original implementation. We changed the parser so that if that if you weren't specific enough – say, when taking a mudslug – the system would choose one for you. People may now find out that they're picking up (or dropping, or wearing, or wielding, or whatever) the wrong items, but at least they can do so – and 99.9% of the time the right thing probably happens anyway. When one of our engineers changed this behavior, I even reported it in my "Creeping Fixes" forum topic. We'd decided our original implementation was a bug.

There's a lesson here for StoryBuilders, but it's not a simple one. It goes something like this: Even if you decide how things are going to work in your game, and they work in precisely that way, don't be certain that this is the right behavior. It could be that your terrific design is not liked by the players, and then you'll have to make hard choices. Which is more correct, the desires of your players or your own design concepts? The real answer is both. Never ignore your own designs due to the desires of players; never ignore the desires of players due to your own designs.

Voting: A Road Not Taken

Staying on the election thread, I'd like to get back to voting, by way of a digression involving rooms.

We talk about a lot of weird things at Skotos, when we're trying to build a system to build virtual worlds. Somewhere between 6 and 12 months ago we started talking about room names. In real life, room names are chosen by a sort of communal agreement.

Earlier this year, my then fiance (now wife) and I moved into a house. It's an old place, built in 1906 right after the San Francisco earthquake, and thus there were tenants there before us. On the north side of the second floor there was a large room, walls painted with green paint, windows hung with red curtains. A king-sized bed sat in the middle of the room, taking up the majority of the floorspace. Some bureaus and shelves filled out the room. I can't say for sure what the room was called then, but I'd guess "[Someone]'s Bedroom."

When Kimberly and I started deciding what we wanted to do with the house, we envisioned having two libraries – each of which would double as a guest room. [Someone]'s Bedroom would become one of our libraries, and we'd differentiate from the other one by calling it "The Green Library", due to the paint on the wall. We'd move in lots of book shelves and jam a futon bed up against one wall.

But, as we began to get closer to moving in, we decided that the room I'd chosen for my office was a bit small and a bit awkward and that perhaps I should have that nice green bedroom instead. So, when we hijacked our friends into helping us move across town we had them unload a slew of bookshelves as well as my desk and filing cabinet into this former-bedroom, former-theoretical-library. And thus it became "Shannon's Office".

One room, three names: [Someone]'s Bedroom; The Green Library; and Shannon's Office. In a text-dominant game, how do you represent this fact – that room names are usually determined by use? We can't have StoryHosts constantly wandering around, querying players about the communal names for rooms and then renaming them, but we wanted there to be some answer.

Taking this problem in hand I came up with a cunning and clever plan, about 50% serious and 50% smartass, which is close to my norm.

I suggested that the use of a room is usually suggested by the furniture in the room. In the three setups of that green room: the bed suggested that it was a bedroom; the bookshelves without any other distinguishing furniture other than a futon-bed in its couch configuration suggested that it was a library; and the shelves with desk suggested it was an office. Now here was an algorithm that could be implemented in a computer program.

What we would do, you see, is have all of the furniture in a room vote on what the name of the room should be. Votes would be weighted depending on the mass of the furniture – a value that we'd already calculated – a wicker chair would get less votes than a huge, oaken round table. You could even allow things to be pretty dynamic by giving each object a selection of room names that it might vote on. A bookshelf might declare it was part of a library or an office for example. If you wrote the algorithms right, you could not only come up with a decision, but you could come up with the best decision – the one that made the most pieces of furniture happy.

With this system in place if players moved around furniture, a dining hall could become a grand library could become a bedroom. There was some fiddling to be done – we needed to determine how the green walls of a room might become part of the title and how ownership of a room could be declared – but the core idea seemed pretty sound, to me at least.

And I'll have to admit I liked the mental picture I had of the sofa, the dining table, and the wicker chair chatting about what their environment should be called. I still like that mental image.

Our engineering staff was – shall we say – less than amused. There was some screaming involved, though I think it was the terrified type of screaming, not the angry sort.

Zell offered up a few scenarios to me:

1. Imagine Corbin saying "I'll meet you in the Queen's Bedroom." You wander the Castle, unable to find the right locale. There's a Queen's Library, and it's got some bedroom furniture in it, but it's not called a bedroom. Where is your meeting?
   
   
2. Imagine a carefully balanced room, equally split between office and bedroom furniture. It currently is named an office, but only by the narrowest of margins. Now imagine a player, who we'll call Tricky Ricky. Rick is carrying around a nightstand. Rick steps into the room and it becomes a bedroom. Rick steps out of the room and it becomes an office. Rick amuses himself for hours.

My hopes of chesterfields and ottomans mingling together to cast ballots may never be realized.