Jump to content
The Dark Mod Forums

Object and Light Movement Awareness of AI


Fausst

Recommended Posts

I am working on an implementation that makes AI aware of moving lights and objects which it can see.

I wanted to know your opinions about the problem and some possible solutions for it.

 

The problem: AI doesn't react to an object that is grabbed by the player and moved in front of their eyes. I tested it multiple times, even the object is completely lit in front of the AI nothing happens. In fact, you can push them with these objects if you do it slowly and carefully in 1.07 :)(the new 1.08 has corrected being able to push as grayman told).

Related to this, they don't react to candle or lantern light that moves or appears in front of them. You take a candle and completely brighten the front of the AI while standing next to him, there is no reaction.

Also from what I have read from the forum, the player can abuse this by grabbing a pile and creating a shadow for himself. The ai isn't aware of the moving pile, so player can move piles around for creating shadows. After creating enough shadow you can walk inside the shadow and AI won't notice this because it can not detect a moving object.

 

I think it is a major problem for AI and I am trying to find a good solution for this.

I need feedback from you guys in order to understand what I should or I should not do about this problem.

 

Here's my solution:

I created multiple algorithms using different methods in the code. For the moving object awareness, the most simple solution was;

if the ai can see the object && that object is grabbed by player && it also moves

make the AI face to the entity that is moving and set the alert state to suspicious or searching.

I think the AI can handle afterwards because I will just try to make the ai investigate near the moving object.

To get rid of possible issues between other ai, the implementation should find whether the object is held by the player.

 

This is the solution I found for light awareness which is similar to moving objects.

if the light is held by the player (ai eliminated) && the light moves (I don't have an exact idea about this one)

&& the bounding sphere of light intersects with the AI viewcone

turn toward the lightsource

Again if we can only turn the ai to that direction the rest will handled by ai. I mean it is a natural reaction to turn towards where the light comes before going into any states. (I think)

I really know how deep and complex this solution can get but again we can find the source of light candle or torch whether ai or the player therefore complications with other AI would be eliminated.

 

I would like to hear thoughts and possible alternative solutions from the community and the team before trying to implement it.

Edited by Fausst
Link to comment
Share on other sites

  • Replies 57
  • Created
  • Last Reply

Top Posters In This Topic

Sounds pretty cool. Anything that breaks the old gaming rule of "the guards don't care unless they see me the player actually doing something" is good in my book. We've already passed the cute Thief scenario where you can open a door right in a guard's face and he doesn't mind, but there is still the issue of moving lights someone mentioned in the lantern topic not alerting guards.

 

If I were a guard on patrol and I saw a light moving around, I would certainly get suspitious.

--- War does not decide who is right, war decides who is left.

Link to comment
Share on other sites

We've already passed the cute Thief scenario where you can open a door right in a guard's face and he doesn't mind,

 

I made a suggestion about this problem in the I Want To Help section and if somehow I can solve this object and light awareness problem, my next objective will be extended to especially to door awareness but it is another story. I will start a new thread about that sometime.

Link to comment
Share on other sites

Reading through the solution list, I think this sounds fine (on forum electrons, anyway :D

 

The code is able to tell that an object is "grabbed" by the player. In this case, you can eliminate any other AI.

 

About the "if the light is moved", this sounds a little bit complicated. However, we can assume that "if the object is in the grabber, the player either moves or manipulates it". Thus we can just make the movement check easier. So the tests would be in that order:

 

* if the object is in the player hands

* and I (each AI) can see it (it is not too far, it is visible from the AIs POV, and it is lit (either because it is in sufficient light, or it is lit)

* then turn torwards it

* If the object in the grabber is moving (I think this might be easily detected by storing the center of the grabber object each frame, and compare it with the last frame, if they differ, set a flag "object in grabber moves), get slightly more alert every time that happens

* if the object is not moving, but fully lit, then get slightly more alert (so if the player freezes with a hovering crate, that raises suspicion, too)

 

So, at first the AI turns, then he might get slightly alert (and if you move very very slowly in darkness, he ignores you) and if he gets alerted enough, he comes looking.

 

Basically, we would extent the "can I see the player" check with "can I see the object in the players hand".

 

There are two slight compications:

 

* The player can put a lit candle on a small crate, then carefully grab the crate and carry around the crate and candle. Or at least I think you can do this. However, handling the normal case and not this edge case is already much better than before :) At least in this situation the small crate would be lit, so the AI could see the moving crate.

* If both player and object-in-grabber move (elevator ride in dark, AI stands next to player), then the object in the player hands would appear to "move". This can be solved by taking the movement of the grabber object realtively to the player center instead of to the world.

 

 

Anyway, it would be fun to make a map which is totally brightly lit, a few AI, a pile of crates and then have the player cross the room :D (And then see that this no longer works in v1.08 :)

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Link to comment
Share on other sites

I'm pretty sure we already have a solution to handle doors in place, but it's up to mappers to flag doors as suspicious.

 

I know that but the problem is if the door is not suspicious, you can play with the door in front of an ai as long as you want and he wouldn't care.

 

 

* The player can put a lit candle on a small crate, then carefully grab the crate and carry around the crate and candle. Or at least I think you can do this. However, handling the normal case and not this edge case is already much better than before :) At least in this situation the small crate would be lit, so the AI could see the moving crate.

* If both player and object-in-grabber move (elevator ride in dark, AI stands next to player), then the object in the player hands would appear to "move". This can be solved by taking the movement of the grabber object realtively to the player center instead of to the world.

 

 

Anyway, it would be fun to make a map which is totally brightly lit, a few AI, a pile of crates and then have the player cross the room :D (And then see that this no longer works in v1.08 :)

 

These are very good cases to take care of for the solution. There are other cases to think of.

If the player is holding a candle and the ai suddenly turns towards the candle. If it doesn't see the player but only the candle and the player is not moving the candle ai wouldn't have a reaction. But we can add what you suggested:

* if the object is not moving, but fully lit, then get slightly more alert (so if the player freezes with a hovering crate, that raises suspicion, too)

But then here comes another problem;

The candle is grabbed by the player and player doesn't move the candle, but it is also on the table. So the candle is just on the table but because of being grabbed by the player the AI is alerted. Sorry if my English is not clear.

Let's keep brainstorming :)

Edited by Fausst
Link to comment
Share on other sites

I know that but the problem is if the door is not suspicious, you can play with the door in front of an ai as long as you want and he wouldn't care.

 

We had once planned on making AI turn their head towards any door that opened in their FOV. It seems like reasonable behaviour, even for someone not on guard, to look towards a door opening to see who is coming through. The AI wouldn't be alerted by this unless it was a suspicious door, but at least they wouldn't appear to ignore it, and players that aren't careful could be busted when the AI turns to look.

Link to comment
Share on other sites

We had once planned on making AI turn their head towards any door that opened in their FOV. It seems like reasonable behaviour, even for someone not on guard, to look towards a door opening to see who is coming through. The AI wouldn't be alerted by this unless it was a suspicious door, but at least they wouldn't appear to ignore it, and players that aren't careful could be busted when the AI turns to look.

 

Yes this was exactly what I suggested.

Link to comment
Share on other sites

But there are a lot of times a guard is stationed right in front of a door and you can open/look/even got and BJ him.

 

Having them look at every door would break those situations. Sometimes you are in a bright area going through a door, an ai looking could bust you quickly when it's hard to see them.

 

I think doors are fine being flagged if the mapper requires it.

 

Other wise give the player a break. Doors suck in TF2 also for basically the same reason. A player can be standing there with a rocket launcher, door open, boom you're dead, because you can't see what's out there. Sure you can try and fake an possible player out by opening the door a tiny bit and jumping back, etc...

 

But since doors frob all the way open, or you have to grab (close) / open it... to stop it a little, then continue to open I think it would be too much to 'be careful' at every door.

If they moved with the grabber it would be better to have because you could slowly crack it, then continue to open. Having to frob open/closed everytime just to crack it would be lame.

Dark is the sway that mows like a harvest

Link to comment
Share on other sites

Having them look at every door would break those situations

 

They only look if it's in their FOV. They wouldn't turn around if the door was behind them. I'm pretty sure we had already decided to do this, but just never got around to it.

 

Yes this was exactly what I suggested.

 

For an extra level of detail, an AI that is alerted or has logged suspicious behaviour who has a door open in his FOV could stop and watch the door for X seconds. If no friendly AI comes through the door in that time, he treats it as suspicious and walks over to investigate.

Link to comment
Share on other sites

They only look if it's in their FOV. They wouldn't turn around if the door was behind them. I'm pretty sure we had already decided to do this, but just never got around to it.

 

Is this really confirmed, I mean the team agreed to implement this before?

 

For an extra level of detail, an AI that is alerted or has logged suspicious behaviour who has a door open in his FOV could stop and watch the door for X seconds. If no friendly AI comes through the door in that time, he treats it as suspicious and walks over to investigate.

 

Hmm I was thinking that the guard should also turn around if the door is really close but I can see baddcog's point on this. It would somehow break gameplay. On the other hand, this seems reasonable gameplay wise and shouldn't be too complicated.

But it would cause problems in gameplay when an AI gets stuck and can't pass through the door, there is a potential that nearby AI would be distrupted constantly so we should check who is opening the door. But thats implementation part of course. Other than that I don't see any possible problems with watching and investigating. I addition it would allow the player to distract the guard in a new way I think.

Link to comment
Share on other sites

Is this really confirmed, I mean the team agreed to implement this before?

 

Yep. This is from our old design doc:

 

Low Security Areas: AI ignore doors

 

Default: If AI sees one actually open, they'll stare at the spot for a few seconds and comment, then proceed (alert 1.5). Seeing a door left open elicits an Alert 1 comment (like "torches always going out") but nothing further.

 

High Security: If they see the door open, they'll walk over to investigate (alert 2). If they see a door left open, they'll stare and comment (alert 1.5) and perhaps go over and close it?

Link to comment
Share on other sites

What we have now for doors:

 

1 - A closed door is okay.

2 - An open door is okay, unless it's marked by the mapper to be suspicious, using ShouldBeClosed. A guard will investigate a suspicious door unless it's obvious that a friend opened it.

3 - A door in the act of opening or closing is ignored by a guard.

 

In order to keep guards from interrogating every nearby door every frame, we rely on the doors (via visual stims) to tell nearby guards that something's going on. Today, an open door sends out a stim that pings guards w/in its radius, and each has to process the stim when received. If the guard can't see the door, nothing happens and he'll get the next stim later. If he can see the door, then he has to decide what to do about it. He'll ignore all doors except the ones marked by the mapper. He turns off the stim for himself so he doesn't have to continually reach the same conclusion.

 

When the door closes, the stim goes off. When it reopens, the stim comes back on and we start all over again.

 

Closed doors used to send out stims also, but I turned them off because doors spend most of their time closed, and all nearby guards were essentially getting spammed with these stims. The poor stationary guard who couldn't see the stimming door never got a chance to turn it off, so he'd have to handle every single stim that came his way from the same door.

 

If we reactivate the closed-door stim, and let guards treat ALL doors that are stimming them (open or closed) as suspicious, then we could simulate the desired behavior. What we don't have, though, is a stim that says "this door is moving".

 

So let's look at an example.

 

Door opens and a guard gets stimmed. He treats the door as a suspicious door and gathers information about it. All the code that's already in place to handle suspicious doors kicks in, and the guard either decides he needs to investigate, or he goes back to what he was doing.

 

Door closes and a guard gets stimmed. He then runs through the same suspicious door code. The only difference is that he'll probably open the door when he gets to it, whereas previously he was investigating a door that was already open.

 

So if it's okay for a guard to not notice a problem until the door has reached it's full open or full closed position, we probably only need to do these things:

 

1 - reactivate the door stim for closed doors

2 - a guard receiving a stim for a closed door he can't see can just ignore it. it closed when he wasn't around, so it's not important

3 - a guard receiving a stim for an open door he can't see that's NOT marked ShouldBeClosed can just ignore it. It opened when he wasn't around, so it's not important

4 - a guard receiving a stim for an open or closed door he can see treats it as a suspicious door. investigation doesn't occur if the guard determines a friend was operating the door. this code is already there.

 

None of this covers actual door movement, but we would need to create a movement stim if we wanted to be that precise, and I'm not sure there's any added benefit to that, since we can get the desired behavior using the existing door stims.

 

If a full investigation of a door that's NOT marked ShouldBeClosed isn't desirable, the response could be simplified to just looking at the door for a period of time. If the player is responsible, and is lit up enough, he's busted.

 

=================

 

And if the door is not in the guard's FOV? Do we want him turning around, as if he heard the door open? That would really put a damper on gameplay, since there are many situations where you open a door and a guard is looking away, and you lose the opportunity to KO him when he turns around in response to the open door stim.

 

There are also lots of situations where a mapper has placed a stationary guard in front of a door, and there's just enough room for you to slip in behind him and open the door. The mapper has set it up so you can do that, but now the game is going to take that away by having the guard turn around.

Link to comment
Share on other sites

We had once planned on making AI turn their head towards any door that opened in their FOV. It seems like reasonable behaviour, even for someone not on guard, to look towards a door opening to see who is coming through. The AI wouldn't be alerted by this unless it was a suspicious door, but at least they wouldn't appear to ignore it, and players that aren't careful could be busted when the AI turns to look.

 

That's something I'd like to see implemented, because in real-life, people will do look at sources of sound or movements outside of their FOV by turning their head (You just have to watch in RL what happens in places where there is a door that is opened frequently. In 8/10 cases people turn their head to see who is coming through, unless its like a cafetary door, where people stop bothering a long time ago).

 

That little detail will make the AI appear a lot more realistic.

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Link to comment
Share on other sites

So if it's okay for a guard to not notice a problem until the door has reached it's full open or full closed position, we probably only need to do these things:

 

When you say "full open", do you mean until it reaches it's maximum rotation angle (which is what it sounds like) or just when it stops moving? If players frob the door quickly to make it open just a crack, does that mean no stim would be sent out? That actually sounds rather appealing, since it would encourage players to use that feature. But it could also result in players stopping the door at 85 degrees instead of 90 and essentially beating the system.

 

But we don't define low- or high-security areas today. They're simulated via the ShouldBeClosed spawnarg, I suppose.

 

True...that was more just to show that we had, once upon a time, thought it a good idea, not a guide for how to implement it.

 

And if the door is not in the guard's FOV? Do we want him turning around, as if he heard the door open?

 

No, I don't think so. I've toyed with a low-level audio alert locally, but definitely nothing that makes AI turn around, for the reasons you mentioned.

Link to comment
Share on other sites

When you say "full open", do you mean until it reaches it's maximum rotation angle (which is what it sounds like) or just when it stops moving? If players frob the door quickly to make it open just a crack, does that mean no stim would be sent out? That actually sounds rather appealing, since it would encourage players to use that feature. But it could also result in players stopping the door at 85 degrees instead of 90 and essentially beating the system.

 

I think it is better to use a percentage-based system, because that would also cover sliding doors. Door moves more than X % in time Y (defined by the door speed) - trigger alert.

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Link to comment
Share on other sites

When you say "full open", do you mean until it reaches it's maximum rotation angle?

 

I thought the stim was enabled when the door reached fully open, but it's enabled when the door starts moving, regardless of whether it's opening or closing.

Link to comment
Share on other sites

I thought the stim was enabled when the door reached fully open, but it's enabled when the door starts moving, regardless of whether it's opening or closing.

 

Ah, okay then. So an AI will turn to look as soon as the door starts to open, or close. Hmm. We'll have to be careful to make sure that the AI doesn't 'stack' notices and become alert due to seeing those stims...otherwise a player trying to be careful could do the following:

 

1. frob the door to open [creates stim]

2. frob the door quickly to stop it

3. peer through the crack, see an AI, frob door to close it [creates stim]

 

That would actually generate two stims, whereas just throwing the door wide open would only generate one. We don't want to penalize the player for being cautious.

 

I actually agree with Tels that it would be nice if we could fire a stim when the door has gone 50% of its total angle, or something along those lines, but I suspect it's not worth doing that extra work when there's a system in place that already works.

Link to comment
Share on other sites

Yeah, I can see how that would penalize a player for being careful. I guess they'll have to get used to opening it, frobbing it to stop it at a crack open, and then maybe waiting for the AI to de-alert before they close it again. It would be nice if it only went off when the door was opened to a larger angle, but that may be hard to code. We also have a commented out system for "advanced door opening" where you hold down frob and then up/down mouse movement is mapped to door movement for slow opening, but it wasn't quite working to detect when the door reached its closed/open states, so we abandoned it for the time being.

Link to comment
Share on other sites

and then maybe waiting for the AI to de-alert before they close it again.

 

Well, my point is that AI should not "alert" at all due to the door stim. They should just turn their head to face the door for a few moments. If they see something noteworthy, then they can go and investigate. If the door is flagged as suspicious, then they'll alert because it's open, but that's a separate thing.

 

Although, what would happen in the case of a suspicious door, where the player opens it and closes it again? AI would turn to look, see that the door is open when it shouldn't be, and head over to search. If the player then quickly closes the door, does this cancel the stim?

Link to comment
Share on other sites

If they see something noteworthy, then they can go and investigate.

 

What if the player is not visible, yet can play with the door? Not completely open it or close it, just playing with the door in front of the AI. Will it be worthy to investigate for AI?

 

One of the things that breaks the immersion for me is, the player can stop the door AI is closing while all AI can do is to look. AI sees this but just can't react because it is not fully opened or closed. (assuming that we extended or created a system depending on open or close) I think after making the AI turn their heads, we should have a system to make AI aware of the moving door and increase the alert level according to it.

 

More importantly, a system based on the door movement has the potential to solve a lot more things that we can not think of in one shot. It can be percentage based like Tels suggested or we can figure out something else but it is crucial to have it based around door movement, not open or close state.

 

So there are two steps:

1- the door opens and AI turns its head towards the door if it is not already looking.

2- while he is looking at the door it should be alerted depending on the movement.

 

These are completely independent from suspicious door cases and therefore can blend together well. For me this seems like a natural reaction in real life.

 

By the way, about the object awareness that I am working on;

Should I implement the alert system like,

if the AI reaches some alert threshold because of seing a moving object in air, he identifies the player without actually seing him. The logical reason for this is the object should somehow be grabbed by the player. The alert threshold actually represents that it identified who is holding the object. That depends on imagination :) (maybe he sees the player's arm if he looks long enough.)

Or should I make it like, n

no matter how alerted he is because of the moving object, he shouldn't identify the player. This is like the hearing alert. The AI definately knows something is out there but just can't spot it. Last state of search with weapons drawn.

 

So what are your opinions?

Edited by Fausst
Link to comment
Share on other sites

Although, what would happen in the case of a suspicious door, where the player opens it and closes it again? AI would turn to look, see that the door is open when it shouldn't be, and head over to search. If the player then quickly closes the door, does this cancel the stim?

 

The stim is already processed when the AI begins to investigate. If the door is closed by the time the AI gets to it, he will simply open it as part of his investigation. The investigation won't be (and shouldn't be) canceled when the door closes.

 

If a threshold like 50% open is used, then it gets a bit complicated. When opened, the door stim is enabled. Pinged AI are then supposed to decide what to do about it. If we're going to change this so they don't care until the door is open 50%, then we'll need a new door stim that's enabled at that point, so as not to overload the purpose of the existing one. For example, we have to maintain the function of the existing one so that AI investigate a suspicious door that's only open 10%. For that situation, we don't care that it hasn't opened enough to trigger the "50% stim".

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Recent Status Updates

    • Ansome

      Well then, it's been about a week since I released my first FM and I must say that I was very pleasantly surprised by its reception. I had expected half as much interest in my short little FM as I received and even less when it came to positive feedback, but I am glad that the aspects of my mission that I put the most heart into were often the most appreciated. It was also delightful to read plenty of honest criticism and helpful feedback, as I've already been given plenty of useful pointers on improving my brushwork, level design, and gameplay difficulty.
      I've gotten back into the groove of chipping away at my reading and game list, as well as the endless FM catalogue here, but I may very well try my hand at the 15th anniversary contest should it materialize. That is assuming my eyes are ready for a few more months of Dark Radiant's bright interface while burning the midnight oil, of course!
      · 1 reply
    • The Black Arrow

      Any of you heard Age of Wonders 4's OST?
      https://www.youtube.com/watch?v=Q0TcoMGq4iA
      I love how after all these years, Michiel van den Bos still conserves his "Melodic" spirit.
      · 0 replies
    • nbohr1more

      Moddb article is up:  https://www.moddb.com/mods/the-dark-mod/news/the-dark-mod-212-is-here
      · 3 replies
    • Petike the Taffer

      I've been gone for a while, but now I'm back, have a new desktop and I want to get back to making missions and playing missions. And doing other contributions. Waiting for my reset password for the wiki, but I'll take a look at it soon. Hello, all.
      · 4 replies
    • snatcher

      TDM Modpack 4.0 for The Dark Mod 2.12 released!
      · 1 reply
×
×
  • Create New...