AI Cooperation During Searches

[Springheel]

The AI that's already searching barks "snd_warn*" as part of his request for help.

 

The AI that's joining the search barks "snd_warn_response" or "snd_assistFriend".

 

Are you saying that this is wrong?

 

Those barks certainly weren't designed for that purpose. Is that's what's been causing all the "I'm coming" vocals that have been playing lately?

 

"snd_assistFriend" is not really appropriate for joining a search--the lines are designed for AI who are running to help a friend in trouble a distance away. Most of them are a variation of, "Hold on, I'm coming!" They're delivered with a lot of urgency, and are great for AI responding to a friend in combat, or a friend being hit by arrows, but not so much for searches. The new helpSearch vocals are designed for that purpose.

 

I'm not sure "snd_warn*" is well suited to asking for help _during_ a search. Some of them would sound right, but the lines were written with the idea that the AI was finished searching and had returned to his patrol, so many of them refer to seeing something "a while ago". The giveOrder vocals are probably better suited to AI asking for help searching.

[Springheel]

Btw, I just remembered that I did not set any values for either sound_prop (whether they are yells or tells) or priority for these new barks.

[grayman]

@Spring,

 

I'm looking through the messages that are sent out when AI bark. The messages contain information the listener uses to determine what to do and how to respond. I have 3 questions ...

 

1.

 

The snd_state4* barks are repeated barks when the AI is in Agitated Searching and they continue when he falls back into Searching State. When they are heard by others, the others come to join the search, if they're able.

 

The snd_state3 barks are repeated barks when the AI has risen into Searching State. When they are heard by others, the others don't respond.

 

Is this correct?

 

2.

 

When an AI cries out in pain, no one responds.

 

Is this correct?

 

3.

 

Also, when a lanternBot sends his repeated barks out in Agitated Searching state, no one responds.

 

Is this correct?

[Springheel]

If by "respond" you mean "react to" (as opposed to having a vocal response), then I would say 2 is definitely not correct. AI who hear a friend cry out in pain should definitely react to it by running to the source. In fact, that would be the ideal case to use the snd_assistfriend bark.

 

As for 3, it depends what the lanternBot search bark sounds like. Is it that alarm whistle? AI should certainly react to that. But if he just has some minor mechanical search sound, it might be appropriate that other AI don't pay attention to it.

 

Most snd_state3 barks are low-volume "Hmmm"s, so I could imagine other AI would ignore them...unless that is the only mechanism for nearby AI to join a state3 search in progress?

[grayman]

If by "respond" you mean "react to" (as opposed to having a vocal response), then I would say 2 is definitely not correct. AI who hear a friend cry out in pain should definitely react to it by running to the source. In fact, that would be the ideal case to use the snd_assistfriend bark.

 

Okay, I'll make that change. The code on the sender's side seems like it wants listeners to come running, but it fails to include a piece of information that the listeners need to actually react. I can work around that.

 

As for 3, it depends what the lanternBot search bark sounds like. Is it that alarm whistle? AI should certainly react to that. But if he just has some minor mechanical search sound, it might be appropriate that other AI don't pay attention to it.

 

The bot sends out a silent propagated sound to alert neighbors. At the same time, it starts its loud alarm whistle. The information carried by the propagated sound makes the same mistake as #2: it fails to include a certain piece of information, thus guaranteeing that no one will respond. I'll fix that.

 

Most snd_state3 barks are low-volume "Hmmm"s, so I could imagine other AI would ignore them...unless that is the only mechanism for nearby AI to join a state3 search in progress?

 

These barks behave like those in #2 and #3, and also leave out the info needed to guarantee a response. Low-level noises shouldn't bring anyone running, so this should stay as is.

 

The state3 searches can be joined when an AI arrives and sees that someone is searching.

[grayman]

When an AI is searching, and another AI comes upon the search, the first AI will request that the second help him search. The code has always transferred 70% of the first AI's alert level to the second AI, probably to simulate that the first AI has more interest in the search than the second. (??)

 

With coordinated searching, this still happens.

 

However, especially when a lot of AI show up to help, this can lead to the last to arrive having much smaller alert levels when they start searching.

 

Let N = alert level of initial AI

 

Then:

 

0.7N = alert level of second AI

(0.7)(0.7)N = alert level of third AI if he's spotted by the second AI

(0.7)(0.7)(0.7)N = alert level of fourth AI if he's spotted by the third AI.

 

This has the effect of the later AI abandoning the search sometimes well before the initial AI does. He's often left searching by himself.

 

Maybe this is clearer to see nowadays because of the work I put in to keep them from continuously re-grabbing each other to join in the search.

 

Options:

 

1. Leave it the way it is.

 

2. Always dole out 0.7N to each arriving AI. (Everyone except the first AI will leave roughly at the same time.)

 

3. Always dole out some random % of N, varying it from 0.6 to 0.8, so AI won't all leave at the same time.

 

Your thoughts?

 

Thanks.

[Tels]

When an AI is searching, and another AI comes upon the search, the first AI will request that the second help him search. The code has always transferred 70% of the first AI's alert level to the second AI, probably to simulate that the first AI has more interest in the search than the second. (??)

 

With coordinated searching, this still happens.

 

However, especially when a lot of AI show up to help, this can lead to the last to arrive having much smaller alert levels when they start searching.

 

Let N = alert level of initial AI

 

Then:

 

0.7N = alert level of second AI

(0.7)(0.7)N = alert level of third AI if he's spotted by the second AI

(0.7)(0.7)(0.7)N = alert level of fourth AI if he's spotted by the third AI.

 

This has the effect of the later AI abandoning the search sometimes well before the initial AI does. He's often left searching by himself.

 

Maybe this is clearer to see nowadays because of the work I put in to keep them from continuously re-grabbing each other to join in the search.

 

Options:

 

1. Leave it the way it is.

 

2. Always dole out 0.7N to each arriving AI. (Everyone except the first AI will leave roughly at the same time.)

 

3. Always dole out some random % of N, varying it from 0.6 to 0.8, so AI won't all leave at the same time.

 

Your thoughts?

 

Thanks.

 

I'd use 3) - that sounds better than a sudden "heh, lets leave, the captain can search alone, someone down for the pub?" scenarios.

 

However, I'm not sure if N should be really N from the start of the search, or from the "time the newcomer" arrives.

 

* first AI arrives, gets alerted N = 100

* second AI arrives 2 seconds later, gets alerted 0.7 * N = 70

* AI ramp down to 50

* third AI arrives 2 minutes later, gets alerted 0.7 * N (70) or 0.7 * M (where M < N, so 35)?

 

If we'd use N for the third AI, he might have 0.7 * N > M = 70, which is > 35, so the first and second AI would finish search and the third one would continue searching on it's own.

 

So I'd say it should be 0.6 ..0.8 of the current alert level of the first (or any of the joined) AI.

 

Newcomers would then lose interest always a bit faster than the first arrivals.

[SteveL]

All the options are plausible. I won't pretend to have thought out gameplay implications, I just want to say I like gradual dispersal. It's the gameplay equivalent of a progress bar while you're waiting to come out of hiding

[Springheel]

It's a little more complicated now because alert level is not the only factor determining how they behave during the search. Some AI will still be regulated to observer status (which is basically like a level 2 stand-there-and-look-around search isn't it?) even if they are given a high alert level. So for everyone after the second helper, alert level is now only determining whether they draw their weapon and how long they stay to observe?

 

I think that the active searchers should probably search for the same amount of time as the friend they're helping, or nearly so. The first arriving guard to become an active searcher should get 100% of N (whatever value the original AI has when the second AI arrives, not the original N value). Perhaps with a small 5% variation one way or the other so they don't appear choreographed. AI arriving after that should get anywhere from 70-100% of the current N (some AI might block an exit for a few minutes and then leave early when nothing is found, while others will stay and guard choke points until they see that the search is done).

 

This might get too muddled, but we might get pleasing results if Rank factored into it...if the observer's rank is less than the active searchers' ranks, they'll stay longer to help, for example. So the priest might leave while his acolytes stay to search the area, but you wouldn't have all the acolytes leave the priest by himself if the roles were reversed.

[demagogue]

The reason for the attenuated alert was to avoid alert cascades where an alert would travel across half the map. IIRC the idea of the attenuation was to keep it relatively localized to the nearest guards, and attenuate out as the signal propagated out to more distant guards, or the more wandering ones. So if you did tweak that, just be cautious it doesn't recreate the problem it was meant to solve (if I understood it correctly).

[Springheel]

I think you're talking about warnings. Searches can't really propogate across significant distance, since the search area remains the same.

[grayman]

I'm at the point where the coordinated searches are holding up to some rigorous testing, including numerous game saves and restores. I think I've tested all the different alert situations.

 

This coming week, I'll add the guard/observer anims and the other small touches like barking out orders like "stand over there".

 

I haven't implemented anything like a "search captain", and I don't know if I will at this point. Perhaps later.

 

Maybe another week or so and I'll be ready to ask for beta testers.

 

After running around a large open area with 5 AI after me, and getting boxed in and whacked at by various weapons, I imagine 2.04 might be the time to think about "coordinated combat".

[Springheel]

I imagine 2.04 might be the time to think about "coordinated combat".

 

Someone is a glutton for punishment.

[grayman]

Someone is a glutton for punishment.

 

Yeah, "Bruises R Us".

[RPGista]

Great, now all you guys need to do is to start a campaign for people to stop reloading everytime some guard overhears a footstep, so they can actually see all the nice, complex behaviour patterns the AI can display when they are searching for us. Fleeing AI, trying to elude alerted ones, and fighting them off are some of the most fun moments to be had in TDM.

Edited October 25, 2014 by RPGista

[grayman]

@Spring:

 

What are the three idle searching animations you made for guards and observers?

 

I think I'm seeing a "scratch leg" but I'm not seeing the other two.

[Springheel]

Scratch leg isn't one of them.

 

I think I called them search_minor or something like that, but I'll have to check when I get home.

[grayman]

search_suspicious

search_suspicious01

search_suspicious02

 

I just need to know what the AI is going to do when these run.

[Springheel]

You mean a description of what they are? You can look at them in DR if you like, but basically two of them are subtle animations where the AI just peers around, and one involves putting their hands on their hips like they're perplexed. My thinking was that they would play randomly while AI are just standing there during Alert 2 or 3 searches. They need control of the leg channel, as one includes a small step forward. I have one more too that I didn't upload yet.

[grayman]

So these aren't appropriate if a weapon is drawn?

 

I wasn't aware of the DR anim viewer.

 

search_suspicious can't be used with a weapon, so it would need to have a replacement anim when a weapon is drawn.

 

The other two are okay with a weapon, and it was one of those that I was seeing.

 

Wouldn't 'looking around' be satisfied by allowing random head turning?

 

Guards and observers aren't going to spend a lot of time guarding or observing in state 3, so I don't know how often we'd see these if they're limited to state 3.

[Arcturus]

Wouldn't 'looking around' be satisfied by allowing random head turning?

On a side note. Random head turning always looks fake. Can we tweak the animation curve's easing out?

[Springheel]

search_suspicious can't be used with a weapon, so it would need to have a replacement anim when a weapon is drawn.

 

I haven't made weapon versions yet, but that wouldn't be hard.

 

Wouldn't 'looking around' be satisfied by allowing random head turning?

 

Sometimes, but it's not very convincing...when people look around they normally turn their shoulders or shift their weight.

 

Guards and observers aren't going to spend a lot of time guarding or observing in state 3

 

This would also be applicable to state 2, where the AI still stands around. And I wasn't thinking of it only for guards/observers, but also for active searchers who are in state 2 or 3.

[Springheel]

search_suspicious

search_suspicious01

search_suspicious02

 

Just a reminder, you don't need to specify each animation in the code...if you refer to "search_suspicious", it will automatically pick randomly from anything called "search_suspicious#". That way more can be added in the future.

[grayman]

Just a reminder, you don't need to specify each animation in the code...if you refer to "search_suspicious", it will automatically pick randomly from anything called "search_suspicious#". That way more can be added in the future.

 

Since I'm trying to use the idle animation system, it makes it even simpler. I just need to specify which list of anims the system should be choosing from, and it does all the grunt work, including what you pointed out here.

 

I did verify that--with the replace anims defined--all three are getting chosen randomly. Atm I'm limiting them to the guard/observer AIs when they're searching, but tomorrow I'll expand that to state2. I just have to figure out when to start/stop the anims. I.e. state2 = yes, state 3 & 4 active searching = no, state 3 & 4 guard/observer searching = yes. A bit complicated, but what isn't in this code?

[grayman]

I should note that the Forger has a thicker waist, so he can't use search_suspicious because his hands disappear into his waistline. He'll need a replacement anim or a chunky version. Atm I'm using a replacement anim of "idle_shifting2".