Spawning is the automated process of adding content to a game on-the-fly, in response to player needs. Typically, it is used to replace objects that have gone out of circulation (eg. mobiles that have been killed) and as an adjunct to quests.

At its most basic, it occurs simply when the game designers believe that the players should need it, regular as clockwork. Actually, this isn't as dumb as it sounds, because if players can safely predict when and where content is to be added then the system tends towards self-balance: spawns that are "too common" will attract more players to them, reducing the goodies available for each individual; spawns that are "too rare" will mean less competition, so more of a chance you'll get something if you do show up at the appointed hour.

This kind of designer-decreed spawning isn't exactly satisfying for players in the long run, though. Players prefer it if the game is responsive to their needs, rather than their having to be responsible to the game's.

The planning-based quest system I've outlined thus far in this series of articles doesn't, in theory, need any kind of spawning. However, in practice spawning can greatly increase the range of quests available and the time taken to set them up.

For example, a couple of articles ago I looked at how Doris the dwarf could have set up her own business. One of the preconditions to doing this was that she had more than 1,000 gold pieces. Now it's possible for the game to keep track of every single monetary transaction between non-players and therefore be able to figure out whether she has 1,000 GP or not. If this is too much work, then an alternative would be to make a general assessment of how much money she would have saved up, based on her circumstances and personality, and give her that. A third option would be simply to give her the money, on the basis that if she didn't have it there's no way that the players would accept "get me 1,000 GP" as a quest.

Keeping track of what money she actually has involves no spawning; giving her an estimate of what money she has does involve spawning, but only of what she implicitly has anyway; giving her the money whether she's entitled to it or not is out-and-out spawning.

In the game world, implementing spawning to make implicit information explicit is defensible. If no-one has been in this neck of the woods before, then maintaining a population of mobiles for the several weeks beforehand would have been a waste of computer resources. Keeping track of which goblins are pregnant, when they give birth and when their offspring reach maturity is also a waste of time: it's far better simply to hide all this behind the scenes and produce goblins approximately when they would have appeared had the full system been implemented.

Spawning objects simply to make a quest exist is less defensible in terms of consistency of the game world, although it can often be justified from the point of view of improving gameplay. If "my daughter has been kidnapped by bandits" then this had better be bandit country rather than a sleepy heartland farming community, and the bandits had better be somewhere the player hasn't just walked past and seen no signs of life in.

The way this is implemented in terms of quests is via a hardwired action. The mobile needs to satisfy a precondition of perhaps X has been captured by Y, which it could do by executing a spawn X captured by Y action. Being hardwired, it can have flavour text hardwired alongside it, in case awkward players ask "how did bandits capture your daughter?". Another way to do it would be to spawn daughter and bandits separately in response to separate preconditions concerning what has been taken and who has taken it.

A problem with spawning

There is a major difficulty with this kind of spawning.

People can go around pressing quest-dispensers' buttons and accepting quests, but not actually complete them. This can either be deliberate or accidental - you may decide that the quest is too hard, or you may be killed attempting it, for example. In order to stop the game from becoming choked with quests, there has to be some kind of clean-up mechanism for ones that are abandoned. This entails their having a time limit (so the game knows when they're formally finished) and that everything that has been spawned can be unspawned.

Unspawning isn't easy. A player desperately trying to kill a pack of wolves in order to finish a quest on time would to notice were the pack suddenly to evaporate when the clock struck midnight. They'd also be cross if the sword they'd won fair and square in an earlier part of the quest were to disappear the moment no-one was looking at it.

In simple worlds, the problem is tractable. Objects to be kept can be given a property of resistance to unspawning, and objects to be unspawned can be flagged to do so on the next "get rid of useless objects if no-one can see them" pass of the database.

In more sophisticated worlds with a better idea of physics, there may be knock-on effects that cannot reasonably be undone. If a dragon starts a forest fire and the player bursts a dam to try to extinguish the flames, then when the quest ends the dragon can be removed but what about the forest fire? Or the flood? Or the secondary fires that started when the forest fire reached the village? Or the mobiles that were trapped in the forest and burned to death?

If you've spawned an asteroid to hit the game world, unspawning it is going to be impossible...

Next article, I finish this series on quests by examining how human designers can use automated quests as tools to help them design bigger and better quests themselves.