The Inside Scoop on Gaming

Last week I discussed a problem without really offering a solution (or, at least, not a sustainable solution). The dynamism problem is stated fairly simply: in an Achievement-based 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 outline the two broad solutions which I vaguely mentioned last week:

Object Recreation. (Aka Resets or 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.
New Object Creation. The solution I came up with eleven 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 game designers.

In actuality, the ideas at the bases of these existing solutions can be expanded to offer good answers to the dynamism problem. By using object recreation and new object creation in interesting new ways you can put more dynamism into your game, and that's going to be my topic of discussion this week and next. This time around: object recreation.

The Random Factor

One of the simplest expansions to object recreation is to introduce 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 Skotos 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. Camping 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 are 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 maintain 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.)

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 last week 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 ways ...

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

Thinking Virtually

#52: The Dynamic Dilemma, Part Two

What do you think?

All Thinking Virtually columns, provided by Shannon Appelcline

Other columns at RPGnet


Thinking Virtually #52: The Dynamic Dilemma, Part Two by Shannon Appelcline April 22, 2002 [an error occurred while processing this directive] [an error occurred while processing this directive] [an error occurred while processing this directive]	Last week I discussed a problem without really offering a solution (or, at least, not a sustainable solution). The dynamism problem is stated fairly simply: in an Achievement-based 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 outline the two broad solutions which I vaguely mentioned last week: Object Recreation. (Aka Resets or 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. New Object Creation. The solution I came up with eleven 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 game designers. In actuality, the ideas at the bases of these existing solutions can be expanded to offer good answers to the dynamism problem. By using object recreation and new object creation in interesting new ways you can put more dynamism into your game, and that's going to be my topic of discussion this week and next. This time around: object recreation. The Random Factor One of the simplest expansions to object recreation is to introduce 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 Skotos 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. Camping 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 are 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 maintain 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.) 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 last week 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 ways ... And with that tantalizing note, let me bid you adieu until next week, when I'll finish up this topic.