26 réponses à ce sujet

[henesua]

Back when I was working on a single player module, I wrote a system for tracking creature data across spawns. It works well for a single player module. Unique creatures have persistent hitpoints and only 1 can be spawned at a time. Populations of creatures can be tracked in terms of deaths, spawns, and limits can be set on the population in terms of max deaths and max spawns.

I am now working on putting this into a multiplayer environment, but realize its not as easy as I thought it would be. This is not technically difficult, but it is a sticky issue of design because it relates to DM preferences. Since I am writting this not only for myself, but also for other DMs who will be running events in Arnheim with me, I'd like to get some general feedback. Even if you don't give a crap about Arnheim, I'd like feedback. I will be posting this to the vault, and your builders or admin might be interested in the scripts.

Given that creatures can be brought into play in one of three ways: spawned by script, spawned by a DM, or placed by a Builder, consider the ramifications that this system would have on the first two methods. The third as far as we are concerned is treated the same as a DM spawn.

Should Spawns by DMs and Scripts be treated with equal precedence?

• Example 1: a NESS spawn point executes and a unique NPC is spawned in an area. Until that creature despawns, no other NESS spawn point will be able to call the NPC forth. BUT should that also restrict DMs from spawning the unique NPC? My inclination is to say that yes, only one instance of a Unique NPC should occur in the module at any one time. But that could be annoying for a DM who needs the NPC for their event, and gets a rejection message. What do you think?
• Example 2: a DM spawns a Unique NPC in one area, and in an adjacent area a NESS spawn point for the same NPC is triggered by the party's rogue scouting about. The NESS spawn point will not be able to spawn the Unique NPC. I am assuming that all DMs would like this restriction, but again... what do you think?

Whats a good way to handle death of a Unique NPC?

• Possibility 1: NPC was killed the day before, and the server has since reset. A DM, not knowing about this, tries to spawn them, and this is the first spawn attempt. The NPC is spawned to a special out of character area, and killed. The DM is told that the NPC is dead, who killed them, and where they can find the dead NPC should they want to bring them back from the dead. All NESS spawns of the NPC simply fail - and DMs get a simple message that the NESS spawn failed due to the NPC being dead.
• Possibility 2: NPC was killed earlier, and the location of their death was stored. The corpse has since despawned. Attempts to spawn the NPC will fail, but DMs will be told why and where the corpse will spawn. Henceforth when any player (DM or PC) enters the area where the NPC died, the NPC is spawned in dead at the stored location. The NPCs inventory is emptied, and any items the NPC last had in their inventory are restored from the DB. All DMs are told that the NPC spawned in dead, where the NPC is, and circumstances about the death. (This would could include a time of death check to determine what the corpse looks like... perhaps)
• Possibility 3: DMs can spawn a dead NPC but it comes in at 1 HP. Likewise NESS Spawns will fail, and inform the DMs that the NPC is dead. Should a DM wish to restore the NPC, they can spawn them, and cast a raise spell on the NPC, and thus erase the death. Otherwise the NPC's death count remains.

Whats a good way to handle Hitpoints of a Unique NPC?

• Possibility 1: Unique NPCs have persistent HP across server resets
• Possibility 2: Unique NPCs have consistent HP from despawn (when HP is recorded) to respawn. This is reset to max when the server resets.

And I suppose the biggest question is:
should limits only apply to scripted spawns? DM spawns would happen independently of this system - except for some text feedback to the DM about the data stored on the creature.

Modifié par henesua, 05 novembre 2012 - 01:54 .

[ehye_khandee]

How exactly is thwarting a DM from spawning a 'unique' creatures supposed to be helpful here?

DMs do what DMs do. Systems should never inhibit a DM from getting at what needs done.

My 2 cents.

Be well. Game on.
GM_ODA

[henesua]

That is why I posed the question, Ehye_Khandee.

I was however hoping for some reasoning behind the opinion. I can't do anything with an absolute. Its not useful and along with most absolutes, wrong in at least some cases if not many.

Given that I am also considering the same as you suggest (that this would not impact DMs) I'd prefer to understand your actual reasoning behind this. Otherwise the 2 cents is worhtless. As should be obvious to another builder and admin, there are many possible benefits from restricting a unique NPC to a single instance. Persistent HP, and inventory being two of the most obvious. But anything related to data becomes cumbersome to track if you have two instances of something that should be unique. Maintaining a sense of immersion for players is of course another consideration, although DMs can usually be trusted with that.

[Lightfoot8]

henesua wrote...

Should Spawns by DMs and Scripts be treated with equal precedence?

I would say yes. If NPC are unique, They should be unique. If the NPC is called for, A check should be given for the area they are in. If there are no PC present, there should be a chance for them despawning and respawning in the new area. I would even give them a chance to flee from the area if they are low on HP.

Whats a good way to handle death of a Unique NPC?

Hard to say on this one. It really depends on the rank/position of the NPC. What the PC's do with the body, after it is killed, and many other factors can come into play. I would give it at least a Game TimeStamp, that it could not be raised before the stamp expired, Reguardless of server resets, Unless of cource the body is directly found.

Or perhaps you would want to give your unique NPC a few minions each that wonder the world, every time they die, looking for them to raise. So if there body way in the grave yard in town, A minion would either have to fight of sneek there way in to raise them. giving them a smaller played out chance to be raised.

Whats a good way to handle Hitpoints of a Unique NPC?

Restore X% hit points per day, Use possesed healing gear(rings,Pots,wands,ect..). Spend excess gold on Healing, Either directly or just x amount of gold per HP.

Of cource if your NPC is a Cleric, Just give them full HP after a few hours. I am sure thy would just go back to there temple and get healed if needed.

Or if there HP are low enough you could say they will only respawn at there home base. basicly they stay home untill they feel that are in shape to go out on the road again.

And I suppose the biggest question is:

should limits only apply to scripted spawns? DM spawns would happen independently of this system - except for some text feedback to the DM about the data stored on the creature.

I feel that a unique NPC should be unique. DM on a server should have no problem working together, If they do, well you then have bigger problems. You may want to concider allowing DM's to add there own unique NPC to the system that only they are allowed to control/spawn.


....

ok My turn.

Should Unique NPC be allowed to loot player.

I kind of like the Idea myself. The more players/monsters he kills/loots the stronger and better equipted he gets.

Why stop at NPC, How about unique Items

I played with this Idea at one time just never implemented it.
Basicly you track the Item in the DB so you always know if it is out and about. If one ever disappeared from the server for X amount of time, You spawn it back into the world. If the player had it, You simply remove it from there inventory when they log back in. You will just need to let your player base know up front that Uniqe items have to stay in play, That if they sit unused in there vault for too long, they will be stolen/sneek-off/wife throws them in a garage sale/ whatever.

I also thought about having the items fall off the PC when they where killed. The item would simply sit there untill something came around and picked it up. Be it another PC, NPC, NPC minion, Or just plain old encounter.


Just some extra thoughts.

[henesua]

Thanks for the feedback, Lightfoot.

I'm not sure how to track whether a unique item is in game. Using Acquire/Unacquire events?

For NPC looting of PCs and leveling, I'd essentially need to store the entire NPC in the database so that everything about the NPC was persistent. My limitation is that I am using the Bioware DB but I could probably make this work. Creating an NPC XP and leveling system would be another requirement.

Considering the concerns about limitations on DMs which I am also sensitive to, for now I am going to leave in the ability to tweak this. the NESS system will have a different hook and initialization process when it creates the creature, and the spawn event which tracks creature spawning will be configurable so that DM spawns can be treated differently, and perhaps I could incorporate different levels of DM permissions. Master DMs would have no limitations.

[SHOVA]

Henesua, I have to wonder why all the effort to handle such a unique NPC/creature spawn. If your worried about adding extra "one only" creatures, that appear via NESS, or the like, why not just tell your DMS possess the unique Ness spawn thing, rather than DM spawn it? Have them Move it, (the Ness won't spawn another, Use it for whatever event, and then put it back. Seems like less hassle for you, as the builder than making some new database.

[henesua]

 A few reasons, Shova.

• This enables more persistency for a Unique NPCs state: death, hitpoints etc... or a population's state: total deaths, total spawns versus limits on these relative to population size.
• It enables me and other builders to create Meta Data that will be applied to the creature when it spawns. Basically the "data object" is a waypoint with a certain tag. The creature upon spawning looks for its data object, and gets updated. Builders can tweak the group by adjusting settings
• AND the database continues to keep track of other data (hit points, deaths, births etc...). so the persistent data gets combined with the settings on the waypoint.

So there are many uses for this beyond what I am describing above as it creates a situation for emergent properties related to individuals and populations. It could even be integrated into an ecology model for a completely sandboxed world.  In this thread I just want to get feedback from DMs as to issues of interface.
But anyway some ideas:Lets say a PC rises to an important position in the game. At present I have created religions and religious institutions, as well as "Inns" that have an "Innkeeper" (An Inn is any place that PCs can stay in, and is controlled by another NPC or PC, but it works well for inns with persistent rooms). Lets say a PC Monk becomes head master of the Monastery in Arnheim. Well you'd think that they'd be able to draw upon a population as henchmen or some other resource. Well with the above system you can track the population's spawns, and deaths and even births (to replace the deaths). Unique NPCs can be associated with the group as well.

[Lightfoot8]

henesua wrote...

 For NPC looting of PCs and leveling, I'd essentially need to store the entire NPC in the database so that everything about the NPC was persistent. My limitation is that I am using the Bioware DB but I could probably make this work. Creating an NPC XP and leveling system would be another requirement.

.

I don't see the Bioware DB as a limitation anymore.   I once thought that the nwnx DB was faster then the internam one.  But Funky in one post came right out and said that It was no faster.   That means that the only real draw back to the DB is its tendencey to bloat, Forcing the server Admin to do rutine maintance to depress it....

Well, the other day I was thinking about how long I have been running my client without reinstalling the Log rotater saver  that I once had installed.   It was a simple bat file that was downloaded from the vault.  It simply took the current log file and renamed it to the current date/Time stamp.   Preventing old logs from being overriten.  Then running the game.  You basicly started the game via the batch file instead of the regular exe. 


It just seems like it would not be that hard to write something along the same lines for a server.   on server resets instead of running the nwserver run a bat file instead that will.   The batch file would run  DataPack.exe, then run the server with a complete command line to start the server.   You could even add a few auto DB backup to the mix just encase something went wrong.  


Sorry for the off topic post.   I just thought I would share the Idea.

[henesua]

At some point I'll have to look into the data packer, Lightfoot. I don't have an intel machine to serve from. My server is an old PPC Mac. If there is a linux utility for packing the NWN DB, I could probably make it work for the mac. Anything like that available?

And no sweat on being off topic.

[ehye_khandee]

Reasoning: Because the builder may know how he/she would like things to be, the DM works with things as they play out. The DM should always be the final arbiter (q.v. DM guide any edition).

Hence, you do not want to trip up the fellow running an event.

Be well. Game on.
GM_ODA

http://playnwn.com

[henesua]

ehye_khandee wrote...

the DM works with things as they play out.

This statement is quite true in NWN. DMs lack perfect information, and thus need a few rails to help guide them. At the PWs I have been part of this has been arrived at by consensus amongst a team of DMs. And in those kind environments I'd agree with the rest of your statements (even though they don't logically follow from one another).

However if you have a server with factions whose power base can accumulate or erode based on how the module itself tracks them... I think you need more than just a team of DMs to set the rules of the game. I think the system has to have a basic structure that defines certain boundaries for how the game is played.

I'm just not sure how best to handle this.

I have however put the code in place today (on the bus) to enable a different treatment of DM Spawning and Script Spawning of Creatures.

Modifié par henesua, 06 novembre 2012 - 03:26 .

[ehye_khandee]

The DMG (any edition) quite nicely defines the DM as "the final arbiter". Read that, you'll see that my statements flow from that quite logically. While the writer of any published module for DND will tell you how the writer envisioned the work, every one I have on my shelf, without fail, declares the DM should change x,y and z as they please. I understand in YOUR specific piece that you envision debut of this work in MAY require you to give a DM 'rails' - but if you are also looking to wide adoption, I might honestly advise making such things an option rather than the enforced rule. As a DM, anything that gets in my way gets ripped out, but then, I'm a scripter too. Why would you want to block the DM from doing what the DM is intended by DND and NWN to do; run an event as if a director? I should think making this another option of your work would make it more conducive to being used widely.

Be well. Game on.
GM_ODA

[SHOVA]

If I understand correctly what Henesua is looking to do, then this system would do two things for the module that uses it, and the DMs that work there.
1st it would make Unique NPCs dynamic, beyond the set to plot and forget about them like most other modules do, and second, it would keep DMs, and even the normal Spawn system from spawning in a dead Unique NPC.

I look forward to this system being made, as I hate the set it to plot and nothing will ever change it. However, this proposed system will not work for every world, and I am curious as to what impact it will have when used with other "dynamic" NPC systems, if it will cause terrible lag, or if it will change how we as builders build from now on.

Ehye, you are somewhat correct. In PNP, what you posted about DMs is true. In NWN PWs, your way off the mark. Typically the builder/host runs the show, other DMs that "work" there follow whatever the host/head DM puts in place as rules. Some PWs may have more defined guidelines than others, and your PW may be the one instance where that is not the case. But for the most part, unless it is "your" PW, DMs answer to the host.

[henesua]

Ehye, I'm asking for feedback on what I am doing, not to be told to stop.

Regarding your comments about making aspects of this optional, yes, I agree. I addressed this yesterday in the thread, and implemented it. This will enable easy adjustment of the system should it be more trouble than it is worth.

With regards to seeking wide adoption etc... you misunderstand my purpose. While I do enjoy sharing my work, I develop it to use it, not for the download count. Sharing is also fun and healthy for the community. Hoping for and encouraging more of it should be the community ethic.

[henesua]

Shova, it is good to know that there is interest. I'll try to keep the system generic enough and simple enough to implement for others. That is always a fun challenge.

EDIT - I must add however that I am hitting a snag. If Unique NPCs are comitted to the database, I need to investigate how personal reputation is handled. I hope it is stripped from teh creature.

Modifié par henesua, 06 novembre 2012 - 04:03 .

[Rolo Kipp]

<keeping an eye...>

I also see application for tracking unique NPCs (and others) in the whole hyper-mod concept. It's would be a major part of allowing "left-over" content from an adventure to be integrated into a larger game-space.

*My* coupla coppers ;-)

<...on the main chance>

[SHOVA]

Henesua,
the snag, of personal reputation.. I have run into it before when the PC respawns, and factions are reset.
I have yet to find a way to adjust reputation for the PC in re-guard to custom factions. For some strange reason, Bio- thought we would only need 4 factions.

From what I have been able to gather, is it is stored locally which is why its a major undertaking to work around it. I suggest storing the faction data on a custom skin for the said NPC.

As far as making this customizable, the documentation is going to have to be pretty good, as your dealling with advanced NPC handling.

Modifié par SHOVA, 06 novembre 2012 - 06:49 .

[ehye_khandee]

henesua wrote...

Ehye, I'm asking for feedback on what I am doing, not to be told to stop.

Regarding your comments about making aspects of this optional, yes, I agree. I addressed this yesterday in the thread, and implemented it. This will enable easy adjustment of the system should it be more trouble than it is worth.

With regards to seeking wide adoption etc... you misunderstand my purpose. While I do enjoy sharing my work, I develop it to use it, not for the download count. Sharing is also fun and healthy for the community. Hoping for and encouraging more of it should be the community ethic.

If you READ it, you'd know it WAS a suggestion on HOW  -   make such restaints on a DM OPTIONAL to make your system more universally usable. DMs run things as it happens in NWN, what a group of PLAYERS do to what the BUILDER had in mind will often be made to work or not work by the skill of the DMing. This goes for NWN as well as PNP. This is all the same game underneath it all and the DM client is what makes this computer game special.

Be well. Game on.
GM_ODA

[henesua]

Ehye, not interested in arguing with you. We've already been through this.

[henesua]

I'm getting feedback from other sources as well. A bit exhausted after hashing this over and over and dealing with design of the organization for the data, but I think I may have something more substantial in a few days.

Here's a cut and paste of another exchange I am having about this.

An old friend from Vives asked....
- Could you provide two scenarios, one with unique creatures and one without, to show the difference between the two and the purpose of having this system in place?

Lets try it this way. A Monk PC has discovered that the NPC Master (unique NPC) of their monastery was using other monks irresponsibly to further a cause that the PC opposes. So the player tells a DM that they want to take over control of the monastery. The DM helps facilitate a player driven event in which the PC defeats the NPC master. Due to the conflict a number of the rank and file (generics of a type) leave and a number stay (based on the PC monk's reputation in the monastery), but the PC is now in control of the monastery. The PC now has some of the rank and file to draw upon should they be needed, and the former master has been removed as a member of the monastery. If the former master NPC survives it could remain a member of the other nefarious group it was a member of. Perhaps this other group now has a population of rank and file monks as well that DMs can use to harass the now PC run monastery.

Granted I don't have the ability to enable such to happen yet. But this system of data tracking is critical in implementing it. While the DM would be needed to help the transfer of leadership. Once the PC is in control, they would have the monastery's resources at their command, and not need a DM to exercise this power. The DM could move on to other things, and let the module track reputation, and such at the monastery perhaps periodically adjusting how many loyal rank and file NPCs remain, and providing other feedback to the PC to indicate their success or lack thereof in running it.

===

To those in the know, this should look a little like what Border Kingdoms was doing, but the intention is not to rely on DMs for everything and thereby, hopefully, limit DM burnout. I would think that anyone following my project closely would have realized that I have been aiming for something similar as well - as my background system puts PCs into different groups that are in conflict with one another (the world has a civilized versus wild conflict for example).

Well now that Border Kingdoms is gone, rather than keeping my module private for session based play, I am trying to get my module ready to fill the same niche. And I learned a bit from playing on that server and seeing how their henchman system worked. I am borrowing that and seeking to apply it here with this population management and unique NPC management. In case anyone is wondering how I intend to use all of this.

Might as well let the cat out of the bag even though I am far from being able to release this. After all this talk I am excited by what I am finally seeing as possible.

And with that said... I need a break. Been a long day and my head hurts.

Modifié par henesua, 07 novembre 2012 - 05:34 .

[ehye_khandee]

Ignore this if you think it an arguement (in error). No argument here, but I don't see where the point I was making was treated with anything but dismissal. If I missed the "Oh, OK, we'll make that an option" somewhere feel free to quote and bold it in your reply to this.

Be well. Game on.
GM_ODA

[henesua]

One example early on

henesua wrote...

Considering the concerns about limitations on DMs which I am also sensitive to, for now I am going to leave in the ability to tweak this. the NESS system will have a different hook and initialization process when it creates the creature, and the spawn event which tracks creature spawning will be configurable so that DM spawns can be treated differently, and perhaps I could incorporate different levels of DM permissions. Master DMs would have no limitations.

Similar comment made later, although shorter, in direct response to you in which I mentioned that I had coded this flexibility into the system while on my commute and had it working.

If you missed these comments fine. No hard feelings. And I appologize for taking your stance as combative. I figured that my agreeing with you and explaining how I had taken such concerns on board would be enough to move on. That you missed this hadn't occurred to me as I am very deep into this and as a non-programmer with a completely different kind of set of professional skills - over my head. Sorry for being so close to the task at hand to have neglected taking a step back and realizing that you missed my comments. Admittedly they buk was not in direct response to you.

Anyway, moving on. Gotta figure out how to design my data to work for this... but maybe tomorrow. Head hurts. Just... tweaking a few more lines of code... before i step away.

[SHOVA]

Henesua,
How will reputation change in the database you are making? Will it change via DM widget? Actual conversation with NPC? Or have you come up with some alternative?

I ask this because I see a unique, and possibly unintended use for your system.
Merchant implementation in NWN has always bothered me. While the APPRAISE skill check does work, after a few levels and skill dumps it is a joke. Now with your system in play, the merchant could adjust the price of the store based on Appraise, and what data has been added to the database. Once the PC sees the prices, they could well kill the merchant, have their reputation for killing merchants with outrageous prices added, and then when a new NPC merchant spawns in a day or to, and using the data, give the PC Walmart low prices.

[henesua]

Regarding reputation - admittedly I have not spent a lot of time digging into this yet.

I am using PRR so reputation related to social interaction, renown etc... is persistent and affects prices.

However my concern is about the personal reputation system built into the game and what happens to it when the NPC is committed to the DB. I've still not tested this, and don't know what is in store for me. It could be that this snag prevents me from committing NPCs to the DB. In any case, I hope to have this figured out this week.

Modifié par henesua, 07 novembre 2012 - 02:32 .

[SHOVA]

Henesua, you have had almost a week now! What have you found out about reputation? Please don't give up on this system, It sound too useful.