Stealth game tropes

[Springheel]

We do a few of these better than AAA games.

 

[V-Man339]

I don't really like countdown videos, and this one is included, but frankly yeah, half the reason I do challenge runs of The Dark Mod is because it's actually fairly believable and, as a result, challenging.

The fact is though this is because most stealth games want to cast as wide as possible of a net with their sells so they make things easy.

 

One of the first things I tell people about the Dark Mod is that the AI doesn't just magically forget you, whereas in Assassin's Creed they practically had to yell out that they were finally doing that in Revelations that this had changed because they realized people were beginning to realize how underwhelming things were.

 

This isn't an AI issue, we nailed this back in Chaos Theory. It is, rather, a demographics issue.

Edited October 27, 2016 by V-Man339

[Sotha]

Yes, Grayman's children are on par with tripleA title AIs, if not exceeding them.

 

I do not claim to know anything about AI programming, but some of the critique presented in the video feels a bit unfair. The list of possible situations a stealth AI might encounter is long and complicated compared to shooter AI. It surely is very difficult to get the AI to react appropriately to every foreseeable circumstance.

 

So hats off and cheers to all the AI programmers. Ours have done a particularily good job!

[Obsttorte]

There are some things I can second. But I think some of the obscurities are mainly gameplay decisions. If I'm hiding behind a corner in a game, I don't really know how much of my body is showing around the corner, because I simple don't have the body awareness I have in real life. So the simplifications mainly should take the limited informations into account the player has.

 

Of course you shouldn't dumb down a game. But there is a reason why most of us do not do the stuff we do in games. In real life most of the stuff would be way to difficult or dangerous, and in regards to TDM or Thief would most definetely cause us to end up in jail

 

Regarding the searching time: Of course it might seem unrealistic if guards stop searching for you fast, and this was one of the points criticised on Thief 4, too. But I remember dozens of times where I was hiding in an FM at a spot that was too dark for the ai to see me and unreachable for them. So I knew I wasn't in danger and that the ai won't find me, but still have to wait for them to calm down. This can become pretty tiresome, and is probably one of the main situations in which players tend to simple reload a saved game. Even if it is unrealistic, Thief 4 did a good job there, imho.

[V-Man339]

I'm still just stunned by how contrarian the final point on the list is.

 

I want it on record that I don't mind knockouts or the ability to kill enemies while still emphasizing ghost play, it very much is about contextualization and narrative reinforcement.

 

That and shit like the corners, Alekhine's Gun was originally fully realistic so corner cover was essentially useless before a patch.

[grayman]

10 - Friend dies next to you.

This one has two guards talking with one another, and one dies and the other doesn't care. In TDM, conversations abort and alert levels rise and bodies get noticed, so we do a better job.

9 - Peeking around corners.

This is a gameplay thing. Perhaps it's more obvious in a third-person view that heads and shoulders can be seen by the opposition, but TDM's first-person view at least gives you the semblance that you've leaned out just enough to see, but not to expose yourself. And lighting comes into play, too. TDM's lighting is such that when you look at a scene, you think, "There's no way that guard can NOT see what's going on". While you're given enough light (think ambient) to see what's happening around you, it's often not enough light for the guard to see what you're seeing. It's like you have cat's eyes and he doesn't.

8 - Sneaking up on guards.

We simulate this pretty well, even to the point where players have complained they can't get close to guards to KO them. We provide three different AI sight levels and hearing levels, so our players can customize gameplay from extremely challenging to extremely forgiving.

7 - Arrow through the head.

Given enough light, nearby guards are going to spot this in TDM.

6 - Not noticing missing guards.

Here's something we are guilty of. A stationary guard who's left his post doesn't elicit concern from a passing friend who's used to seeing him there. A guard on a fixed patrol route who doesn't show up on schedule also doesn't elicit concern. We've had discussions about this in the past. Mayby we'll do something about these situations in the future. The first should be simple; the second not so much, especially since many patrolling guards operate under RIT rules.

5 - The cardboard box trick.

I think we fixed this. Did we?

4 - Disguises.

The mission author sets up a disguise if it's pertinent to the mission, so I imagine it works as well as the mission author wants it to work.

3 - Hit guard with brick.

We're guilty of this, primarily because the code has no memory of where the brick came from; only where it's going after it's hit the guard. In fact, it seems quite random to me, which is why I made it so the guard AT LEAST looks at the object that hit him, then makes some small attempt to look back where he thinks the brick came from, which may or may not be the truth. Some memory could be added to the brick, though, so it can say to the guard, "Hey, I came from over there!". Smart bricks.

2 - Forgetful guards.

This can be a bit odd, but I suppose it's a gameplay thing. We do provide a fair amount of time for guards to search around and spot you, and when back on patrol, guards will tell other guards that something happened, and to be on the lookout. But it seems a bit odd when you've downed someone and his patrolling buddy--after searching for a few minutes--comes back around 10 times and walks over his buddy's body each time and doesn't at least drop a few flowers or a teddy bear in remembrance. "Isn't anyone going to clean this up???"

1 - Stealth executions.

This probably doesn't apply to TDM.

[demagogue]

Re: the thrown brick issue. The idea that comes to me is that when the brick is flying and lands and emits a sound guards can register (or a vis-stim for flying arrows), the system might also compute a quick vector (the direction from which it flies/hits the ground, maybe as simple as subtracting consecutive xy values), and then there's a simple conditional. If the guard sees or hears the arrow/brick in flight or on impact, then it receives that vector as "where it came from", and that direction gets upgraded for the search (but it wouldn't apply to guards seeing the brick or weapon lying on the ground later). Something along those lines.

[Destined]

I think that TDM has a very good AI. You people did a very good job there and it is good to see, that the AI is still steadily improved, when people have suggestions that make the game more realistic/challenging.

 

6 - Not noticing missing guards.

Here's something we are guilty of. A stationary guard who's left his post doesn't elicit concern from a passing friend who's used to seeing him there. A guard on a fixed patrol route who doesn't show up on schedule also doesn't elicit concern. We've had discussions about this in the past. Mayby we'll do something about these situations in the future. The first should be simple; the second not so much, especially since many patrolling guards operate under RIT rules.

This is really a feature that would be very nice. As we already have absence markers for missing loot, the missing stationary guard should indeed be not too hard to implement. If I remember correctly the main point here was that we have no lines for a missing guard in the vocal set. For the missing patrol, it is really more complicated. One option I recently thought of, would be to create NURBS curve on the longest way of patrol route and when the AI is KOed, an absence marker is created that moves along the NURBS curve with the walking speed of the AI. This would simulate the time the AI needs to finish its patrol and alert the guard when the absence marker reaches it.

Another possibility (that can already be used) would be to estimate the time the AI needs to finish the patrol and as soon as it gets KOed start a timer. When the timer runs out the stationary AI starts a patrol in the opposite direction of the original patrol (as this is the way I would look for a missing buddy on patrol). Then, either the guard finds the body or, after finishing one round on the patrol route gets alarmed. However, this is a quite big setup as you have to double every patrol route, you want to have checked...

 

2 - Forgetful guards.

This can be a bit odd, but I suppose it's a gameplay thing. We do provide a fair amount of time for guards to search around and spot you, and when back on patrol, guards will tell other guards that something happened, and to be on the lookout. But it seems a bit odd when you've downed someone and his patrolling buddy--after searching for a few minutes--comes back around 10 times and walks over his buddy's body each time and doesn't at least drop a few flowers or a teddy bear in remembrance. "Isn't anyone going to clean this up???"

 

This is already very well done in TDM as we have the alert_idle state after being roused the first time. If the mapper wants to he can also send stationary guards on patrol after they have been alerted with alert_idle_only path corners. I think mappers have every possibility to make AI appear to not forgetting anything as long as they make use of this.

[Sotha]

About thrown bricks... Could we let the AI cheat just a little bit?

 

When the AI detects being hit by a brick, get current player position.

AI goes WTF and moves to the position.

 

Sure the player has time to move between brick throwing and brick landing, but considering the fly speed of brick is fast and throw distance is short, the delta between the throwing position and the position the player is when the brick hits cannot be too different.

 

Could this cheating be applied to AI who are shot with an arrow and survive? Currently, you can pepper an AI from the darkness with arrows until they die and they passively take hits without doing much.

 

Would it be better if the AI cheated just a little bit and would run to the shooting position? It would be similar abstraction to the "arrow to the head does not kill alert AI" rule. The AI feels the direction from which the attack came, and attacks there to avoid being hurt again.

 

Of course some additional fuzzyness could be added. Instead of sending the AI to the exact player position, send the AI to random position within 5m radius of the player position.

[Destined]

I agree, giving the player position would be a good option as the AI should definitely be able to determine the direction it was hit from, regardless if it was an arrow or a brick.

 

A similar approach could be used for bottles etc thrown in another direction. The player location (at that point) is given to the AI. Then it first investigates the location of impact (as this is where the sound came from) and then goes to the player location (as this is a likely place from where the bottle was thrown). This gives the player enough time to move (in most cases, this is done to distract the guard, anyway) and adds to realism as the search appears to be more focused.

[wesp5]

Would it be better if the AI cheated just a little bit and would run to the shooting position? It would be similar abstraction to the "arrow to the head does not kill alert AI" rule. The AI feels the direction from which the attack came, and attacks there to avoid being hurt again.

I would be against that. The "alert AI" example you state is bad enough and kills the immersion for me all the time guards magically get inulverable! Also I'm doing a bit of LARP and unless you see the shooter, getting hit by an arrow would only give you little info about the direction, like it came from the back or a side. If the AI would move right on towards the position of the player that would be more "gameplay-magic" ruining the realism. The same goes for the brick, although I agree that the AI should definately be aware that this was no accident and should start random searches!

Edited October 28, 2016 by wesp5

[Oldjim]

Regarding the direction of the arrow

There is a much worse example from the opposite point of view where shooting from long range with a sniper rifle causes all and sundry to focus on your exact position and throw grenades with extreme accuracy

[demagogue]

If it does cheat, it should (1) get the location when the player throws it, not when it lands, in case they run off, and (2) there should be an increasing random nudge or stochiastic fuzzy zone as a function of distance to deal with the issue Oldjim just said. Or maybe just reduce it to knowledge of a fuzzy (randomly within) 90deg arc from the point of impact towards the player at throw-time.

[Destined]

You are right with your point (1), as this would be the most realistic approach. For this we would have to store the player location each time an object is thrown or an arrow is fired and then give this location to an AI that might be alerted. Sounds easy enough (at least for a layman such as I). The "fuzziness" should also be no big issue. When you have stored the player location, you could add a random number between +/-"fuzzyness-factor" to each coordinate (or at least x and y, the z-coordinate might be problematic here). Even the distance could be included as a factor with which the "fuzzyness-factor" is multiplied. The only problem, I could imagine is, if the AI get alerted by other means (especially scripted alerts) it might cause them to search at the last stored player location. I am sure there might be other possible bugs that result from this.

[esme]

I wouldn't worry too much about working out where a brick is thrown from.

 

Having been hit by a flying brick I can tell you it's a case of "by the time you see it, it's hit you" and I couldn't tell you where it came from.

 

If I'd have seen it I'd have ducked, maybe that could be implemented ? a ducking/flinch response for flying projectiles that are seen.

 

A near miss on the other hand, providing the AI happens to be looking in the right direction or sees enough of the trajectory then it could work out a rough area where it might have come from but it needn't be incredibly accurate, give the projectile information that says "I came from that 50 sq metre area over there" & have it disappear or reset to a new area when it hits the ground so the ground needs to inform the projectile of the new area.

 

It's a lot of work for little reward imo, the AI in TDM are the best I've seen

[wesp5]

A near miss on the other hand, providing the AI happens to be looking in the right direction or sees enough of the trajectory then it could work out a rough area where it might have come from

 

That would indeed make more sense than in the case that the AI is hit. Still I think only the general direction should be given to the AI, using the player location even with some randomness would imply revealing the distance too which can't really be guessed with an arrow flying by.

[grayman]

A near miss on the other hand, providing the AI happens to be looking in the right direction or sees enough of the trajectory then it could work out a rough area where it might have come from but it needn't be incredibly accurate, give the projectile information that says "I came from that 50 sq metre area over there" & have it disappear or reset to a new area when it hits the ground so the ground needs to inform the projectile of the new area.

 

 

 

AI only "see" objects that throw off visual stims.

 

An AI won't see an incoming brick even if he's looking right at it.

[Obsttorte]

Isn't the "throwing a brick" thing part of the actual gameplay? I mean, yes, if the brick hits the ai, it may look for the player. But a brick thrown somewhere is actually something I would expect to be able to do to distract the ai. It's basically the same thing as shooting a noisemaker.

 

Maybe it would make more sense to make the behaviour distance dependent. If the object emits the sound pretty close to the ai, it should be believable that the ai notices someone has thrown it and searches for said person. But if the sound comes from a certain distance, it might also be believable that the ai can't tell whether the sound was created by an object or a person and therefore investigates the source of the sound instead of searching for an intruder.

 

However, we would have to deal that way both for objects thrown around as well as the noisemaker, simple for consistency reasons. That an ai behaves different for a noisemaker simple because it is a tool intented for distraction would be very unbelievable for me.

 

Just my two cents, though.

[Springheel]

I would say the only issue is that someone hit with a brick should not search the ground immediately around the brick. And I think our AI already turn and look in the direction the object came from, don't they?

[esme]

 

AI only "see" objects that throw off visual stims.

 

An AI won't see an incoming brick even if he's looking right at it.

 

Ah, bugger, scratch that idea then