Feature Specification: Encounter System

Scripted ALFA systems & related tech discussions (ACR)

Moderators: ALFA Administrators, Staff - Technical

User avatar
ç i p h é r
Retired
Posts: 2904
Joined: Fri Oct 21, 2005 4:12 pm
Location: US Central (GMT - 6)

Feature Specification: Encounter System

Post by ç i p h é r »

Encounter System
The requirements for the ALFA Encounter System are detailed below.

For a short explanation of the feature specification format, visit:
http://www.alandfaraway.org/phpbbforum/ ... hp?t=27229

Functional Requirements
The encounter system is responsible for spawning creatures at random while in the wilderness, when resting, or at specific locations to achieve a specific encounter level.

The encounter system will track spawn kills on a per-group basis (based on creature tribe/area), and force spawn groups to grow organically (eg: no CR5 until you have 1 CR3 and 10 CR1-2 - EL formula?). Population trends will follow the monster manual for a given creature type, which includes a certain number of elite creatures, noncombatants, etc (specifics?) per total population. Creature demographics can vary along racial/tribal/type lines and in relation to terrain and locale.

Spawn points will have a % chance (specifically?) to spawn a small raiding party. Raiding parties will target creature population centers, killing local wildlife and attacking nearby settlements (AI?). When the group size reaches 10, the spawn group becomes a large raiding party. When the group size reaches 100, the spawn group becomes a camp with a named Boss and has a % chance (specifically?) to launch a new spawn point in a nearby area that doesn't already have spawn points of the same type in them. If left unchecked, spawns will eventually overrun areas and even regions.

Spawn points that have grown organically by the system will be destroyed when the Boss is killed. Natural spawn points placed in the toolset will not.

Growth rates must be balanced with player habits/activity on a given server. (leave to builders to determine or auto calculate to specific rate?)

EL equations from the DMG (3.0):
  • Matched pairs - EL(x + 2y) = 2^y * CRx, where x is the CR of the creatures and y is the number of creatures. Eg: 2 CR9s or 4 CR7s or 8 CR5s = EL11.

    Mixed set - EL(x+1) = CRx + CR(x-3), where x is the CR of the creatures. Eg: CR5 + CR2 = EL6.

    Fractional - normalize the CR to get an EL of 1. Eg: 4 * CR1/4 = EL1. More than 12 should not be used to provide challenge, as they individually are too weak and large numbers of spawns can lag a server.
NWN Object Dependencies
TBD

Local Variables and External Configs
TBD

Logging and Debugging (global LOG & DEBUG (on/off) constants)
TBD

Persistence Requirements
TBD

Event Dependencies
TBD
Last edited by ç i p h é r on Sat May 20, 2006 9:10 pm, edited 5 times in total.
User avatar
ç i p h é r
Retired
Posts: 2904
Joined: Fri Oct 21, 2005 4:12 pm
Location: US Central (GMT - 6)

Post by ç i p h é r »

Just a placeholder for the requirements. I'll take a crack and prying loose the system ideas in the dim rets thread but please keep relevant dialogue here if possible.
User avatar
ç i p h é r
Retired
Posts: 2904
Joined: Fri Oct 21, 2005 4:12 pm
Location: US Central (GMT - 6)

Post by ç i p h é r »

Ok how's this for a first crack at a spec? I've noted areas where I think we need to be more specific.
User avatar
Fionn
Ancient Red Dragon
Posts: 2942
Joined: Sun Jan 04, 2004 7:07 am
Location: Seattle, WA

Post by Fionn »

Hrmm.... from the WotC site:

Code: Select all

Encounter Level (EL): Encounter Level is strictly a tool for the DM to use when deciding if an encounter is too easy, about right, or too hard for a particular group of characters. It has no real effect on play. Some people think that Encounter Level determines how much experience character can gain from an encounter, but that's not so (see Challenge Rating).
PC: Bot (WD)

Code: Select all

     -----          -----          -----          -----
    /     \        /     \        /     \        /     \
   /  RIP  \      /  RIP  \      /  RIP  \      /  RIP  \      /
   |       |      |       |      |       |      |       |      |
  *| *  *  |*    *| *  *  |*    *| *  *  |*    *| *  *  |*    *|
_)/\\_//(/|_)(__)/\\_//(/|_)(__)/\\_//(/|_)(__)/\\_//(/|_)(__)/\\_(
User avatar
Fionn
Ancient Red Dragon
Posts: 2942
Joined: Sun Jan 04, 2004 7:07 am
Location: Seattle, WA

Post by Fionn »

EL equations from the DMG (3.0):

Matched pair - doubling of anything (over CR1) adds two to the CR. EL11 for 2*CR9, 4*CR7, 8*CR5...

Mixed set - EL (X+1) = CRX + CR (x-3). A CR5 + a CR2 is EL6.

Fractional - up it until we have 1. 4 CR1/4 = EL1. More than 12 should not be used to provide challenge, as they individually are too weak (and would lag us to high heaven).

This tells me we can sum all fractions, add up all of any CR, run N%2 > 0 recursively on each. I'm not sure of an elegant algorythm for the mixed set though.

If we're not running this through XP calcs, it doesn't matter that we calc EL from CRs. If that is the case, we simply need to generate a set of CRs for the builder specified EL (or organically grown EL). We should have a flag for single, group, or tribe - this tells us if we want to make a single CR11, 2-X of whatever doubles to 11, or build a pyramid of CR1, CR4, CR7, ... For this latter, we can likely fudge one CR either way, so 4 CR1 take a CR3-4 slot.

EL7 Tribe:

Drop 4, have a quad of EL3.

|

CR3 + 3(EL3)

|

Drop two (since we can't drop 4 and don't have a pyramid), have a pair of EL1

|

CR3 + 6(CR1)

Each CR will be a group spawn pulled from everything matching that tribe with CR +/-1 of that CR. If we are pulling CR1, we may pull a fractional CR, in which case we spawn 1/CR.

I chose to drop 4 to give us a pyramid shape. As long as dropping 4 is 5+, we pull one off and drop the rest 4. EL 21 is CR 17, 3*13, 9*9, 27*5, 81*1... this may not be a good idea unless we're running AMD10K+.
PC: Bot (WD)

Code: Select all

     -----          -----          -----          -----
    /     \        /     \        /     \        /     \
   /  RIP  \      /  RIP  \      /  RIP  \      /  RIP  \      /
   |       |      |       |      |       |      |       |      |
  *| *  *  |*    *| *  *  |*    *| *  *  |*    *| *  *  |*    *|
_)/\\_//(/|_)(__)/\\_//(/|_)(__)/\\_//(/|_)(__)/\\_//(/|_)(__)/\\_(
User avatar
ç i p h é r
Retired
Posts: 2904
Joined: Fri Oct 21, 2005 4:12 pm
Location: US Central (GMT - 6)

Post by ç i p h é r »

Right. We'd calculate XP based on the CR of each creature defeated and the PC levels involved (to highest PC level IIRC).
Fionn wrote:I chose to drop 4 to give us a pyramid shape. As long as dropping 4 is 5+, we pull one off and drop the rest 4. EL 21 is CR 17, 3*13, 9*9, 27*5, 81*1... this may not be a good idea unless we're running AMD10K+.
I think a pyramid algorithm is a good balance between quantity and quality, but to avoid predictability, we could use a method chosen at random by the encounter system. For instance, your EL21 may be a CR21 creature or it could be two CR19s, or eight CR15s, or a pyramid of CRs like you laid out.

If we can make the spawn point setup easy for builders AND avoid predictability of spawn points to players, it'll be a really easy to use system that's more challenging to farm.
Ronan
Dungeon Master
Posts: 4611
Joined: Sun Feb 20, 2005 9:48 am

Post by Ronan »

Is this relevant? Most people seem ademant that ALFA spawns should not scale to party level, at least not in any noticable way. For that reason, I don't think we'd want a spawn system using EL.
User avatar
Fionn
Ancient Red Dragon
Posts: 2942
Joined: Sun Jan 04, 2004 7:07 am
Location: Seattle, WA

Post by Fionn »

Builder choice of Single, Group (2, 4, 8 of CR-2, 4, 6), or Tribe (pyramid). This would be a tag on the spawn point. This allows me to put a % chance for a BIG mob in an area, without letting it randomize, a % chance of several raiding parties (2 Ettins, 4 Ogres, 8 Orc), or a big tribe of whatever. The tribe can either be static (spawn % limited by DimRet per partymember), or organic (spawn % limited or enhanced by DimRit per previously killed.)
PC: Bot (WD)

Code: Select all

     -----          -----          -----          -----
    /     \        /     \        /     \        /     \
   /  RIP  \      /  RIP  \      /  RIP  \      /  RIP  \      /
   |       |      |       |      |       |      |       |      |
  *| *  *  |*    *| *  *  |*    *| *  *  |*    *| *  *  |*    *|
_)/\\_//(/|_)(__)/\\_//(/|_)(__)/\\_//(/|_)(__)/\\_//(/|_)(__)/\\_(
User avatar
Fionn
Ancient Red Dragon
Posts: 2942
Joined: Sun Jan 04, 2004 7:07 am
Location: Seattle, WA

Post by Fionn »

nm - i see you are moving most of that functionality to the spawn system.

EL would just be then to figure out what groups are available, and choose appropriate mobs from them to pass to spawn system.

Ronan - system doesn't scale to party, system scales by either builder tagging (Blacktooth Crags have an EL13 chance), or by organically grown tribes (Orc WP hasn't been killed in 50 days, it is now up to EL10).
PC: Bot (WD)

Code: Select all

     -----          -----          -----          -----
    /     \        /     \        /     \        /     \
   /  RIP  \      /  RIP  \      /  RIP  \      /  RIP  \      /
   |       |      |       |      |       |      |       |      |
  *| *  *  |*    *| *  *  |*    *| *  *  |*    *| *  *  |*    *|
_)/\\_//(/|_)(__)/\\_//(/|_)(__)/\\_//(/|_)(__)/\\_//(/|_)(__)/\\_(
Ronan
Dungeon Master
Posts: 4611
Joined: Sun Feb 20, 2005 9:48 am

Post by Ronan »

Fionn wrote:Builder choice of Single, Group (2, 4, 8 of CR-2, 4, 6), or Tribe (pyramid). This would be a tag on the spawn point. This allows me to put a % chance for a BIG mob in an area, without letting it randomize, a % chance of several raiding parties (2 Ettins, 4 Ogres, 8 Orc), or a big tribe of whatever. The tribe can either be static (spawn % limited by DimRet per partymember), or organic (spawn % limited or enhanced by DimRit per previously killed.)
Hrm, I think this is sort of stepping on the toes of the spawn system a bit... As I had invisioned it, the encounter system should generate the spawns the first time a PC enters an area, based on local populations (the builder defines how what sort of creatures reside in certain areas, and how many of them).
User avatar
ç i p h é r
Retired
Posts: 2904
Joined: Fri Oct 21, 2005 4:12 pm
Location: US Central (GMT - 6)

Post by ç i p h é r »

I've drawn the line as follows:

Spawn = apply spawn point rules (ie all the static parts)
Encounter = manage spawn points (ie all the moving parts like tracking and scaling spawn points)

If anyone sees it differently, let's work out a definition that's clear so we avoid crossing requirements.
Ronan
Dungeon Master
Posts: 4611
Joined: Sun Feb 20, 2005 9:48 am

Post by Ronan »

Hmm, the problem is that random encounters shouldn't really have spawn waypoints. And even static spawns could stand to be more intelligent, ie kill a few guards in Beregost and it will take a while for them to get replaced. Is there any clear advantage to seperating these systems? I'm thinking maybe I was wrong to try to.

Another question is, how do we define to what population a spawn belongs to? Faction? But then many servers have far more spawn camps than factions, and we don't want a destroyed camp at point A to reduce numbers at point B.
User avatar
Fionn
Ancient Red Dragon
Posts: 2942
Joined: Sun Jan 04, 2004 7:07 am
Location: Seattle, WA

Post by Fionn »

Encounter system can simply create spawn waypoints. This allows the builder to use whichever is more appropriate.

I'm not sure if we should use the EL system to override normal drops, or simply augment it. Personally, I'm leaning towards very light drops (IC, worthless soiled goblin armor and flint weapons don't drop). Mobs should drop unused potions/scrolls/ammo and other such consumables, with a small chance for some coinage or gems. DMs can use a system like I've got in TPI to manually load out pChests for the spawn areas. This allows us to tightly control any real wealth, while allowing PCs to earn back enough to keep adventuring.

One thing to note on that - if we want a +1 sword to be unusual, it should cost more than 3 potions to the PC that might be using it (CMW at that level). This likely means we drop the prices &/or availability of consumables. One easy way is to make sure they're dropping from our mobs.
PC: Bot (WD)

Code: Select all

     -----          -----          -----          -----
    /     \        /     \        /     \        /     \
   /  RIP  \      /  RIP  \      /  RIP  \      /  RIP  \      /
   |       |      |       |      |       |      |       |      |
  *| *  *  |*    *| *  *  |*    *| *  *  |*    *| *  *  |*    *|
_)/\\_//(/|_)(__)/\\_//(/|_)(__)/\\_//(/|_)(__)/\\_//(/|_)(__)/\\_(
User avatar
ç i p h é r
Retired
Posts: 2904
Joined: Fri Oct 21, 2005 4:12 pm
Location: US Central (GMT - 6)

Post by ç i p h é r »

For monsters, I'd say popluation is based on type. For humanoids, I'd say population is based on race. We could get really complex by breaking it down into regions and/or tribes, but I'm not sure that kind of complexity will be worth it or appreciated.

Perhaps "manage spawn points" is a poor generalization but I'm not sure how else to state it. Random encounters can be implemented in a number of places, from hooks in event scripts (like resting or transitioning) to a % chance at spawn points (placed or organic). The tracking of kills I see as part of the encounter system so if a spawn point has been farmed excessively, it could adjust the spawn rules at that spawn point to compensate.

Let's flesh out the details of these two systems as much as we can and then decide if the overlaps are too great for them to realistically operate independently. They may not even if we decide to log the requirements separately.
Ronan
Dungeon Master
Posts: 4611
Joined: Sun Feb 20, 2005 9:48 am

Post by Ronan »

Fionn wrote:Encounter system can simply create spawn waypoints. This allows the builder to use whichever is more appropriate.
Well, there are situations where the encounter system needs to spawn something without a waypoint generated. And there are situations where the spawn system needs to be aware of local populations when it spawns something at a spawn waypoint.

I had planned to use the same loot-generation scripts for all monsters, regardless of how they were spawned or who spawned them. These scripts are tied directly into the wealth standards, which spell out how much a spawn of a given CR should drop. Unless there is a good reason, I'd like to keep that system in place and working the same for every creature. That allows us to change spawn drops, and the wealth of the whole of ALFA, by changing one script (name acr_wealth_i). If builders want to create custom loot drops, they can script their own using the provided APIs (with a template for a guide) but ultimately the buck should stop at the wealth standards IMO.
Locked