I felt like sharing this. No other reason :

Most cities in RPGs seem to be sparsely populated by NPCs. To create the illusion of a population, we create a few select Major NPCs (which have individual AI) and a specified number (determinant on city size) of Minor NPCs, which are controlled by a ''Group Mind'' and moved about with flocking technology. If we try to disturb these NPCs, they will either ignore and walk around us (flocking in action), or give us a short, sharp message like ''Sorry, I''m in a hurry. Please excuse me.'' Identification of Major NPCs can be an issue, however, they will often remain in certain locations for extended periods of time, be dressed in a unique fashion, or be in areas where the number of Minor NPCs is low, or nil. Using this method has one especially interesting side-effect : you have to actively work to FOLLOW a Major NPC if it enters a group of Minor NPCs. Also, Minor NPCs make excellent soldiers, especially if you want to send an army of soldiers, whether it be 100 or 1000, against your Player.

Yes, it works, and works very well. It also works very fast. At its simplest level, the Flocking System I refer to is a Particle System with Object Avoidance in the movement code. I hope this benefits someone ... Merrick

Nice, Merrick.

I have an intresting idea for an extention to this: the ability to turn one of these minor into a major NPC, if the current state of the game requires it. (note: this is dynamic rpgs only)

ANDREW RUSSELL STUDIOS
Visit Tiberia: it''s bigger, it''s badder, it''s pouyer...

''NPC (La la la)'' could be a hit song..

but anyway...
Im interested to see how your AI is... you seem to be getting awfully advanced at this stuff...



:: Jamie Interactive ::

morfe,
Yes that is the way it usually is. I suppose it works, but it can make things feel quite generic. It brings up questions to the player such as why is this NPC highly detailed, and this one is just a generic cookie-cutter type of NPC . I suppose due to speed and memory constraints it may be the only way to do it. I guess it's a necessary evil unless/until we find a better way. Although, Andrew's idea sounds interesting too.


I have heard ES3: Morrowind is going to have every NPC as detailed as the player. I wonder how they're doing it.



Need help? Well, go FAQ yourself.
What a plight we who try to make a story-based game have...writers of conventional media have words, we have but binary numbers



Edited by - Nazrix on March 21, 2001 9:35:30 AM

quote:Original post by Eight

I imagine it would still work quite well in RPGs.

For instance, trolls aren''t exactly famed for their intelligence, so it''d be perfectly natural for them to have minor AI. Then, if your setting calls for lots of trolls around the place - you''d have it sorted.

E

Yes, I''m fine with that approach for NPCs that are known to have a lesser intelligence like animals or unintelligent beasts, but many RPGs do this for what are supposed to be as intelligent as others like them. It is obvious to the player in many RPGs that one NPC is only more detailed because the developers just had to make some detailed and some not. When seeing through the developers'' plans, it looses some suspension of belief.



Need help? Well, go FAQ yourself.
What a plight we who try to make a story-based game have...writers of conventional media have words, we have but binary numbers

I really think the way to go is to look how a storyteller would improvise on the fly. A mob of people is just genericly controlled until the player begins to focus on a particular character. At this point, the NPC is dynamically built, fleshing out characteristics and a history for the NPC which is consistent with the NPC''s location, heading, etc.

By the time the player confronts the NPC, the NPC has been fleshed out. If the confrontation only lasts a short time and then the NPC goes on his way, the NPC''s dataset can be discarded UNLESS: The player learned of some key facts which will enable the player to meet up with this NPC again, such as his residence address, his place of work, etc. In this case, the NPC''s dataset is kept around until resources dry up. The case of resources drying up may never happen given the size of future hard drives and the finite time a player has to explore the world. For example, let''s say a very rich and highly linked database is used which requires 20k of storage for the fully fleshed out NPC. Now, let''s say our player causes NPCs to be procedurally generated at the rate of one every five minutes. This means 4166 hours of gameplay will produce 50,000 NPCs, which results in one GB of storage.

bishop,
that sounds interesting, but are you suggesting that when the player finds enough info. about an NPC to make him/her worth keeping track of the game will dynamically store this info on the HDD for future reference. Then it would load it into RAM when the info is needed.

I just wanted to make sure I understand what you're saying.



Need help? Well, go FAQ yourself.
What a plight we who try to make a story-based game have...writers of conventional media have words, we have but binary numbers


Edited by - Nazrix on March 21, 2001 2:11:00 PM

quote:Original post by Nazrix

bishop,
that sounds interesting, but are you suggesting that when the player finds enough info. about an NPC to make him/her worth keeping track of the game will dynamically store this info on the HDD for future reference. Then it would load it into RAM when the info is needed.

I just wanted to make sure I understand what you''re saying.

Yes.

But I would go a step furhter, and say an NPC could be dynamically generated as a Soar program (there''s that word again) and called into the Soar system when the NPC needs to be reloaded. This way, not only could one build the traits of the character, but the beliefs and knowledge of the character as well, including the newly learned knowledge about the player and the prior interactions with the player. Additionally. a set of default knowledge (a separate Soar module) could be merged into the NPC program each time the NPC is reloaded.

We would probably be talking about more than 20k of uniqued data per NPC as a Soar program, but still, we''re talking about advanced next generation technology here, and I think it would still be in the realm of taday''s storage capacities, especially since I don''t think a player is going to encounter 50,000 NPC''s by playing for 4000 hours, as I mentioned in my above post.

The default knowledgebase which could be merged with the explicit knowledge of the NPC (Soar is designed to handle the seamless merging of knowledgebases) would include various knowledge sets about topics such as ownership, survival, need for shelter, empathy, combat, financial goals, etc.