Other Things Happen

Although players are the main source of the load on virtual worlds’ supporting hardware, they are not the only one. Things can happen whether or not players are present. Some of it is mechanistic: The virtual world’s sun rises and sets, its weather comes and goes, all irrespective of whether there are players around. For a highly detailed world, this could amount to considerable work (a breeze rustles individual leaves on a tree, one of which falls off to land in a stream that carries it lazily to a river and thence to the sea). Virtual worlds of this complexity are some way off at the moment, though.

What’s more of an issue is the presence in the virtual world of virtual creatures. These are commonly known as mobiles ¹ (mobs for short), and they represent the monsters and non-player characters that inhabit the virtual world. They are discussed in more detail in Chapter 4, “World Design,” but what concerns us about them right now is that they need to behave in a believable manner. This requires artificial intelligence techniques, which gobble up computational resources like nothing else. Even simple path-finding is an insatiable consumer of CPU cycles. It would be great to have a virtual city with 100,000 virtual inhabitants, each making real-time decisions as to how to spend their virtual lives. We may have to wait some time before we get this, though.

If a designer wants more mobiles in the virtual world than the servers can handle, they have to offer solutions for managing these mobiles. The classic answer is to suspend processing of those mobiles whose actions would not be witnessed directly by players. What causes AI load is not the number of mobiles on a sub-server, but the number that are active at any one time.

Consider a group of goblins in a village. With no players in the vicinity, there’s no point in having them do anything. Sure, a sub-server can move them around a bit when it’s not unduly loaded, but players get priority. Only when a group of adventurers shows up is it time to activate the goblins so they can behave intelligently and give the players a run for their money. When the players leave, the dead goblins can respawn and wait for the next batch of adventurers.

Designers who want more mobiles than the programmers tell them they can have might be tempted to use this proximity activation approach. They have to realize, though, that every decision they make has consequences.

In this particular case, the consequences are on causality. If a tree falls in a desert, does it make a noise? Using proximity activation, it would never fall in the first place.

Consider a second goblin raiding party. It emerges from its camp, kills some villagers’ sheep, and then returns home with the spoils. The villagers get angry and offer to pay players to kill the goblins.

It’s an evening’s quest.

It’s an evening’s quest that would never happen if the goblins stayed in their camp until a player happened upon them.

Yes, of course, plenty of ways around this instantly present themselves, but that’s not the point: What’s important is that the designer has to recognize that there may be a problem in the first place. Would your proposed solutions to the problem come with problems of their own? Would you have thought about that if I hadn’t asked?

Virtual world design is about consequences.