#26: The Dynamic Dilemma, Part One

by Shannon Appelcline

March 22, 2001 – There comes a time in any MUD players' life when he decides that he could do better than the world builders of his favorite game – when he decides that he could build worlds a million times more interesting than those already in existence. Most players satisfy this urge by petitioning to become a Wizard at their favorite MUD and then building their own realm within the existing game.

But, there are some people who want more. They don't like the character classes in their current game. They think the combat system is limited. They don't think breadmakers are adequately represented by the skill system. And, most of all, they hate the repetitive elements on the game: how the same old monsters keep reappearing, fighting in the same old ways, and dropping the same old treasures.

So, these poor dissatisfied players whine and gripe and finally come to a conclusion. There's only one answer for them. They must create a game of their own.

I was struck by the bug in early 1991.

Caveat: This week I'm really talking about a type of game very different from my usual topic in this column. I'm talking about problems associated with achievement-based games that have some independent gameplay. We don't have any of these at Skotos yet, though we're planning for one with The Bane. Traditionally in the multiplayer prose game field this type of game has been very popular, in the guise of thousands and thousands of MUDs on the Internet. They'll become an increasing focus in my column in the months to come, as The Bane moves toward reality.

The Nature of the Problem

A lot of the issues I discuss are simple gameplay issues. Revising character classes or combat or skills can have dramatic effects on a game, but it's a mainly a question of what type of game you want to create. In Castle Marrach, for example, we're creating a skill system for Socializers; Achievers might not be too happy with the results.

There are, however, some questions that are more central to the whole idea of playing in multiplayer online games – questions that every game must face and that, in many cases, no one has answered well. One of those questions is encapsulated in the reset problem – the question of how to deal with repetitive elements in a game.

The problem goes something like this:

In a game – any game – players need to do something. How do the StoryBuilders keep them entertained on a day-to-day basis?

If you build a game around socialization, there isn't much problem. If you set things up right, the players entertain each other within the background that you've created. Take Galactic Emperor: Succession as an example. In that game you're trying to defeat the other players in order to become the next Galactic Emperor. The other players create the obstacles in your way, and there's probably enough of them that you remain occupied until the day of the Galactic Emperor vote.

The game Quake is a bit far from our prose adventures, but it does show how games built around socialization (be it cooperation or competition) are kept constantly fresh. The designers built some backgrounds and then an infinite number of players filled them up, trying to kill each other.

Although we need to constantly work on Castle Marrach, to create plots and to keep things interesting, it's a far cry from the type of work we'd have to do in an independent-play game. Ideally we can create good StoryBuilder to StoryPlayer ratios in Castle Marrach, with one StoryBuilder entertaining many StoryPlayers, but as we'll see that becomes more difficult in games supporting independent play.

Things, in fact, get a lot harder when you try and build game that allow independent game play. But, multiplayer games with some level of independent play are big draws in the prose game community. When I was struck by that StoryBuilder bug a decade ago, I wanted to build a game with independent play built into it. Skotos too is planning a game with some independent play in it – The Bane.

You see, for an independent-play game, you can spend hours carefully crafting a dragon and filling his hoard with all manner of intriguing goodies. And then some damned player comes around, murders the dragon, and steals all his furniture. Elapsed building time: days. Elapsed play time: 10 minutes. You're back where you started.

Traditionally multiplayer prose games have resolved this problem with the "reset". Eventually, slain monsters and looted treasures are recreated. It might happen after a set amount of time (every 24 hours), after a random amount of time (1-24 hours), or after a set criteria is met (when someone finds The Stone of Faceted Rainbows; when all of the monsters in a specific area are slain).

Without a doubt, resets resolve a central problem associated with multiplayer games. A limited number of StoryBuilders can entertain a large number of StoryPlayers with a limited amount of work. But, there are very real drawbacks.

Among them:

• Players may continue overcoming the same challenges instead of moving on to new adventures.
• More experienced players can hang out at "reset" spots, constantly looting the same monsters and getting the best treasures.
• Economies can be destroyed by the constant influx of new treasures.
• Suspension of disbelief can be wrecked because of the constant return of slain beasties and the duplication of "unique" items.
• Players can feel powerless to change their gaming environment.

Some of the problems I've outlined have been resolved by some games. EverQuest, for example, introduced some randomness into their resetting (a monster might regenerate after a random amount of time; a valuable magic item might be carried by a random monster in an area). These "fixes" curtail some of the worst player abuses (namely players sitting around waiting for the orc that carries around the Board of Indlas Sommer to reappear). Nonetheless, the whole idea of resets is still pretty subpar.

Very smart people have been trying to solve the problem for years without success. I don't intend to try and solve it here today (or in 14 days when I finish my discussion of this topic). I would, however, like to talk the issue out, so that StoryBuilders are familiar with the reset problem and also with some of the possibilities we're considering to make things better.

The Project X Solution

Ten years ago I didn't have the same humility – perhaps it's really common sense – that I do now. When I was struck by the StoryBuilding bug I was certain that I could fix the reset problem. Together with two friends, J. and K., I set out to design a new type of prose game.

With all of the arrogance and silly confidentially of young men that have just left their childhoods behind, we named our new game "Project X".

Most embarrassing.

J., K. and I wanted to make our game "persistent". I didn't know the phrase then, but it's a by-word in our little mini-industry now. It means that a world maintains changes introduced into it. We wanted to make sure if some players killed an Ogre, then that Ogre would never be seen again.

The obvious question is: what do the players do when all the Ogres are dead?

No problem. We had an answer for that. Our game would be implemented dynamically. We'd build plots into the descriptions of our realms, with certain events triggering changes in the world. So, for example, if our Ogre was killed, we'd have – built into the Ogre description or maybe the Ogre death routines – the code that described where the plot should go next. When the Ogre croaked, the system might read the next-plot code, then go and create some Orc bandits who had previously been oppressed by the Ogre but could now rise up.

And we could do a lot neater stuff than just monster substitution. We could, for example, place an old abandoned Castle out in the wilderness, and slowly have that Castle come to life as nearby monsters were slain, until finally it became a community center for the local countryside, filled with knights and jousting and ladies and wooing and all of the other good things you find in castles.

All thanks to the dynamic plot elements that we'd built into descriptions before the first player adventured through that area of the game. (And that we'd scramble to continue and add as players moved the plots forward in our game.)

All very neat, and an excellent recipe for a truly dynamic game allowing independent gameplay. And, all totally destined for failure. Because – and we were unable to see this in our naive young minds – there was no way a StoryBuilder could ever keep up. A StoryBuilder might put twice as much work into creating an area as it took a StoryPlayer to clean it out. Thus, there would need to be 2 StoryBuilders for every single StoryPlayer in our game. Castle Marrach has a very high StoryBuilder to StoryPlayer ratio. It was maybe 1:50 or 1:75 until a month or two ago, and it should revert to those numbers or better as StoryPlotters and Veteran Players go online. 1:50 as opposed to 2:1. You do the math.

Fortunately we never got far enough to see the total failure of our naive young plans. We were never given the opportunity to wallow in the cynicism of our failure (though, we were young adults live in the early 1990s... we probably did anyway).

The size of the task daunted us. We never got anywhere on the game. J. took some of the core concepts that we'd developed and applied them in totally different ways as a project for the XCF (eXperimental Computer Facility) at Berkeley. He was really the only true programmer of our triad anyway. K. does system administration now, while I do whatever gets dropped on my plate. More often than not I say that I'm a writer.

Bottom line: No game. Even if we'd written it, we would have found our system totally unmanageable because it depended on a small number of StoryBuilders to do a huge amount of work.

And the Answer Is... ?

So I've spent a while addressing the basic issue of maintaining stuff for players to do in a multiplayer online game. And, I've talked about one "fix" that would have failed miserably.

So, what solutions are we considering here at Skotos? What ideas should future StoryBuilders be looking into?

Despite the danger of rotten fruit heading my way, I'm going to plead column length and say that I'm going to continue this line of thought in two week's time, on April 5.

Next week contains one of my two favorite holidays of the year. All Fool's Day. I want to celebrate it with something a little more humorous.

So, see you in 7 for some funny business then in 14 for the rest on this topic.

How do you think the reset problem should be dealt with?