XD cook fish for a living...

Conversations include giving goals and such. i should have said interaction. But the way they express interaction the most would be by conversation.

EDIT:

Im also not liking the idea of having to use different threads for each AI... I should try as hard as possible to use triggers than checking everything.

Sims 3 originally tried to use a planner for the Sims dealing with their career paths, jobs, etc. Until one time they couldn't figure out why a Sim was cooking fish all day. They finally figured out that it was because he had determined that it was the best way at the time to work towards his "life goal". Now they certainly could have balanced it out a lot better than that example, but they decided to go simply with a more utility-based method of forward chaining rather than the inherent back-chaining of a planner.

Obviously such a situation (cooking fish all day towards a 'life goal') indicates a Goal balancing issue where Life Goals have less of an immediate need. It seems to me (and I would in NO way compare my inept skills to any in the professional realm) that back-chaining is superior to forward chaining in 'realism' and also in accomplishing multiple goals simultaneously.... by using a utility/desire weighting system that would encourage the following example:
An NPC has a strong need/desire to satisfy hunger. In addition, it has a less strong desire to make a shelter. Since the food goal is higher than the shelter, the NPC plans accordingly and sets off on a path to the nearest berry bush. Near to the path lies some tree branches which would satisfy a portion of the 'build shelter' goal so the AI incorporates a short detour on his way to the berries and picks up the tree branches.

Being able to do such multi-tasking is important in my own AI design goals, but probably not so much to the AI developers of the Sims - their agents seem to do a single goal at a time which can be interrupted by higher priority events, etc.

Well, this is how i think of it:

There is alot in the environment. Only a fraction is what the AI uses. If you can flag certain things in the environment as needs to be checked, you might be able to have both in one.

Regarding triggers vs. threads... the two are not mutually exclusive. That said, constant polling of the environment is computationally expensive if done incorrectly but also yields some more subtle behavior than having things entirely trigger-based. There are pros and cons. You can also have "immediate action" triggers show up as high-priority decisions in the landscape (so to speak) so that they can't be ignored.

Actually, this is akin to my current thought, and kind of coincides with my lame attempts at 'memory' or 'historical environment knowledge'. As an agent blunders through the environment, all manipulatable objects and their locations are stored along with a timestamp. The timestamp is used to degrade the knowledge 'value' over time so that a berry bush at X one hour ago has more 'value' then an equal (size, type, distance, etc) berry bush recorded at an earlier time. When accessing this array, I divide the values into 2 groups: Immediate Vicinity (Line of Sight) and Long Distance. Now, as Goals are formulated, any objects required to achieve a particular Goal are stored AND then the 'memory' is evaluated and the objects in memory have their values additionally adjusted upwards in importance, becoming 'triggers'. Then, as movement occurs, any trigger that comes into view causes the AI to re-evaluate the goal in which that object is a part of and possibly altering the current goal to incorporate manipulation of this trigger object into the plan. I refer to these 'triggers' as Dynamic Triggers. I like the idea of Dynamic Triggers and the Timestamps allow me to put an upper limit on the amount of memory required, flushing out 'old' info.

BUT, implementation of this has been more memory/computationally intensive then I would like, and seems to me kind of 'clunky' - still debugging and re-balancing values which I fear has been the majority of time involved coding.

Nice... How are you storing the memories of things? You probably already know what you are doing, but may i suggest something?

I know ive said this before, but i find it easy to use and debug. You construct the memories out of a base class- one with a single ID to describe what kind it is. Then you can use small values to store the rest of the info. At most, saving the location of an object is 5 ints: the ID that it was a memory of an object, the position, and the last time it saw it. I would think for the position that you would need exact numbers, so rounding and possible some noise could save memory.

DaveMark,
Something was bothering me about your example of the Sims and the repetitive cooking in order to increase cooking skill. Though this action seems unrealistic, in the context of the virtual environment and game design parameters, it was perfectly realistic. This same exact behavior is exhibited by human players in the same situation: both Ultima Online and RuneQuest have skill based character development systems and it is 'part of the game' to see a player repeating the same action hundreds or thousands of times to increase skills. So, I would classify that 'problem' as a game design flaw that results in unrealistic AI behavior, not an AI issue per se.

just my thoughts...