Wednesday, April 2, 2008

Dynamic Quest Generation

The fundamentals of quests on a Persistent World generally fall into two camps. The first being quests which are completely controlled by the sever itself, and the second being completely controlled by Dungeon Masters through the DM Client. Clearly both of these are feasible, but they also come with a price. While the DM quest is very open and dynamic, it requires the presence of a DM in order to do it and more often than not there isn't one available when you need them. By comparison the scripted quest may always be available, but it will never be as flexible as a DM quest and generally tends to be repeatable for the simple fact that it requires scripting to put in and we can't have this a "run once" type of thing due to the investment of time that has been made.

What if there was a way to combine the two?

The best of both worlds would obviously be to have quests that are dynamic, flexible and change over time, while not always requiring a DM to be present to be able to conduct them. Ultimately you dont want them to be repeatable but you don't want to lose all of the hard work that went into scripting it as well. So you find yourself asking the question "Is this actually possible?"

Breaking it down

The first thing that I realised was that regardless of whether a quest was scripted or controlled by a DM, the low level nuts and bolts of it were essentially the same. It is just as easy for a DM to give you an item and tell you who you need to give it to as it is for a script to do it, and yet the DM can expand on this simple action by providing a background story that elevates it from being a simple fed-ex quest. When you look at most stories or quests, you can always break them down into their constituent parts and those parts when looked at individually are actually not that difficult to do. An entire adventure could be summed up with a combination of exploration, fed-ex, assassinate, locate, solve and navigate. In essence there is only a limited number of storelines under the sun and almost any idea could be expressed not in elloquent words from a DM, but in a series of interlocked tasks or actions which may be as simple as delivering an item to a chosen person.

Example: The Fed-Ex

To highlight this point lets look at the simple fed-ex quest. The staple of any good RPG diet and unfortunately something that is impossible to truely get away from. In its simplest form it is the delivery of an item to a destination. This can easily be set up with a scripting wizard or managed by a DM. The DM however has the added benefit of being able to vary the way in which the quest is delivered, but at the end of the day it is a still a fed-ex. A common derivation of the fed-ex is the proof-kill. This requires someone to kill another, and then return to them proof that they have done the job (usually something owned by the victim that is only dropped when they die). Is this not just a fed-ex in disguise?

Imagine all these:

  • Lord of the Rings - Deliver the one ring to the fires of Mt Doom and throw it in.... Fed-ex!!
  • Star Wars - Deliver Luke Skywalker to Alderaan... Fed-ex!!
  • The Matrix - Deliver Neo to Computer City... Fex-ex!!
  • Raiders of the Lost Ark - Deliver the Ark/Crystal Skull/Grail to some crusty museum.... Fed-ex!!
  • Conan the Barbarian - Retrieve the woman you love from the evil Thulsa Doom.... Reverse Fed-ex???

So it isn't the mechanics of what is required that makes it enjoyable, but the story that is weaved around it. With a scripted quest this story is hard coded into the dialogs and scripts, which forces it to become repeatable, while DMs have the luxury of weaving a new story each week while still achieving the same underlying goals. The question then becomes:

"How can we get DMs to provide the story for scripted quests?"

The Quest Engine

Now imagine that the scripts are in place, but instead of being hard coded with the story, they only hard code the mechanics of the story while leaving the actual details as variables. In this way a DM can create their own story by choosing the specific details and generating the quest using those details. Taking the simple fed-ex as an example, a tool will be provided that allows a DM to interact with the underlying database that contains all of the currently running quests. In this way they are able to create new quests on the fly, which will automatically be available live in the server. For instance they could choose the local inn keeper, select a bag of supplies as the item and then set the destination as their cousin at another inn on the other side of town. By then writing the the words that will be used to flesh out the story they have essentially created their own DM controlled quest but without the need to be there to follow it all the way through. A player now talking to the inn keeper will be given the option of taking this quest and can now follow the story.

Once this has been completed, the quest is over, never again to be performed by anyone else and never again to be repeated. The DM is now able to choose any other manner by which to run the same kind of quest. They could create a band of orcs in the hills, and assign a fed-ex quest with the local captain of the guards who is offering a bounty for the head of the orc chief, or a farmer who needs an antidote for a sick cow, or a local noble who has had their ring stolen and wants it back, etc, etc, etc. The possibilities are as endless as the imagination of the DM and yet they do not have to be present for any of them.

Quest Simulator

This is where it gets interesting. Now take this one step further. As well as having DM created quests using this engine, why dont we allow simulators to automatically create these quests? A living and breathing world always has certain jobs that need doing, and those jobs may or may not be repeatable, though they always involve some variation. Store owners always need to buy or sell stock, transport companies always need to send goods from one place to another, thieves always need apprehending, resources need finding, etc, etc. If the simulator was tied into the quest engine it could generate its own quests based on what is currently happening in the world. In this way, there will always be something for players to do as there will always be a need for the world to keep churning. The difference here however is that each quest has a viable effect on the world. If the goods are not delivered then the simulator cannot craft more items and that may generate a new quest. Stop too many thieves and the local thieves guild may put a price on the head of the do-gooder.
With an engine in place that is flexible enough to generate all types of quests, and the simulators in place to instigate different quests based on what is happening in the world, we end up with a persistent world that still has and needs input from a DM, but also quite happily takes care of the day to day quests that are available and ensures that none of them are directly repeatable as a result. Richness, variety and a true impact on the world. Everything you could ask from a Persistent World.

1 comments:

Robert maddox said...

I've been looking at something similar for creating dynamic spawn points for the creatures within a world as well. What's interesting is that a world who's cycles are pre-mapped is pretty boring. It's the players who cause chaos and change within any given system - with dynamic spawn points and a need-based questing system, the world becomes static and predictable the fewer players that are online. It becomes a system seeking stability. The more players that are online, however, the more the system becomes unbalanced, leading to "crisis situations" that are inherently full of drama and emergent storylines. So long as a "reboot scenario" is considered when the world becomes unviable, (such as an apocalypse event followed by a rebirth event), the world will able to return to stability regardless the mayhem caused by players trying to "break the system".