Dynamic Random Encounters

The random encounter has always been part of a staple role-playing diet. Its purpose was to throw something different into the mix at a time when there was nothing specifically planned going on, allowing the DM a way to add something extra to the storyline at a moments notice. This was done via a random encounter table which required you to make a d100 check and then use the encounter that matched the rolled value. Sometimes a specific encounter may have covered several percentage points on this chart, indicating that it was far more likely to come up than others. There were also caveats on some of the encounters that once they had occurred, they were no longer available and you had to re-roll if they accidentally came up again.

Looking at the concept behind the random encounter table we can see that the original intent was something along the lines of "At this location, these kinds of creatures and these pre-determined scenarios may be encountered in this frequency". When ever a check was made the DM knew that the encounter was statistically appropriate for the location they were in. Often it would require a lot of creativity and thought to create such a list, requiring the DM to draw from several sources to make it feel realistic for whatever part of the world they were in.

First they would consider what the local flora and fauna was for the area in question, adding wildlife from their natural habitat. This allowed different localities to have a distinctly different flavour as adventurers could tell how a land was changing based on how the creatures they faced were different. Every creature in the monster manual is given a terrain to which it is considered common and this was used to structure the encounter tables. From there the DM would consider what was currently happening in the world around them, were there any nearby villages or population centres that would have an effect on random encounters. Thus if there was a nearby goblin village you might throw a few goblin patrols into the table, or a group of local bandits who were in the area. Last but not least a DM would try to come up with some creative people and situations that might add some colour and variety to what was otherwise a long journey across faceless terrain. These often required coming up with an NPC, a situation and a reason for being there, and presented an opportunity for the characters to actually role-play instead of fight, and were usually one shot encounters that would only happen the once.

The random encounter table that was created as a result was a specific snapshot in time that would provide encounters for the brief period of time the players were actually in that area.

Translation to Neverwinter Nights

The translation of this concept to Neverwinter Nights was very static and limited. The Encounter object only represented simple monster spawning, and while you were able to control when the encounter could be fired, the fact that it had the ability to be reset coupled with the inability to alter its location or the list of monsters in the encounter dynamically made it very static. Whats worse, too many encounters placed in an area caused huge overheads and lag as a result. This of course was still sufficient for being used in a run-once module where most encounters were snapshots in time that were only triggered once and allowed for areas of the module to be "cleared" as you progressed further into the storyline.

The non-monster spawn types of random encounters were not even catered for and required the designer to specifically script them into the module at a pre-determined point, which again made it incredibly static and very predictable. Again on the surface in a run-once module it would have appeared as if everything was ok, but play the module more than once and everything was essentially the same with very little variation the next time around.

Translation to a Persistent World

Unfortunately having already suffered in the translation to Neverwinter Nights, it becomes detrimental and unworkable for a persistent world environment. What was always intended as being a snapshot in time that characters only passed over once or twice, now becomes something constantly and repeatedly crossed hundreds of thousands of times. In a world that is always alive, it's predictability makes it nothing more than a "bonus round" for earning experience points. So much so that players map out a series of points where these types of encounters occur and repetitively follow the circuit farming experience from them. They can do this all day and night without fail and no matter how many creatures are killed, it is a never ending supply of opponents for them to beef up on. Whats more, as loot tables are also based on random chance, with rare loot drops being given the lowest percentage changes, repetitively farming over and over again means that eventually you are going to hit the jackpot and bring into existence powerful items that should not be there.
This then becomes a self-fulfilling trap where those who do not do this are penalized by having to follow the laws of averages, while those who embrace the loophole are given an unlimited supply of experience and loot as a result.

What needs to be eliminated

In order to fix random encounters for a persistent world environment you obviously need to eliminate those detrimental factors which have inadvertently been introduced. Clearly the use of the encounter object itself is the first problem. The very fact that it slows down the server, creates unwanted lag and even causes compiling of the module to grind to a halt is evidence enough for its execution.

The solution that takes its place must must also eliminate the predictability of where encounters are located. While it was unpractical to try and create and maintain several encounter objects in the same area, the same limitations don't apply to a custom system, and thus an area can be designed with multiple encounter locations in order to reduce predictability. As these locations are all tied into the same random encounter system, instead of having their own completely autonomous triggering mechanism it also means that you can control the encounters that happen in the area as a whole.

The next thing that obviously must be eliminated is the inexhaustibly of them. Without a fixed creature list we now have the ability to add and remove creatures from the table as we wish, allowing us to either show a changing list over time, or to add/remove creatures based on how frequently they have been encountered. The creation of items out of nothing is also eliminated by the loot and treasure sub-system which draws from the database.

What we end up with is a system that is no longer specific to an actual location, immune to being "farmed", relates to the world around you and changes over time to reflect what is going on. During quiet times the random encounters may be fewer and more mundane, while in times of war they may automatically include more war parties, they could contain undead when a nearby cemetery is infested, and smatterings of highly detailed role-playing encounters can occur throughout based on statistical probability of them happening.

Back to basics

So how then can we restructure the random encounter table in a way to support this?

To start we go back to the way in which the random encounter table was originally created by DMs. The idea is to replicate how it was done previously, but draw from various sub-systems in the template where appropriate and keep in mind that it is no longer a snapshot in time.

The most obvious place to start is of course the natural fauna of a chosen area. This is the most basic of the random encounters and allows you to decide for each area what the breakdown of creatures are. These can be considered the "renewable" resources for random encounters as their numbers are replenished by the natural eco-system. This could of course change over time and the designers of the persistent world will have the ability to adjust this list dynamically when the world is running without the need to re-compile the module as you would with a standard encounter object. This of course doesn't stop you from randomly dropping "once-off" encounters into the list such as a green dragon that has taken up residence, or a more unusual creature that just happens to be in the area now.

Secondly, interaction with the quest sub-system allows for random encounters to be attached to quests. If a goblin tribe has taken up residence in a cave, then it stands to reason that the surrounding areas would now have a greater chance of goblin patrols. Start to take out too many patrols and they may step them up to something more. This also leads the characters into quests for the surrounding areas. Imagine encountering undead in a forest, which eventually leads you to the local cemetery that has recently been infested with undead.

Lastly, there are always things going on in the world, random happenings from people who live nearby or NPCs that exist in the world. This could include everything from a supporting level NPC who often scouts the woods during certain times of the day, encountering NPC adventuring parties who are in the area, or even coming across minions of the major villains who have schemes going on at the time.

In essence we have now restored the original purpose of the random encounter, tied it in with various sub-systems that allow it to be altered dynamically or even automatically, and made it feasible in a persistent environment.

How it works

Obviously if we are replacing the existing encounter object, we need to replace it with something. In keeping in line with the philosophy of the template, the module itself will only contain enough mechanics to make things happen, while the actual specifics are handled behind the scenes by a separate simulator and accessed via the NXNX interface. Special area triggers can be placed all around the area, and identified as random encounter points. Instead of being generic however the size of the area as well as the features that exist in the area can be mapped out. This may include ambush points where smarter enemies may spring from during the encounter, choke points that may be blocked or camp areas where something may be set up. The purpose here is to litter the world with as many encounter points as possible, as these do not take up a great deal of resources, and the specifics of the encounter point are recorded by the database. The random encounter list is then matched to the possible encounter points and whenever a player approaches, a determination can be made for whether an encounter is to take place and the encounter point can be properly configured before they arrive. In this way the designer can be incredibly detailed about how they design encounter areas and leave everything up to the system to work out when the time comes.

The end result is an area which feels as if it is real, with encounters that are not predictable, that can happen in a variety of locations, and can even be smart in the way they are portrayed. They could be chance encounters with the local wildlife, or highly specialized encounters with NPCs that lead the players into new adventures. Now the focus has been completely removed from simple circuit farming, and the joy is restored by making those who explore and look around get rewarded for their efforts more than those looking for a quick fix.