Fascinating discussion - some very interesting ideas.

Here's another feature/complexity you could add (apologies if someone's already suggested it) - have a main event, and then a subset of "details" associated with it. NPCs might know of the event, but particular details might only be known to certain indivduals. This could be worked into the decay systems you've been suggesting - an NPC might remember an event, but forget specific details over time.
Eg, the NPC will always remember a battle took place in a nieghbouring village, but he might forget exactly when it took place, if a particular character was killed, or which direction the raiders fled.
This could be built into a hierarchy or tree structure - eg,
Battle took place
-A local was killed
----He was a farmer
-------It was Farmer Jim

Obviusly various weights could be applied to different details, etc.
Just my two cents


Edited by - NeverSayDie on February 18, 2002 11:28:13 AM

Nice idea NeverSayDie!

You could expand this further to include the ''Chinese Whispers'' effect when people communicate. Perhaps NPC1, while telling NPC2 of the story of the battle, mixes up some of the details. Perhaps instead of a farmer, she says that the baker was killed!? This might make it harder and more interesting for the PC to decipher what actually happened and whether it has relevance to his or her situation!

Timkin

Wow! That is all I can say about this thread.

Some of these ideas are very interesting. But nobody (but me) has said anyhting about the use of a semantic network. I was really serious in my little onesentence post.

Take a bunch of nodes with phrases and words in them and link them by their relationships. for example: the node containing "red" would hopefully have an is-a link to the node containing "color". And "color" would have a one-is link to "red".

Edited by - Puzzler183 on February 18, 2002 5:42:11 PM

quote: Original post by Puzzler183
Wow! That is all I can say about this thread.

Some of these ideas are very interesting. But nobody (but me) has said anyhting about the use of a semantic network. I was really serious in my little onesentence post.

The problem you will find Puzzler183 is that while your idea has merit, most of our readers will never have encountered a semantic network and would therefore have no idea of the benefits of such, let alone how to apply it to the task.

Perhaps you could offer a concise overview of applying a semantic network to the problem of NPC communication? I''m sure everyone reading this thread would appreciate it and it would certainly contribute a lot to the discussion!

Thanks,

Timkin

You know, this sound A LOT like replication between servers in most enterprise software. Most of the issues brought up by other people have already been answered. It would probably do you good to take a look at some of that stuff. I don''t know much about it at all, but I know there are already proven algorithms to enchance performance. And since these server are already doing it in real-time with little work from the processor, it should be almost "free" to implement. Hope that help the thought process.

One day I''''ll stop pretending to know how to program

A semantic network is an advanced form of knowledge representation that, like many things, has been around for quite awhile but has not been implemented in virtually any applications. It is basically a set of nodes linked together to form a network. I have implemented them in two ways using two different style, all of which will be discussed below. I will give you two basic structs in C++: the link and the node.

struct link {	bool active;		//is the link on?	char truth;		//the higher, the more true	char desc;		//descriptor byte	short nptr;		//offset of the node in the array};struct node {	char desc;		//describes contents of the node	bool active;		//is the node on?	char idea[30];		//knowledge string	char ltot;		//number of links	link links[45];		//links}; 

The two ways to implement them:
1. As an array of nodes
2. As cluster of nodes, created dynamically in memory

For an array of nodes, you may use the structs I gave you and just have to write functions to add nodes, remove them, and clean house (which will be discussed later). For a cluster of nodes, change the

short nptr; 

is the link struct to:

struct node *nptr; 

Then use new and delete to create the cluster. Now onto the two styles of networks:

1. General links
2. Specific links

the descriptor byte in the link struct tells the relationship between the two nodes being linked. This can be specific (lives in, eats) or general (is a, characteristic. While the latter is more suited to predicate calculus than the former, the former is (probably) better suited for this game.

Now as for how this applies to NPC communication:

When NPC 1 says to NPC 2, "red is a color", NPC 2 would look for red and color in their knowledge base. If he found both, he would create an "is a" link between them. If oe (or both) was missing, he would create the missing one(s) and then create an "is a" link between them.

I admit, this approach requires more parsing than normal but I find it very useful.

I love the idea of a semantic network, as it gives NPC''s (or agents, or whatever) actual understanding of the world around them, as opposed to faking it.

I guess the reason I haven''t responded is that, for my project, it would be overkill. I love talking theory, but a common malady of these forums is people talking about grand ideas, but never implementing beyond the basics. Sourceforge and the web in general are littered with projects that have incredible design docs, but never make it past version 0.0013. I know that I myself have started many such projects and never gotten even close to finishing them.

So, my approach is incremental. It''s probably less organized, and leads to constant rewrites, but it does give me the knowledge that I''m progressing. At the moment, I have a small map, which I can create with a basic map editor. I have some NPC''s, created randomly, which move to random points using vectors. I''m seriously embroiled in trying to figure out A* pathfinding. Once that''s done, I''ll move on to having multiple level maps (countryside map leads to city map, city map leads to house map, and so on). Each feature gets added as I need it or can figure it out.

I have my gossip system working on a basic level. NPC''s can gain and trade information. I know that I can add more complexity later. But at this point in the game (pardon the pun), having a semantic network in my game would be, unfortunately, absurd.

Having said that, I am learning a lot from you guys, and I may have to create a proof-of-concept program to play with the ideas, just because it sounds like so much fun. I''d also like to figure out what rules would be relevant to an RPG. MY NPC''s would not need to know that apple "is a" fruit, for example, but they would need to know that an orc "is aligned" evil. NPC''s should have a set of rules that helps them make decisions about their daily lives - when to change state, what to buy, where to travel, who is on what side in a battle, and so on. Maybe a good discussion would be what subset of semantic rules is most important in an RPG?

Please keep talking. I''m really enjoying it, and would like to contribute, but for the moment, the best I can do is listen and occasionally ask questions.

- Gollum, who is mired in pathfinding he11.

Well I am working on some semantic net classes so if you want the code, feel free to leave your email, and mention it.

In the gossip context you can get away with using only one semantic net representing the relevant items in the map. Each NPC has a set of links and when they communicate they exchange these links. So if npc1 ask "where is the blue key", npc2 checks the semantic net to see if one of his links is related to the blue key and if so he will tell it npc1, who adds this link to his set. Just an idea....

To me it sounds kind of silly to keep track of all these NPC''s and things they know and remember it would eat up memory like crazy. You could probably do it all semi-random and the users couldn''t tell the difference.