This is a method for spawning random creatures in random numbers from a list.
The main feature is that if spot listen checks are not made nothing is spawned.
Included are both a trigger method and a psuedo hb, which is set to retire after 20 tries. The trigger is on a 30 second delay.
The monsters are all the same in the lists, but this is just an example. You
want tougher monsters in the harder to spot categories. Also the spawns are scaled.
I added in a distance/direction check from a suggestion by --theinquistor.
Regarding that comment that you were spotted. I only used standard bioware creatures in the demo, so if they noticed your low level characters they must have lousy move silently and hide skills.
Thanks for the comments and for checking it out. You have that exactly concerning the standard repetition which occurs with the default encounter system. Essentially this, the random spawn method, was meant to replace and/or accentuate the default spawning method.
It is very flexible in regards to numbers of creatures that appear and how tough they are. The designer sets up the creatures usually 1 of 6 possible creatures shows up. In this way you can have variety within certain parameters. So you could set up various ecounters trigger with different creatures based on terrain type, time of day, etc...
You can also determine the number of time the encounter will retrigger, go off again, set intentionally high in this demo, as you indicated from your play-test. What this allows is a more emergent, organic, less predictable feel to creature encounters.
For instance in a typical fight you hit a trigger and spawn x number of creatures. The party defeats them and you move on. Now with this method the script is firing over and over again spawning different but perhaps the same creatures, simulating the idea of the intial encounter attracting additional combatants. An example of a use for this method would be an area infested with goblins, bugs, etc.. similar to the demo. So an area to move through, or if you are tough enough stay and fight to gain xp and then get out. This is much more challenging to players and at the same time more realistic imo.
ffbj, you managed to break the "Groundhog day" symptom common to most PWs and for this alone, all module makers should check this out.
Is the game balance improved using this method? I can only say may be but I would still prefer this to the default Bioware one, because the default makes little sense to me and is certainly not properly balanced.
I loaded thew above demo module on my server and gave it a shot with 5 characters (those on my server vault). Three of them had no equipment so it was a bit tough. I got the most of this with a lvl 2 monk except that the encounters seems to never stop. He met 8 groups of creatures mostly 1-2 at a time but once he had 3 goblins and once 4 beetles. If there was a safe place to rest I assume that he could cross the woods and continue his journey. My F1/C1 met nothing at all. My F2/S8 with hellhound met the same bunch of critters my monk did so I assume that the demo is most likely for level 2-4 or something like that. My fighter 2 met three birds and my rogue 1, 3 goblins. I guess my fighter could have done well if he was not naked. I guess my hobbit rogue (naked) was just unlucky to face 3 hunting goblins who had spotted him.
Bug or features? Except for my invisible mage, all my characters (including the stealthy ones) were spotted by the (visible) creatures in the forest.
In regards to your other point. The story concept linked with the various scripting elements can certainly make or break a module.
It's as if you are a stage manager setting up the various props: scripts, lighting, dialogue,etc... to accentuate the story. That is, story is not only related verbally. This is a basic though, somewhat undervalued concept. I do come from a writing background , so I may just write an atricle, as you suggest. Thanks for the idea.
Thanks. Yes it is more a method than a system. That is true. Mostly I just do stuff and toss it up on the vault. I am not really so good at publicizing my stuff, but here and there people find something they can use.
In regard to the interview, this spawning method is part of the methodology I use which integrates additional concepts to achieve a particular effect. This spawning method is one piece of the overall whole.
You may want to take a look at 'Mission to Askalon' which incorporates some of my other ideas on design. For instance, spawn objects, and spawns based on monsters which act as mobile spawners.
Thanks again for the comments.
Posted by Inayity at 2008-08-25 08:02:12 Voted 10.00 on 08/25/08
FFBJ, I first came across this looking for spawn systems. After reading your description, I searched some more and found the NWN Podcast where you were interviewed. I looked at the module and listened to you describe your "system" though I guess it's really best-described as a "method", at least from my understanding of it so far.
This is not just cool, it's _important_. It's too bad that samples like this don't get many downloaders and even fewer votes, because you touched on something which shows what Neverwinter can be, if people would stop focusing so much on building and spend more time _telling_a_story.
Anyway, thank you for taking the time to make this. I would really like to see you write something, about the merging of storytelling and NWN, because I know I'd read it and anyone else who did would probably realize how much _more_ can be made with the toolset.
To anyone using this, you may notice that spawns will continue even after pc's have left the are, if the Ran local has not been exceeded. In mine I have safe areas which will interrupt this. This is how I did it.
ExecuteScript("onentersafe", oPC);//add this to areas you consider safe
void main ()//call this script onentersafe.
{
object oPC = GetEnteringObject();
DelayCommand (10.0, SetLocalInt(oPC,"Safe",1));
DelayCommand (60.0, DeleteLocalInt(oPC,"Safe"));
}
if (GetLocalInt(oPC,"Safe") == 1)
return;//goes in on random spawnlisten toward the top.
This is fairly self-explanatory but for clarity's sake. On the onenter of your safe areas you want to put the exectue script line, and then the name of your script.
This will execute the script and set the local safe on the pc, thus limiting bleed over.
Finally you want to add the return condition to the random spawn listen script, and set the local on the safe area to Safe to 1.
Sure thing. You can certainly customize it any way you want. One of the main features is the uncertainty of what will spawn and where. The standard spawning methods are too predictable, imo. With most spawners you hit a trigger and spawn the same thing in the
same place. You remove one of the most vital elements for making the game exciting. With this method things can get worse over time, unlike the standard method where once you defeat the initial impact of the encounter it is pretty much over.
Thanks for the comments.
Thanks for the quick reply. After playing around a bit I answered my own question! For my purposes, I've removed the spot checks, increased the delay to 60 seconds, changed the switch to a d10 and changed the "Resets" and "Spawn" variables (already in use in another script) to "RESETS_areaX_##" and "Spawn_areaX_##" to accomodate multiple versions of this script.
If (when) I have future questions, I'll post them in the forum. Thanks again for the quick reply, and for making this script available.
BS
PS--I'll vote once I've played with it a bit more
void main()
{
object oPC = GetEnteringObject();
object oArea = GetArea(oPC);
if (!GetIsPC(oPC))
return;
if (oArea != OBJECT_SELF)
return;
int iReset = GetLocalInt(OBJECT_SELF, "RESETS");
if(iReset == 1)
return;
{
SetLocalInt(OBJECT_SELF, "RESETS", 1);
SetLocalInt(oPC,"Ran",0);
DelayCommand (30.0, ExecuteScript("spawnrandomm01",oArea));
}
DelayCommand(100.0, SetLocalInt(OBJECT_SELF, "RESETS", 0));//alter reset up or down.
}
All this really does is set up the firing of the executable script 'spawnrandom' It also sets up the local Ran, which is used later to determine how many times the spawn script runs. Next we have the spawner:
#include "NW_I0_GENERIC"
void main()
{
int nCreature, nNumber;
string sCreature = "";
object oPC = GetFirstPC();
object oArea = GetArea(oPC);
if (!GetIsPC(oPC))
return;
if (GetLocalInt(oPC,"Ran") >20)
return;//script will only run 20 times, default would be 10
//Cycle through PCs in area
{
object oPChp = GetFirstPC();
while (GetIsObjectValid(oPChp))
{
iHdTemp++;
iHdTemp += GetHitDice(oPChp); //trying to add the pc's in the area hp
oPChp = GetNextPC();
}
{
if (iHdTemp < 10)
SetLocalInt(oPC,"Spawn",1);
else if (iHdTemp < 20)
SetLocalInt(oPC,"Spawn",2);
else if (iHdTemp < 30)
SetLocalInt(oPC,"Spawn",3);
else if (iHdTemp < 40)
SetLocalInt(oPC,"Spawn",4);
else
SetLocalInt(oPC,"Spawn",5);
if (d100() > 75 + iHdTemp)//set between 50-75, set high for demo
return;
{
if ((GetLocalInt(oPC,"Spawn")== 1) && (GetIsSkillSuccessful(oPC, SKILL_LISTEN, 5)))//easy
{
SendMessageToPC(oPC, "You Hear Something!");
switch (d6())
{
case 1: sCreature = "nw_btlfire"; break;
case 2: sCreature = "nw_goblina"; break;
case 3: sCreature = "nw_badger"; break;
case 4: sCreature = "nw_goblina"; break;
case 5: sCreature = "nw_stirge"; break;
case 6: sCreature ="nw_goblinb"; break;
}
for (nNumber = 0; nNumber < d4(); nNumber++)
CreateObject(OBJECT_TYPE_CREATURE, sCreature, lWP, FALSE);
Go can see at the bottom how the script continues to execute itself after a delay a certain amount of times. All these plugin values can be changed. So the script will continue to run until the local Ran is exceeded or there are no pc's in the area.
By simply removing the execute line at the bottom you could make this into a trigger script too, or into a trigger that fires a number of times. Usually I do demo's as they are, in a sense my way of documentation. 'A picture is worth a thousand words,' so to speak.
So there is a bit of documentation for you.
That's right. The trigger is separate. Just drop in the random spawn script with the t in it, t for trigger, and you are all set. I recently updated the hb to give distance/and direction but you can easily convert that to a trigger too. I don't do much in the way of documentation, as most of my scripts are fairly simple and straightforward.
Thanks for the comments.
Checked out the demo and the original thread, and I have a newbie Q (yikes!): you mentioned the demo used two methods to trigger the spawns: the pseudo-hb script in the area's onEnter, and the "spawnrandom..." script in the trigger's onEnter. If I only use the trigger, I don't need to worry about the area onEnter script, correct? I can just use the triggers only and not the pseudo-hb?
Sorry for such a simple question, but there's no documentation in the demo (hint, hint...).
Thanks in advance
BS
...just kidding about the documentation ;) I appreciate everybody's contributions.
Posted by Shargast at 2008-01-06 06:48:09 Voted 10.00 on 01/06/08
I've used this script set and it is rock solid!
Cheers
Shargast _________________________ Realms of Shargast V1-V5ab, LOTR V15, The Undeath Clave & Faithful of Aerth
Cool. It's eminently tweakable. Glad you found it useful. Thanks for the vote.
Posted by Archduke at 2007-05-24 12:51:19 Voted 9.50 on 05/24/07
Well the least I could do was return the favour and vote for something of yours! I am actually very glad you made this as, with a very tiny amount of tweaking, I was able to adapt it into a VERY useful 'wandering monster' system, much more suitable than the HotU default one. And it's so very simple to configure too without having to dabble with .2das!!! Thank you, ffbj!
You must be Logged In to post comments in this section.
Site
