#28: The Dynamic Dilemma, Part Two

by Shannon Appelcline

April 5, 2001 - For the first twenty-four weeks of this column, I limited the scope of my articles. I mainly discussed trials, tribulations, and trivialities related to social games like Castle Marrach. Cool stuff, but not the entire spectrum of multiplayer online games.

In actuality, there are tons of different games which we can represent in prose. I talked about the broad categories of game types out there in "Telling Stories, Classifying Worlds", and have since categorized the Skotos games on the Our Games page.

With the scope of Skotos games increasing, it only seemed fair to expand the scope of this column too. My article of two weeks ago, "The Dynamic Dilemma, Part One" was the first article to really look closely at a problem in a game of a different sort. It addressed the problem of dynamism in Achiever-type games, like our upcoming The Bane (and also like the many MUDs out there on the net).

The dynamism problem is stated fairly simply: in an Achiever-type game, players are constantly doing things, and some of those things (killing monsters & looting treasures) can be quite destructive; they use up resources which a StoryBuilder has lovingly handcrafted.

How can a StoryBuilder keep up with the StoryPlayers?

The answer is a very tough one that's stumped multiplayer game builders for over two decades. What I offer this week and next are a few possible routes for thought, not complete answers.

Before I continue, let me remind you of the two solutions discussed last time around:

• Resets. (Aka Spawns or Repops.) The standard solution thus far. Every once in a while things that have been killed, stolen, or moved are recreated. Monsters & treasures are the usual beneficiaries of resets. Deficits: repetitiveness, inability of players to affect the world, repetitiveness, possibility for boring players, repetitiveness, opportunity for players to take massive advantage of the system, and repetitiveness.
• Constant Creation. The solution I came up with ten years ago for my own game (Project X), where StoryBuilders kept ahead of the players, always creating new stuff to do. Deficits: Carpal tunnel syndrome, tendonitis, and general insanity among StoryBuilders.

In actuality, the ideas at the bases of these existing solutions can be expanded to offer good answers to the dynamism problem. You just need to look at the core mechanics involved in these systems: object recreation and new object creation. If you expand these two core concepts out, looking at them in some new ways, they can offer solutions that are interesting and realistic.

As usual, my topic got a little bit out of hand, so this week I'm going to limit myself to expansions on the idea of object recreation.

The Random Factor

One of the simplest expansions of object recreation is introducing random elements. You still address the issue of dynamism with resets, but the randomness makes the resets a little less obvious (and also harder for players to abuse). This was discussed a little bit in the forums. It's also a common topic over on the MUD-DEV mailing list. I'm going to summarize some of the best ideas about random resetting and also include a few of my own. A lot of these have been implemented in EverQuest, which has probably gone further toward randomizing resets than just about anyone else.

These ideas for randomizing resets really don't deviate a lot from the basic concept. They're variations on a tune. They don't resolve the core problem of a static world that players can't affect, but they do at least give some illusion of change. So, not a great solution, and definitely not the best way to solve the dynamism problem through object recreation, but simple. Consider it nice stucco to put on the outside of your game.

Randomizing Spawn Type. In a reset-based game specific objects (usually monsters or treasures) are recreated every once in a while. By randomizing the spawn type you can have different objects spawned at different times. This could be a slight change: you might generate a red shield rather than a green shield. It might be a major change, but still confined to a single object type: you might generate a kick-butt orc chieftain instead of a wussy orc follower. Or, it might be a massive change, resulting in a different object being created: you might generate a dragon rather than an orc.

Many designers use this method to prevent "camping", which is the practice of waiting for a monster to reset. This is usually done so that you can kill the monster then grab the rare item that the monster "drops". Depending on how you implement your random spawn, you may or may not alleviate that problem. If the monster with the good item only appears half the time, or if he only drops the good item half the time, players will probably just camp even more. So, don't consider it a good solution for the camping problem, unless you combine it with some of the other methods below.

Do consider this method a good solution for the general problem of dynamism, however. By changing what appears in a locale in meaningful ways consistent with your background you'll create a world that's a little more dynamic and interesting.

A caveat: be careful. You probably don't want to generate a dragon in an area intended for low-level characters (who will be gored) or to generate an orc in an area intended for high-level characters (who will be bored). Likewise, you may not want to offer the opportunity for a very weak opponent to have a very powerful item.

Despite these possible problems, randomizing the spawn type is very common.

Randomizing Spawn Time. Even easier. Rather than having a reset occur for a monster every 8 hours, have it occur every 3-15 hours. Also quite common.

Randomize Spawn Location. The last of the truly random techniques. This can be applied to critters and treasures in slightly different ways. For critters, you might randomize where they appear, over a large area. For treasures you might randomize what critter is holding them.

As should be obvious, combining the three above techniques in different ways can make it much more difficult to detect how critters and loot are being reset.

Respawn Based on Events. Although not technically random, resetting based on events can give the appearance of randomness if the required events are complex enough that players can't figure out the pattern.

A certain powerful creature might not be reset until all critters in an area or destroyed or until a certain door is opened or until a certain ritual is done. Alternatively powerful creatures might only be respawned as weak creatures are killed and truly mighty creatures might only be respawned as powerful creatures are killed.

On the downside, players tend to always figure out the pattern. And publish it on their web sites.

Respawn Based on Players. You can really increase the amount of dynamism in your game by respawning based on a specific event: what players enter the area. The idea here is that you wait to reset until you see who is coming along to kill monsters and loot treasures. Then you can create appropriate critters and loot for that person.

The problem, as with many of these randomizations of spawn, is how you main continuity of story. In other words, the quasi-randomness has to make sense. If you can conquer that, however, this is another powerful possibility.

The Simulation Solution

Static resets and randomized resets are both parts of the object recreation continuum. As you move up the continuum, you slowly introduce more and more criteria for how a reset works. At the far end of that continuum the criteria are so complex that you're actually modelling real-world systems. Enter simulations. With a simulation you still have monsters and treasures being recreated in your game, but it's all based upon complex ecological and economic simulations.

To create a good simulation you need to understand one core idea: the world of the game is bigger than the world of objects in the game. In other words, not everything in the world is actually physically represented in the world. Rather, most things in the worlds are represented by simulations, with objects occasionally being created and uncreated.

For example you might have a ecological simulation that details all the peoples and critters living in your world. Say it says there's a population of 100,000 Ogres in your world and that they're very aggressive creatures and that they prefer to roam the forests. In any forest there's going to be a decent chance of meeting an Ogre, while the further away you get from a forest the more the odds decrease.

If a player kills an Ogre that doesn't change the simulation much. There are only 99,999 Ogres now. And, given that the ecological simulation includes not just death but also birth, that Ogre will eventually be replaced. If their numbers greatly increase, Ogres might become more aggressive; if they greatly decrease, the Ogres might hide out more. Players could be overwhelmed by Ogres or wipe them out.

A similar simulation can be applied to economics, with new raw materials entering the world from mines, crafters crafting those new raw materials, magicians making new magic items, those items flowing into monsters' hands as they make attacks that aren't repulsed... etc. The system can be as complex as you see fit.

Lots of people have talked about simulations over the years. They're really hard to put together because you have to design them in a way to give players free will and the ability to make changes, but at the same time make sure they don't easily knock the whole thing out of kilter. I've even seen the occasional claim that it's impossible to create real ecological or economic simulations in multiplayer online games (which seems pretty defeatist and dogmatic to me).

Nonetheless, huge numbers of failed simulations litter the world of online games.

Ultima Online tried out a simulation system shortly after the game went online, but it was doomed. I haven't seen much discussion of their economic system, but their ecological system had definite flaws. For one thing, they didn't use the idea of only embodying a few of their critters in the world, while letting the rest live in a simulation. As a result the number of actual critters that they had holding down their ecological simulation was much too small and players were able to totally wipe them out. Quickly.

Economic systems face similar problems. How do you constantly give out treasure to characters without that influx of loot creating hyperinflation? How do you avoid hoarding, a core problem for any closed economy? How do you provide an outlet for goods so that you have items passing both in and out of your economy? There's a lot of room for discussion here, possibly as a future column.

In many ways I think simulations are one of the best solutions for Achievement-type games. They allow for resets, but do them in a very realistic way which actually represents the ecology and the economy of the world. They allow players to make a large change in the world, but do so slowly enough that StoryBuilders have plenty of time to build other things for the players to do – if the players wipe out all the Ogres then a StoryBuilder can think about creating the next obstacle. Definitely, simulations seem to be the best end result if you decide the correct solution to the dynamism problem is object recreation. (And if you're willing to invest the time to do so, going down all the rat holes that are likely in a problem of this complexity.)

In closing I should note that we're going to give simulations a shot. They're the core of the game which has been on our TODO board since day one: Alvatia. We see it as the ultimate in an Achievement game.

Final Thoughts on Object Recreation

As I've already noted the solutions that I've offered this week all fall into the same category: object recreation. They look upon the question of dynamism and say that the right solution is to constantly recreate the same items in your game (maybe the exact same items, maybe a whole random list of items).

It's not the only answer.

The other possibility is to create entirely new objects. When I discussed my Project X solution two weeks ago I suggested this was a pretty insane way to do things. If you're trying to create things faster than the players destroy them, as we were going to in Project X, it is insane. But, there are other solutions...

And with that tantalizing note, let me bid you adieu until next week, when I'll finish up this topic.