This might help...

In terms of handling the locations of NPCs at any given time, just apply schedules.

An NPC can have a series of locations they can be found at any given time. If your game has a built in timing mechanism just make sure that the player can ask locals about where the npc can be found. Once you have these locations configured, just have your npc use regular pathfinding techniques to move between them, and give each location in the schedule a tolerance level for general wandering in that local.

This even allows for NPCs moving between towns; assign a "week" system to your clock and allow for more complex schedules. Might be a fair bit of work, but unless an NPC is also a wandering adventurer then the would usually follow *some* kind of pattern like this.

Actually, when I made that statement, I just thought of a way you could use this to implement some really nifty quests; this combined with your knowledge sharing information, you could have time-limited quests to stop "spies" and such.

interesting...

quote:Original post by Naaga
That thread keeps talking about ''nodes'' for developing the story. I can''t help but wonder if these nodes are really necessary, though. What is the overall purpose behind them? I mean, the nodes are supposed to be generated from the data in the system, right?

Not entirely. The nodes encapsulate event data, so by encountering certain conditions in the game they cause the node to be activated/included in the overall story graph/network.

quote:Instead of taking the time to translate that data into nodes in order to generate new nodes, why not just take the sraight data and generate new data with it? Then it could be fed right back into the system to perpetuate the dynamic changes in the world.

There''s no proven approach that is the "right" way to do it, so give any number of modifications a try.

quote:Does anyone have some good links on natural language processing?

Natural Language Processing is a rather immature discipline. Despite vast collections of data on linguistics and psychology, getting a computer to create natural-reading text from a collection of disjoint concepts and a context (time, location, witnesses, etc) is still beyond a science. I can''t remember the name of the college text we used, but it''s the "definitive" one. Try a search on Amazon or something.

I''d suggest looking at alternative output mechanisms, though. Using an iconic system that simply spits out the concept characters, leaving translation to language - with appropriate tense correction, conjugation and so forth - to the audience is simpler and is culturally portable.

I agree with those that said that wandering NPCs make sense, but could be intensely irritating to track down. It was one (just one) of the really big flaws in the final Might''n''Magic game (9). You''d get a quest, go do it, then spend half an hour clicking on all 100 NPCs wandering around the city. And since they''re wandering, sometimes you''d get the same wrong person several times.

The idea that the NPCs can give info about where others are is good -- the "yeah, I saw X down at the pub". In fact, if you''re using information databases, it would be simple to have a "last seen" grid for all NPCs, indicating time and map location for every pair.

Even better, maybe when you start asking about person X, word gets around. Eventually one of the wandering NPCs will bump into X (or someone they talk to will see X), let X know, and X (of course wanting to know about your quest!) will come running up. You may still have to hunt around, but it would be really cool if the NPCs actually acted on their own.


In regards to NLP: were you asking about the parsing of input from the user, or the construction of sentences from raw data?

If the former, there''s a lot of stuff out there, albeit mostly on the linguistics side rather than computer side. Even the cheapo "eliza" parsers do a tolerable job in simple situations.

If the latter, I haven''t seen much. Most systems tend to use plan-based reasoning and run off of scripts. The research is mostly focused on things like automated phone systems or ticket sales, where there''s a really limited set of questions/responses that everything can be showhorned into.

But you can take some of the ideas from the newer Chomsky-derived parsing systems (government binding, etc) and apply them to the creation of simple sentences. I played with that some -- purely random sentences, but some very complex ones, with interjections, subphrases, and compound phrases.

Your bits of information probably need some context: some are items/people, some are events. You wouldn''t just have { king, coming, Friday } as an unordered set: you''d know subject, verb, object. Then pick one of a few sentence templates and plug it in.

quote:Original post by Naaga

quote:In regards to NLP: were you asking about the parsing of input from the user, or the construction of sentences from raw data?

The latter. It seems my template idea will need a very well thought-out design. I think it''ll use a struct for the info, with one part being the type of template it needs. Then I''ll need a whole bunch of templates for each type. Then I need to make some lists for each type of word. Somewhere I need to do checks for tense/plurals/etc. Another option is to allow the system to construct the whole sentence itself, but I see that as turning into a list of more complicated templates.

Working with the words as kind of pre-lexical objects, then applying the syntax specifics (plurals, tense, punctuation) at the end, is definitely the way to go. Pass around "ogre", along with a plural flag. Once it''s time to render text do the plural/tense stuff.

Same with articles (a/the/some). Uniqueness and plurality tell you what type of article you need, and if you pre-render it into (say) "an" you''ll just have to check for that countless times.

quote:As for the other part of the system, I''ll try using a single database system for information and see how it works. The main problem I see with doing it that way is that it doesn''t simulate slow-moving data. If the DB is constantly updated, everyone in the world will have access to constantly-accurate information. Maybe I could use a second DB to hold less-current stuff, but I probably don''t need to go to that much depth. Anyone have more thoughts on this?

I''m not sure I see why one database is a problem.

Not only do you have "data" (world events) in the database, you''re representing which characters know which data. Propagation is kind of like path finding (via matrix multiplication).

Err, okay, an example. For fact A, assume person 1 knows it, 2 and 3 don''t. A[1]=1, A[2]=0, A[3]=0. Next interval, look at a proximity matrix to determine if 1 and 2 can communicate. If so, after some appropriate amount of time (adjusted for distance and importance of information), set A[2]=1. (this could even be "adjusted" for some entropy if you''re being way too tricky, so facts might drift)

So your simplest database entities might be:

data: ever growing list of event-facts
actors: the NPCs and any other message propagation system
knowledge: array[data][actors] representing "actor knows data"
propagation: array[actors][actors] representing flow of knowledge.

(propagation is undoubtedly dynamic and proximity based, but (again being way too tricky) could incorporate extra factors like "elves never speak to orcs" or "dwarves always watch the 6pm news" to modify information flows)

Just keep everything in the database until no one knows about it. For the fact where you list who knows it, just decrement it when people forget. If they get to 0, you can prune the fact from teh database.

Alsom you want to make sure that certain events if they are important enough should be known by someone. An example a few years ago when this issue came up then was that if there is a big important fight, and everyone in the battle dies, you probably want to just assume that someone was walking by, saw the battle, and ran off to tell someone. You could maybe generate a dummy npc for events such as this just to make sure the news gets spread somewhere. The npcs can say that a "messenger" told them about the battle, or simple say they "heard rumors" of it.

Another idea for old news is to just keep the news around forever. Surely most news will get written down either in a newspaper, or some sort of log, or people write books about big events. You would only rarely have the npcs "read" the books but it would be kind of neat to hear them reminisce every once in a while, or at least know their history

Heck might be even better to allow the player to read the information, although that might be taking things a bit too far. It''s almost taking things too far already hehe.

Good luck

About when events should expire...

Even though an event like "Bob saved the little girl from the evil cave near the village" is transitory, something about it will probably be preserved in the village stories. People will stop actively talking about it, bards may not sing of the tale, but for a long time afterwards, people would remember (if prompted). As such, I would argue that events simply become "non-urgent". The information is still there, just not relevant.

Of course, if it''s a long-term MMORPG or similar, your database will be huge. In this case, you''d purge things more quickly. Say: small event, 1 month active, 1 year passive. Medium, 4mo/2yr. Large, 8mo/12yr. Huge (kingdom fallen, world saved, etc) I would say 1yr active, 40yr passive, but for these I would gradually phase the information out to just the elders and tomes, eventually becoming legend in a century.

quote:Saluk: "Also you want to make sure that certain events if they are important enough should be known by someone. An example a few years ago when this issue came up then was that if there is a big important fight, and everyone in the battle dies, you probably want to just assume that someone was walking by, saw the battle, and ran off to tell someone. You could maybe generate a dummy npc for events such as this just to make sure the news gets spread somewhere. The npcs can say that a "messenger" told them about the battle, or simple say they "heard rumors" of it.

You wouldn''t even need a dummy. If it''s a large fight, surely folks on the outskirts, areas marched through, etc, would have gotten a glean of "big battle coming". Those who sent family will know "Bob has been gone for ages, never came back from some big battle". Wanderers will see the destruction and return with tales of "some big battle".

Basically, it''s the same event (per se)... just a different perception of it. The winning side knows of it, travellers have seen the effects, townsfolk have heard of it. The event might be more vague ("some huge battle took place over by Glensford, thousands dead"). But you could do this without a dummy NPC.

(sorry, "dummy" events and people have always disturbed me, as they''re usually used to "work around" design flaws)