|
|
|||
Of all the engineering problems that I've discussed in this column, the one that is the nearest and dearest to my heart is this one, The Dynamic Dilemma. I've actually written a set of three articles on the topic over in my other column, Trials, Triumphs & Trivialities, and thus I'm going to be updating and revising those three articles in the next three weeks here. My own story, and my own experience with The Dynamic Dilemma and how it affects online games begins almost exactly eleven years, when I was struck by the game designer bug. I'd fooled around with game design a bit before that. I'd been GMing games for seven or eight years, and I'd just recently put the finishing touches on my first professional game book: Tribunals of Hermes: Rome, for White Wolf. But, I was still getting my feet wet in the area of online game design. And, I wanted to make designs that were better than anything out there, and as a result I ran into one of the most core and central problems with multiplayer online game design. The Nature of the Problem
Back in those halycon days, we didn't use quite as high-faluting of words as "dynamism". Instead, we had a simple phrase for The Dynamic Dilemma We called it "the reset problem". The problem, which related to how to deal with repetitive elements in a game, went something like this: In a game – any game – players need to do something. How do the designers 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 Skotos' 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 put 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 far cry from the MCRPGs I usually discuss in this column, 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 designers in a social game need to constantly work to create plots and keep things interesting, it's considerably less than the work that's required from an "achievement" based game--the sort that you're probably more used to if you come from the tabletop RPG community, where you wander around into constantly new environments, meet constantly new people, and discover constantly new treasures. You see, when designing an "achievement" based game 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 MCRPGs 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 the central problem. A limited number of designers can entertain a large number of players with a limited amount of work. But, there are very real drawbacks. Among them:
When I played my first AberMUD in 1989, the game was built around resets. In 2002 most MCRPGs involving achievement gameplay elements still depend on resets to a large extent. Even supposedly sophisticated games like EverQuest and Asheron's Call use them to constantly repopulate their worlds. Some of the problems I've outlined have been partially 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 the next two weeks when I finish my discussion of this topic). I would, however, like to talk the issue out, so that designers are familiar with the reset problem and also with some of the possibilities that can 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 designing 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 achievement-based 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 designer could ever keep
up. A designer might put twice as much work into creating an area as
it took a player to clean it out. Thus, there would need to be 2
designers for every single player in our game. Over at Skotos Tech,
Castle Marrach has a very high designer to player ratio. Last year it
was maybe 1 designer to 75 or 50 players (1:75 to 1:50). Nowdays,
since we have a number of different types of privileged players, you
could count it at anywhere between 1:50 and 1:10.
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 dynamically
creating stuff for players to do in an MCRPG. And, I've talked
about one "fix" that would have failed miserably.
What solutions do I think will actually work? How would I try and
solve the problem now?
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 over the next two weeks. I no longer believe that there are
any total solutions, but I do now think that there are two broad ways
to design your game that can help a lot with problems of dynamism.
They are:
Each of those deserves a week on its own, and then we'll get to
the one Alternative View I have on this subject.
I'll see you in 7.
| ||
|
[ Read FAQ | Subscribe to RSS | Partner Sites | Contact Us | Advertise with Us ] |
|
[ Read FAQ | Subscribe to RSS | Partner Sites | Contact Us | Advertise with Us ] |
