AI Memories and Containers

Hey Folks! I got the food interactions hooked up today, and that revealed a new obstacle: containers.

My first order of business was to get AI to be able to find food again, now that I have this new "learning" system in place. I had to separate the old "SeekFood" into two distinct interactions: one for seeking a food item directly, and one for checking a container for food. And this revealed a problem with my system and containers.

Basically, AI had no way of associating success/failure of their food-seeking with the container it came from.

To solve this, I decided to add a couple of markers to any item that gets transferred during an interaction. This info includes who the original owner was, and what interaction caused the transfer. Then, when the AI later uses that item and gets a benefit (or drawback), they can associate the effects with that original owner+interaction combo, like they do for other direct interactions.

I think this piece is actually working now, after a few hang-ups and bugs were sorted. However, I think I'm noticing a new problem. Two, in fact.

First, my AI gets pretty pessimistic if it fails the first time it checks a container for food. Since that's the only data point it has, future attempts are avoided because the first attempt actually made them feel worse. Oops. I'll have to figure out a way around this.

The second issue is possibly bigger. My containers no longer think they contain anything when asked by the AI for an item. I used to have a hack to get around this problem, but I eventually removed it because it interfered with the AI learning code. The hack basically gave each AI omniscience about the contents of any container.

Instead, the AI shouldn't know what's in a container until checking, and then the container should either allow or deny the AI based on its contents. But the way I've setup items and conditions, there's no handy way for the container to know what it has..

One solution might be to include a loot check when the game is checking for valid interaction targets. If the interaction requires giving/taking loot, the validator would check that the petitioner or granter have the necessary loot. This solution should work, but is a bit brutish and may use lots of cpu.

Another approach is to do something like what I did in NEO Scavenger. That is, items impart certain conditions upon their owners when added to their inventories, and remove those conditions when the item is lost. This way, I could have something like "HasFood" imparted on a container when a food item is added to it, and the interaction filter is already setup to check for necessary conditions.

The down side to both approaches is that loot can sometimes mean a random amount of items, and there would be no way to know what that random number is in advance without saving that info between the query and the actual interaction. That's more bookkeeping than I want.

I think I'll need to do this NEO Scavenger approach anyway, since I some day want items to impart benefits to the owner. Things like warmth, oxygen supply, or social status. But I'll need to think on it a bit.

That's what weekends are for, right? Have a good one, all!

Comments

Fins's picture
Fins

The solution for the 1st seems to be obvious: change AI's "feelings" to be more human-like.

If i am hungry, i go to a freezer and "check for loot" (among other actions), whenever "freezer" is in reach. Let's say i am visiting a close friend, and i never "checked the freezer" of his before. So i open it, and it's empty. Nada. Will i check that same freezer _again_ if i'll be visiting him again in a few days and once again find myself alone and hungry? I sure will. Why? Because it has that general "freezers are likely to have food" "marker" which my mind puts on it. Heck, i'd check it even after half a dozen "it's empty, every time" attempts.

But what about a cabinet in his bathroom - would i go look for food in it? Even once? Not likely.

I think, two things needs to be done:

- some containers are to be anyhow made known to AIs as "likely to have food" ones, and some other containers - as the opposite. If it'd be me, i'd make it an integer flag, with 255 being "highest probability to have food", and 0 being "lowest probability to have food". That would reflect real-life "knowledge" people have about all sorts of containers in terms of how "foodish" they may be, based on their shape, location, previous experience in checking their contents (if any) and other factors. But at least boolean flag could be used for that purpose;

- there has to be decay of the disappointment AIs have about not finding food. Properly balanced. Very much like in real life: if i check my friend's freezer and find it totally empty, i will NOT go check again in mere 2 minutes, especially when my friend is not there with me at the time, since i _know_ it's empty. But the more time passes, the more probability there is that "may be someone added some food to that damn freezer". Give it enough time, and i'd _forget_ that i once saw my friend's freezer empty, - entirely. This whole process can and should be approximated with "decay of AIs' pessimism with time". Better be non-linear, but %-based till some (minimum) treshold, at which point it'd be removed completely (unless "refreshed" to higher value before nulification has any chance to happen).

I dare think, those mechanisms would be quite useful for many other AIs' experiences, - since you model humans here, the fact that humans tend to forget things after long enough time has to be somehow reflected, i think. As well as at least some basic feats of human intuition and common sense, - and knowing where food may and may not be is one of most basic ones indeed, as humans consume food on a regular basis and thus all adults have vast experience, within their usual environment(s), about where to find some.

As for second problem - i have no idea how to go about it; sure i'd need sufficient data about inner architecture of your whole containers - items - AIs structure. Possibly i'd be unable to propose anything even if having enough data, too. Can only say this one thing: if you indeed are going to implement "the container should either allow or deny the AI based on its contents", then it'd be all hell cut loose, IMHO. Assuming contents of containers change over time, that is.

I'd rather go (IF possible) with the traditional "the continer should either allow or deny the AI based on AI's ability to open the container", which is "true" (boolean) when a) container is not locked, or when b) the AI used the fitting key to open the lock, or when c) the lock was destroyed by the AI; and "false" when container is locked and the AI did not use the fitting key and is unable and/or unwilling to destroy the lock. Applicable to containers proper, doors, passworded electronic devices, eye and fingertips scanners and whatever else "security system" imaginable on a spaceship.

The "locked" status would be dynamic, of course. "Hey, Mary, come on, open the door, i was joking, you know that!" -> "John, you idiot, go throw yourself outta the airlock, i don't want to EVER see you again, cheating bastard!!!" // proper interaction between AIs Mary and John after Mary went into her room and changed status of the door of her room to "locked", the only key in her posession. :D

... our lifestyles, mores, institutions, patterns of interaction, values, and expectations are shaped by a cultural heritage that was formed in a time when carrying capacity exceeded the human load. (c) William R. Catton, Jr

dcfedor's picture
dcfedor

The "marker" you're describing is actually something the AI can do, it just requires that the AI be trained/seasoned. Right now, they're blank slates when they enter the ship. Not only do they have zero experience with what might be in the ship's fridge, they have zero experience with fridges in general. I'm sort of hoping I can throw the AIs into a training area to build up basic experience, and start from that as a template when spawning future AIs.

Your memory point is valid, too. Right now, there's a clunky bit of code to prevent AIs from trying the same thing over and over when in "random experiment" mode. But I may need to add some decay factor, too, so they don't permanently write-off things based on a few experiences in the past.

As for the container issue, I ended up going the hard way, and it turned out not to be that bad. The AI approaches the fridge, rummages for food, and the fridge does some checking behind the scenes to see if it has the necessary food to result in "success" or not.

There are more clever solutions, but this one should at least be reliable, if heavy-handed. I'll come back to this and kick myself in a year when I'm optimizing CPU :)

Dan Fedor - Founder, Blue Bottle Games