Feature Specification: Spawn System

[Ronan]

Alright, I've thought about it some more, and I think we were right in that they should be two seperate systems. The encounter system should only spawn things by placing spawn points, and the spawn system should only talk to the encounter system to ask what to spawn (in the case of spawn camps, not individual spawns). I think we need to break this problem down into smaller parts if we are going to tackle it, namely faction population (population system), encounters (instances of populations) and spawns (instances of encounters, or statically placed).

I'd like to expand or re-do some parts of Cipher's specifications, as follows:

Functional Requirements
The spawn system will handle the spawning and de-spawning of objects in areas.

For the player
Ideally, the player would never know the spawn system existed, not having the opportunity to see any evidence of its existance.

For the builder
The building will place spawn points by placing a waypoint with a specific tag in an area. He will then let local variables on this waypoint to determine its behavior. These variables will have descriptive, intuitive names so that there is as little confusion as possible with builders, and they will come listed on the waypoint blueprint included in the spawn system. The options these variables represent could include the following:

• Spawn ResRef (for use with single-type spawns)
• Spawn group name (for use with the population system)
• Spawn group strength
• Spawn name
• Spawn name prefix
• Spawn name suffix
• Spawn faction (lets hope Obsidian gives us this ability)
• Spawn-in script(s) (possible array of local strings)
• Respawn count (maximum number of times the spawn will activate if its children have been removed from the area)
• Respawn delay (in game-time)
• Spawn-in radius (float distance value)
• Spawn persistance flag (whether or not the child object will be spawned normally, or loaded from the database and saved upon despawn).
• Spawn hour
• Despawn hour
• Spawn chance (0% to 100%)
• Spawn day (1 to 10)
• Despawn day (1o to 10)
• Spawn month
• Despawn month
• Spawns in rain
• Spawns in snow
• Spawns in * weather (ie, other types of weather we haven't defined yet, relates to the weather system)
• Spawns in sight of PCs (whether or not the spawn point will activate if a PC is watching)
• Respawns with PC in area (whether or not the spawn will respawn if PCs have not left the area).
• Spawns when PC nears (distance float value)
• Spawn in VFX
• Spawn in SFX
• Uses spawn-in animation
• Whether or not the spawn is active or disabled

For the DM
Functions should be present to allow external systems to add, modify and delete spawn points. Functions to modify existing spawn points should include, at the least:

• Enable/disable
• Respawn count
• Group strength
• Respawn delay

Ideally, all spawn-point data should be changable via function calls to the spawn system.

NWN Object Dependencies
Waypoints.

Logging and Debugging (global LOG & DEBUG (on/off) constants)
All resrefs spawned will produce debug output on the informational channel. Resrefs not found will produce warnings.

Persistence Requirements
None in itself, the encounter system handles persistance.
If the child persistance option is implemented, a seperate subsystem could be used to store and track saved creatures, since this functionality would undoubtably be used for other purposes.

Event Dependencies
OnAreaEnter, OnAreaExit, possibly others.
Custom events could be added to each spawned child to track whether or not the spawn has been depleted. But I'm not sure if DestroyObject() would bypass this.

Dependancies on other (sub)systems
Population system, encounter system, deubugging system, time system, possibly custom events system, possibly persistant object storage system.

Design Comments
Behind the vault, NESS is the largest source of burst-lag I have seen. Spawn-lag on area ATs has killed many PCs, and this is totally unacceptable to me. Though I have no proof, I suspect the cause of this lag is two-fold: looping through every object in an area and parsing waypoint tags, and so many CreateObject() calls at once. Some strageties I can think of for aiding this are:

• Loop through all spawn points in the module OnLoad, and cache them to local variables on areas. Combine boolean flags into single bitwise integers, and destroy the waypoints as you progress.
• At the very least, begin spawning creatures when a PC exits an area (by retrieving his destination OnExit).
• Possibly "cache" areas by slowly spawning in areas the PC is near, spreading CreateObject() calls over a longer period of time.

Comments?

[ç i p h é r]

Alright, I've thought about it some more, and I think we were right in that they should be two seperate systems. The encounter system should only spawn things by placing spawn points, and the spawn system should only talk to the encounter system to ask what to spawn (in the case of spawn camps, not individual spawns).

Ok. I think that's about where we were last. Spawn system processes spawn waypoints and creates the specified objects. Encounter system manages population, handles growth (creation of new spawn waypoints), and controls random encounters.

Now, how do we define random encounters? Encounters while resting, traveling, or standing around in one place too long? I don't think spawn waypoints qualify as "random". We should make this separation clear in the specs for each system.

I see you added a few more spawn waypoint control options. They certainly look useful. FYI, the "local variables" in the spec format are what we want to expose to external systems and cross referenced in the system they are used by. So, for instance, the Omega Wand also refers to the same local variables we have listed here for managing spawn waypoints so it's clear what data it will be manipulating.

On the persistence end, I don't think the spawn system needs to concern itself at all with that, but the encounter system should preserve population levels and organically grown spawn waypoints, unless we want server resets to restart the whole process. It might make sense from a server maintenance perspective to clear load/lag from execessive spawns, but it would really ruin the immersion particularly if the build up of spawns in a region is affecting the players there. If spawns are lagging the server, the DMs should be able to simply destroy the spawn waypoints via the DM wand.

Also, I like the idea of caching spawn waypoints on module load. It would simplify the matter of saving/restoring spawn waypoints at the cost of time at the initial load stage. Most people use that time to grab a drink or hit the bathroom anyway so it's a workable strategy IMO.

[Ronan]

Ok. I think that's about where we were last. Spawn system processes spawn waypoints and creates the specified objects. Encounter system manages population, handles growth (creation of new spawn waypoints), and controls random encounters.

Now, how do we define random encounters? Encounters while resting, traveling, or standing around in one place too long? I don't think spawn waypoints qualify as "random". We should make this separation clear in the specs for each system.

This is what had given me pause as to whether or not we should seperate the spawn and encouter systems. At first I thought that random encounters should not have a spawn point, but then I realized that a random encounter should not be a one-off thing. If a random encounter is generated in an area, it may not necissarily disapear when a PC leaves that area. So a random spawn must persist for some amount of time, and thus have its own spawn points.

I would say the spawn system can only spawn from spawn-points. The encounter system can tell it to add or remove spawn points, and thus an encounter would become anything not statically defined by the builder.

I see you added a few more spawn waypoint control options. They certainly look useful. FYI, the "local variables" in the spec format are what we want to expose to external systems and cross referenced in the system they are used by. So, for instance, the Omega Wand also refers to the same local variables we have listed here for managing spawn waypoints so it's clear what data it will be manipulating.

Hmm, my thoughts were a bit different. I had thought the local variables would only be used by two sources, the spawn system and builders editing a waypoint. If we make a DM Spawn Tool, it would include the spawn system's include script and call functions to manipulate the spawn points. While I think this is especially important if we end up caching spawn point data as local variables, this is the sort of modularity I'd prefer to see on all systems. Thats why if you look at a lot of the stuff I've got up, nearly all the local variable constants and the storage object are marked "_private".

On the persistence end, I don't think the spawn system needs to concern itself at all with that, but the encounter system should preserve population levels and organically grown spawn waypoints, unless we want server resets to restart the whole process. It might make sense from a server maintenance perspective to clear load/lag from execessive spawns, but it would really ruin the immersion particularly if the build up of spawns in a region is affecting the players there. If spawns are lagging the server, the DMs should be able to simply destroy the spawn waypoints via the DM wand.

Agreed on everything, though I thought there may be instances where a builder would want a certain named NPC to be persistant in inventory, status, etc. This is a minor feature though.

A big reason I want a persistant encounter system is to remove the ambiguity between farming and adventuring. There shouldn't be any way for a PC to farm a spawn, because spawns should simply run out and be destroyed after everything is killed. Add some randomness to this, and you've got new meanings to static quests based on scouting, as well as search-and-destroys. And all repeatable, without the OOCness of hitting the exact same spawn point you hit last week.

Also, I like the idea of caching spawn waypoints on module load. It would simplify the matter of saving/restoring spawn waypoints at the cost of time at the initial load stage. Most people use that time to grab a drink or hit the bathroom anyway so it's a workable strategy IMO.

I'd like to create some simple tests to see what is the largest source of NESS-lag, CreateObject() or looping through area objects to find waypoints. I'm thinking its more the former, but I'd bet the later isn't very quick either.

[ç i p h é r]

I would say the spawn system can only spawn from spawn-points. The encounter system can tell it to add or remove spawn points, and thus an encounter would become anything not statically defined by the builder.

Ok so do away with the PnP notion of a random encounter (which is that the DM rolls the dice to see if anything comes along under certain situations) and leave it up to spawns to roam about and bump into something/someone? In a persistent world, that can work and would also allow scouting to be meaningful. On the other hand, spawns walking around means path finding and that means the increased possibility of lag if it occurs excessively.

Hmm, my thoughts were a bit different. I had thought the local variables would only be used by two sources, the spawn system and builders editing a waypoint. If we make a DM Spawn Tool, it would include the spawn system's include script and call functions to manipulate the spawn points. While I think this is especially important if we end up caching spawn point data as local variables, this is the sort of modularity I'd prefer to see on all systems. Thats why if you look at a lot of the stuff I've got up, nearly all the local variable constants and the storage object are marked "_private".

Hmm...so we're doing away with the idea of a singular wand? Or are you just saying that the spawn system exposes the interfaces to the data that the wand can control? The latter is specific to design/implementation. What I was noting in the requirements was just what data the systems would actually WANT access to so we can then build the appropriate interfaces to them when creating the systems.

I'd like to create some simple tests to see what is the largest source of NESS-lag, CreateObject() or looping through area objects to find waypoints. I'm thinking its more the former, but I'd bet the later isn't very quick either.

Not sure if CreateObject() causes lag, but it sure as hell is affected by it. If you've ever triggered a spawn point then witnessed it spawn once you're well past it, you'll know what I mean. That's no good. In this kind of environment, a PC would be able to run by all the encounters before they spawned.

[Ronan]

Ok so do away with the PnP notion of a random encounter (which is that the DM rolls the dice to see if anything comes along under certain situations) and leave it up to spawns to roam about and bump into something/someone? In a persistent world, that can work and would also allow scouting to be meaningful. On the other hand, spawns walking around means path finding and that means the increased possibility of lag if it occurs excessively.

When a PC is entering (or even about to enter) an area, the encounter system runs, possibly calling CreateSpawnPoint() on the spawn system if it finds it needs to place anything. Then the spawn system runs, and doesn't know anything about what the encounter system did. It just processes its spawn points.

I'll post my vision of the spawn system on the other thread.

[quote="ç i p h é r"...the spawn system exposes the interfaces to the data that the wand can control?[/quote]
Thats what I was saying. I wrote in the specs that all of the data listed should be alterable, but in hindsight thats a bit excessive. I think we might want to wait and see how easy Obsidian makes the scriptable GUI, but I'll go ahead and edit my post with a more prioritized list.

Not sure if CreateObject() causes lag, but it sure as hell is affected by it. If you've ever triggered a spawn point then witnessed it spawn once you're well past it, you'll know what I mean. That's no good. In this kind of environment, a PC would be able to run by all the encounters before they spawned.

Yeah I know, thats why one of my goals is to get everything spawned as soon as possible, at the least we should start doing this as soon as the PC steps on seamless AT trigger.

[Blackwill]

Thinking out loud in the thread about Static content, it led me astray from something which might belong here. The following might belong in the Encounter thread too.

Basic question is: How can we make NPCs of all kinds (inluding monsters) not be static, but rather dynamic and change. With this I mean, the number of spawns, place of spawning, the type of NPC spawned.

An example can be the following:
A tavern:
Player enters -> spawns activated -> 5 sailors at a table, 2 merchants at a table, 1 hooded person at a table, two farmers at the bar, two serving girls, the barkeeper.
Spawns randomly (with a mimimum of time that passes within the Inn), and possibly in group, leave the tavern. While at the same time randomly , and possibly in groups, some new spawns enter via the door. After X game hours without a PC within the area the number and type of spawn change, excluding a few like the barkeeper, and his tw serving girls. Certain hours will have higher activity than others. NPCs leaving and entering will also have this as a factor.

A cave:
Player enters -> spawns activated -> goblins and bats are the only spawn in the cave. A minimum and maximum number of both spawns are in the script. A roll gets done to see how many goblins and bats are in the cave. Time is another factor which should be added in to apply having higher or lower number of spawns.


Spawn type and numbers should be editable on the fly by DMs and should be persistant.


Thoughts?

[Fionn]

That's pretty much how NESS works now Bw. The way I read the proposal above, Encounter system would define what spawn points exist in each area (%, day, night, per hour, etc), and the spawn system would handle the actual spawning.

If we call SetEncounters(), CreateSpawns() as part of the AT system, we may find that creates too much lag on the AT. As it is now, there is a rather large lag between *Moving North* and actually moving north. I think this is the use of HB scripts, rather than onEnter, but I've not checked it out in code.

My other concern with spawning before a PC moves is making sure we check for the PC's target *and* PCs when spawning. Unless the encounter is supposed to be an ambush, they shouldn't be on top of a PC.

[Ronan]

If we call SetEncounters(), CreateSpawns() as part of the AT system, we may find that creates too much lag on the AT. As it is now, there is a rather large lag between *Moving North* and actually moving north. I think this is the use of HB scripts, rather than onEnter, but I've not checked it out in code.

Its deliberate, a DelayCommand(), and something I'd like to keep. In addition, I'd let the AT be cancled if the PC walks back outside the trigger.

My other concern with spawning before a PC moves is making sure we check for the PC's target *and* PCs when spawning. Unless the encounter is supposed to be an ambush, they shouldn't be on top of a PC.

Not, sure I understand this? Better to spawn before the PC has ATed, so the server doesn't lag and the monsters spawn on top of him like it does not.

[Fionn]

If we check for PCs prior to spawning (as we do with NESS), and we then randomly scatter mobs around the area, then we AT a PC on top of a mob that was just spawned.... Dead PC.

Instead, we need to check both for existing PCs *and* scheduled ATs into the area. Likely just create a temp WP for the PC to port to just prior to calling SpawnMobs().

[Ronan]

Oh. I was just going to have the encounter system only create spawn points a certain distance from the area edges. I did forget to post that in the specs though... It should read ranges.2da and not create any spawns close enough for the PC to see when he is spit out from the AT.

Ideally we'd simulate spawns moving through areas well, so encounters could be generated when PCs rest or if they just stand about. These would have to be spawned from the area edges, where an area bordered another with a spawn population in it, and that area didn't have PC(s) in it (to prevent spawns from seeming to pop out of nowhere). But for the first itteration, I don't think this functionality is required

[ç i p h é r]

I'm not sure the situation Fionn points out is entirely preventable, but maybe we could also factor this into mob AI - no loitering around AT's!

[Fionn]

I'm not sure the situation Fionn points out is entirely preventable, but maybe we could also factor this into mob AI - no loitering around AT's!

If we check for PCs *or* PC targets w/i X' prior to spawning, sure. It might slightly lower the chances of an encounter, but *shrugs*. I'm assuming we despawn if the PCs leave.

[Ronan]

I'm not sure the situation Fionn points out is entirely preventable, but maybe we could also factor this into mob AI - no loitering around AT's!

Seems pretty preventable to me, just don't create spawn points within visible range of seamless ATs. If someone has already ATed in an aggroed the mobs to the edge, then its ok to let someone AT on top of those. But otherwise it shouldn't be possible. This is of course assuming despawning of mobs when a PC leaves.

[ç i p h é r]

Spawns can also wander around and might end up standing near a transition when a PC comes through it. The assumption is, of course, that the creatures are either not despawned right away or PCs are still in the area somewhere beyond the perception range of the creatures.

I interpretted the concern not so much that it's bad for monsters to aggregate near ATs but that the monsters will be able to react to a player coming through a transition BEFORE the player can. So, a refined AI may help keep them at a reasonable distance so players have a fighting chance.

[Ronan]

Hmm, we could also keep PCs under cutscene invis and paralysis for a bit as they AT into the area.