View Issue Details

IDProjectCategoryView StatusLast Update
0003462The Dark ModAIpublic03.07.2013 02:40
ReporterSpringheel Assigned Tograyman  
PrioritynormalSeveritynormalReproducibilityhave not tried
Status resolvedResolutionfixed 
Product VersionTDM 2.00 
Target VersionTDM 2.00Fixed in VersionTDM 2.00 
Summary0003462: AI should turn head to look at doors opening
DescriptionI think it would look good if AI turned their heads when a suspicious door (or any door, for that matter) opened in their field of view. It's a natural thing to do, and seems appropriate for AI who are checking to see if anyone they know has opened the door. If they don't turn their head, it looks like they're ignoring the door entirely, which seems odd, especially if they then comment about it.

TagsNo tags attached.

Relationships

related to 0002859 resolvedSpringheel If an AI opens a door marked ShouldBeClosed, he becomes suspicious 

Activities

grayman

grayman

25.06.2013 17:54

administrator   ~0005591

When you say "in FOV" that means he's responding only to the _sight_ of the door opening. He's not responding to the _sound_ of the door opening. If he were to do that, then FOV wouldn't matter and he'd turn to look at a door opening behind him.

Since many authors probably rely on AI not turning around in response to a door opening behind them, an AI responding to _sound_ would not be a good thing.

(I don't mean that the door opening sound suddenly becomes suspicious. We'd simply simulate his interest by letting him respond to the visual stim of a door opening behind him.)

Since we have a disparity between what the player sees in low-light conditions and what an AI sees, we'd have to have the AI ignore light levels when testing whether he can see the door.
Springheel

Springheel

25.06.2013 21:24

administrator   ~0005592

Yes, at the moment I'm just talking about sight. Since AI are 'reacting' to the door, it would make sense for them to look at it. Personally, I think AI should turn to look at ANY door that opens in their FOV, even if it's not suspicious (even someone not guarding would probably glance at a door to see who is entering). But I don't know if doors have a visual stim on them if they're not labelled suspicious.
grayman

grayman

26.06.2013 00:47

administrator   ~0005594

All doors give off a visual stim when they're open. This is useful for an AI who's hanging around a closed locked door for which he has no key. The door telling him it's now open allows him to go through if he needs to.

So the stim is already in place. I just need to teach the AI to look at an opening door.

Some rules, if you agree:

1 - To continue to allow the player to crack open a door and peek through w/o being spotted, a door has to be > 10% open before an AI looks at it.

2 - If the door is suspicious, the current 'suspicious door handling' code supercedes the 'look at door' code.

3 - Currently, handling a suspicious door isn't allowed if the AI's alert level is Suspicious or higher. The door will continue to stim him and if it's still open when his alert level drops below Suspicious, he'll deal with the door.

4 - There's no interest in a door that's closing, only opening.
Springheel

Springheel

26.06.2013 15:01

administrator   ~0005597

1 & 4 are excellent.

2 & 3 -- not sure what these mean exactly...AI will look at normal doors opening but not suspicious ones opening? Wouldn't it be even more important to look at suspicious doors?
grayman

grayman

26.06.2013 15:49

administrator   ~0005598

2 - Since the AI is going to react to the door anyway, because it's suspicious, there's no need to have the AI look at the door. He'll simply go to the door and start searching.

3 - Just describes when the AI is allowed to handle a suspicious door. I suppose he can be allowed to look at it; he just can't walk over to it. I assume we did this because we didn't want to pull him off of whatever put him into Suspicious mode.
Springheel

Springheel

26.06.2013 18:32

administrator   ~0005599

Last edited: 26.06.2013 18:34

View 3 revisions

2 -- From an aesthetic/immersive behaviour point of view, a guard should turn his head even if he's going to search.

If a suspicious door opens in his FOV, a guard is going to turn and direct his attention to it. If he sees a friend come in, he'll turn back to what he was doing. If he doesn't see one after a few seconds, he'll probably go investigate. That's pretty much what the code does now, minus the head-turning, I believe.

Is there any reason code-wise why turning his head towards the door would cause problems?

From a gameplay point of view it seems like a good thing, as it tells the player where the AI's attention is directed, and clever players could even exploit it, by making a dash while the AI is paying attention to some other door.

grayman

grayman

27.06.2013 01:46

administrator   ~0005600

For the AI to appear like he's responding to the opening door, I need to cut the time between door stims from 2s to 1s.

The issue is that when the door begins to open, it stims the AI, who discovers that the door is < 10% open, so he ignores it. When another 2s goes by, the door is completely open (door opening time defaults to 1.75s), at which point he looks at the door.

So the player won't see the AI look at the door while it's actually moving.

If I drop the between-stim time to 1s, the stim will hit the AI near the half-open point, so the door's still opening when the AI looks at it.

I don't think doubling the number of stims an open door sends out is going to have any noticeable effect on performance. Doors spend most of their time closed, and closed doors don't send stims.

I also have to set the lower limit of noticing the door to 20% open. That's about the amount of opening the player needs to get a good view out the door. 10% is too small.
grayman

grayman

27.06.2013 01:55

administrator   ~0005601

Also, I'm letting the AI look at a recently opened door, in addition to one that's in the act of moving. If the AI is stimmed by a door that was opened less than double the opening time ago, the AI will look at it. So if the opening time is 1.75s, any door that stims an AI w/in 3.5s of the start of its open will draw the AI's attention. This is sort of a "Hey, wasn't that door closed a moment ago?" reaction, rather than a "Hey, why's that door opening?" reaction.

The stim interval cut to 1s will most likely let an AI catch the door while it's moving, making the secondary check unnecessary. But in a belt-and-suspenders way, it might get used once in a while.

The only "huh?" instance might be the case of an AI rounding a corner and spotting the open door after it's open but before the 3.5s timer runs out. You might say there's no reason the AI should be interested in the open door, because he didn't see it closed in the moments before it opened. But I think it's okay.
grayman

grayman

27.06.2013 17:11

administrator   ~0005602

So here's where I am with the rules ...

For an unsuspicious door:

The door starts to open, stims the AI, but the AI ignores it, because the door is < 20% open. One second later, when the next stim hits him, if the door is < 20% open, he'll continue to ignore it. Otherwise, he'll look at the door for 2 seconds.

For a suspicious door:

The door starts to open, stims the AI, and the AI immediately starts to look at it for 2 seconds. 1 to 1.5 seconds after the stim, while looking at the door, if no friendlies are apparent, the AI will bark and walk toward the door and begin his search.

The behavior is different wrt the "less than 20% open" rule. On the one hand, I'd like that to be consistent for both door types, to let the player be able to crack open a door and peek through w/o drawing attention. On the other hand, if the door is supposed to be closed, the AI better spot that it's open, regardless of how open it is.

Thoughts on this?
Springheel

Springheel

28.06.2013 02:09

administrator   ~0005604

Last edited: 28.06.2013 02:12

View 5 revisions

Hmmm. There are arguments for both sides. My instinct is that extending the 20% rule is better for gameplay, but it does seem undesirable that the vault door in the bank could be 20% open and AI ignore that fact.

Just brainstorming, but how does the chance to notice doors factor in here? Do AI continue to check the door later if they fail the first check? If so, maybe we could do something with suspicious doors where if the door is open <20%, the chance to notice is only 1/3 normal, and AI have to wait 5 seconds before they can check again. That way their chance of immediately noticing a player who opens the door a crack is pretty low, but if they leave the door open, the AI will eventually notice.

grayman

grayman

28.06.2013 02:18

administrator   ~0005605

The chance to notice an open door is still in play. If the chance check fails, the stim stays alive and the AI gets another chance one second later, ad nauseum until the stim gets through.

I'll try your suggestion and see what it looks like.
Springheel

Springheel

28.06.2013 15:56

administrator   ~0005606

If they're checking every second, then the "chance to notice" would have to be really low to make any difference, wouldn't it? Even someone with a .1 chance would probably notice the door after ten or twenty seconds.

Maybe on suspicious doors <20% open, the chance to notice needs to be reduced by a factor of 10, so the default 1 becomes .1. That would mean a player who cracks the door open for a few seconds has a good chance of getting away with it, but leaving it open like that is pretty much guarrunteed to alert the AI before long.
grayman

grayman

28.06.2013 18:08

administrator   ~0005608

In order to give the player the ability to peek through a suspicious door w/o getting nailed, I need to base it on time rather than chance.

I reduced the chance of noticing the cracked open door to 1/9 its normal value. I changed the stim rate to once every 1.5s (just needs to be less than 1.75s, which is the default time needed to open a door). I established 1/9 by saying 1/3 (your suggestion) times 1/3 (need 3 stims to get near 5s (your suggestion) of elapsed time).

In three tests, the AI spotted the cracked door on the ...

- 1st stim
- 1st stim
- 7th stim

This doesn't bode well for the player.

I'm going to try a rule that says the AI can't see a cracked door until 5s have passed, and get rid of the chance reduction math. This should provide some consistency to AI behavior. I'll probably end up randomizing the 5s so it's between 5s plus and minus some small amount, so that several AI spotting the same door all don't react in the same frame.
grayman

grayman

28.06.2013 18:30

administrator   ~0005609

Yes, that's much better.
grayman

grayman

28.06.2013 18:57

administrator   ~0005611

Ha! This is funny.

There's an old axiom in business: if two or more people are in charge, then no one's in charge. Each will assume someone else will deal with a problem.

In our case, my single guard handles a suspicious opening door correctly. To make sure two or more didn't try to react at the same time, I gave the guard a buddy.

Neither guard responded to the open door. I scratched my head for a moment, ran it again, still nothing. Then I realized that each of them thinks the other one opened the door, so neither responded.

So even in our fake world, the axiom holds true.

Grumble grumble. Need to change some code, methinks...
grayman

grayman

28.06.2013 23:05

administrator   ~0005612

Last edited: 28.06.2013 23:09

View 2 revisions

AI will look for 2s at a door opening in their FOV, unless they’re in combat mode.

An AI will not look at an open door if they were the last one to handle it.

Tightened recognition of who might have opened a suspicious door.

Changed door stim timing from every 2s to every 1.5s, so that an observing AI has a better chance of looking at the door while it’s moving. The default move time for doors is 1.75s.

Allow player to crack open a suspicious door to peek out w/o grabbing the attention of a nearby AI. After 5s, the AI will notice the cracked open door. Non-suspicious doors can be cracked open indefinitely w/o nearby AI noticing.

Rev. 5815:

State.cpp
StimResponseCollection.cpp
FrobMover.cpp
FrobMover.h

Rev 13517:

tdm_mover_doors.def

Springheel

Springheel

03.07.2013 02:10

administrator   ~0005625

I've been watching this in game for a bit. Most of the time it looks great, but there are a few cases where it seems a bit odd. Is there a distance check involved? I've seen AI turn to look at doors that are a long way away. Also, in Fiasco, I've noticed AI turning up to look at the door on the walkway, even though they're inside the tunnel and couldn't see the door anyway.
grayman

grayman

03.07.2013 02:22

administrator   ~0005626

The max distance is the radius of the visual stim from the door, which is 500. If the stim doesn't reach the AI, the AI won't look at the door.

There is a FOV/LOS check. The AI has to have a clear LOS from his eyes to the middle of the door's closed position.

In reviewing the code, I see a bug that negates the LOS check.

I'll submit a correction for that.

Thanks.
grayman

grayman

03.07.2013 02:40

administrator   ~0005627

Split LOS check into two. If the first check fails w/o considering illumination, the AI can't see the door, and will ignore the door this time.

If the first check passes, we have LOS. Continue with the existing check that considers illumination, for the purposes of seeing suspicious doors the AI is handling.

rev. 5817:

State.cpp

Issue History

Date Modified Username Field Change
25.06.2013 00:10 Springheel New Issue
25.06.2013 00:11 Springheel Relationship added related to 0002859
25.06.2013 17:54 grayman Note Added: 0005591
25.06.2013 17:54 grayman Assigned To => grayman
25.06.2013 17:54 grayman Status new => assigned
25.06.2013 21:24 Springheel Note Added: 0005592
26.06.2013 00:47 grayman Note Added: 0005594
26.06.2013 15:01 Springheel Note Added: 0005597
26.06.2013 15:49 grayman Note Added: 0005598
26.06.2013 18:32 Springheel Note Added: 0005599
26.06.2013 18:33 Springheel Note Edited: 0005599 View Revisions
26.06.2013 18:34 Springheel Note Edited: 0005599 View Revisions
27.06.2013 01:46 grayman Note Added: 0005600
27.06.2013 01:55 grayman Note Added: 0005601
27.06.2013 17:11 grayman Note Added: 0005602
27.06.2013 17:11 grayman Status assigned => feedback
28.06.2013 02:09 Springheel Note Added: 0005604
28.06.2013 02:09 Springheel Status feedback => assigned
28.06.2013 02:09 Springheel Note Edited: 0005604 View Revisions
28.06.2013 02:10 Springheel Note Edited: 0005604 View Revisions
28.06.2013 02:11 Springheel Note Edited: 0005604 View Revisions
28.06.2013 02:12 Springheel Note Edited: 0005604 View Revisions
28.06.2013 02:18 grayman Note Added: 0005605
28.06.2013 15:56 Springheel Note Added: 0005606
28.06.2013 18:08 grayman Note Added: 0005608
28.06.2013 18:30 grayman Note Added: 0005609
28.06.2013 18:57 grayman Note Added: 0005611
28.06.2013 23:05 grayman Note Added: 0005612
28.06.2013 23:05 grayman Status assigned => resolved
28.06.2013 23:05 grayman Resolution open => fixed
28.06.2013 23:05 grayman Fixed in Version => TDM 2.00
28.06.2013 23:05 grayman Target Version => TDM 2.00
28.06.2013 23:09 grayman Note Edited: 0005612 View Revisions
03.07.2013 02:10 Springheel Note Added: 0005625
03.07.2013 02:22 grayman Note Added: 0005626
03.07.2013 02:40 grayman Note Added: 0005627