Jump to content
The Dark Mod Forums

AI discussion thread


vorob

Recommended Posts

Guys i recently played thieve's den, and when i was behind this guard:

 

TheDarkMod%202013-10-17%2021-13-04-75.png

 

i turned on the light

 

TheDarkMod%202013-10-17%2021-13-07-56.png

 

is that whole dark mod ai problem (they don't care about light from player) or its thives den specific?

Link to comment
Share on other sites

This is the default behaviour.

FM's: Builder Roads, Old Habits, Old Habits Rebuild

Mapping and Scripting: Apples and Peaches

Sculptris Models and Tutorials: Obsttortes Models

My wiki articles: Obstipedia

Texture Blending in DR: DR ASE Blend Exporter

Link to comment
Share on other sites

Light by itself is not going to put a guard on alert. And a "change in light" would be tricky to do too, since a change in light hitting the AI by itself isn't always suspicious. Game AI aren't supposed to be necessarily intelligent. They just act on certain stims.

 

There are a few cases where the AI can be a little smart. The mapper can put a stim on doors that should be closed, and if he actually sees it open, or a light/torch out (that should be on), he'll get suspicious. I'm trying to remember if that includes closed doors (that should be open) and lights on (that should be off), but if so, then that would get the AI to get suspicious if he actually looks directly at the light. And AI look towards a door that opens right beside them IIRC. So they're getting better. Maybe light-changes will get included in the future too.

  • Like 1

What do you see when you turn out the light? I can't tell you but I know that it's mine.

Link to comment
Share on other sites

Well this happens most likely because of:

-player lantern

-player carried lightsource

-physics induced movement of lightsource

 

The third can be ruled out in most situations because the noise alerts the guard anyway.

 

I dont know exactly how TDM scripts or code works, but maybe a variable could be turned true if player activates lantern, or while frobbing a lightsource type object.

When this variable is true then all AI would perform an extra distance check of the player ( even if one a half sec) , if its within a certain radius the guard would perform a quick turn-around. If player is there he will see him and gets alerted, if not he turns back and continues.

 

Walls or doors would present a problem, but if the distance is reasonable and as long as its a simple turnaround and not an instant alert its not that big a deal.

Link to comment
Share on other sites

Grayman and I were talking about this just a few months ago. The AI can't actually see "light", it just sees the light source (in this case, the player's lantern, which is behind him), or the player. Getting AI to notice when light hits other surfaces would be complicated to code and a big performance hit on top of that, so we scrapped the idea.

Link to comment
Share on other sites

I played around with that either. The easiest possibility is to add an light stim to the ai, combined with a script checking whether the light source is the player lantern. However, this way ai does only react if they are hit by light, they don't see it if surfaces is hitting other surfaces next to them.

FM's: Builder Roads, Old Habits, Old Habits Rebuild

Mapping and Scripting: Apples and Peaches

Sculptris Models and Tutorials: Obsttortes Models

My wiki articles: Obstipedia

Texture Blending in DR: DR ASE Blend Exporter

Link to comment
Share on other sites

The method i described up there isn't relying on Ai seeing the light. Wouldn't that kind of simplification of the problem work?

 

This is something worth investigating. Rather than checking light levels on nearby surfaces, which is a PITA as Spring said, an AI can add one extra check to the player scan he normally does each frame. That would be the check you suggest, with these steps:

 

1 - If the player lantern is on,

 

2 - and the AI is w/in its radius,

 

3 - and there is LOS from the AI's eyes to the player,

 

4 - then the AI can be made to turn toward the player, with a bump in alert level equivalent to having heard a suspicious sound.

 

5 - Then, if the player is visible, the normal player-spotting code takes over

 

6 - otherwise, the AI returns to what he was doing after his alert level drops back to idle.

 

Pros:

 

1 - Good simulation of an AI recognizing a suspicious light change.

 

Cons:

 

1 - It's possible that the above check can cause the AI to turn toward the player when none of the surfaces the AI is looking at are lit by the lantern.

 

2 - Why would an AI be interested only in light from the player's lantern, and not light from lanterns (or torches) carried by other AI?

 

3 - Why would an AI not be interested in other lighting events, like sudden light coming through an open door or window?

 

4 - Why would an AI not be interested in surfaces lit by the player's lantern, when the AI is outside the radius of the lantern?

 

So implementing something like this--even when a simple solution is recognized--can lead to all types of "but what about this?" situations.

Link to comment
Share on other sites

This also wouldn't solve the situation we talked about earlier, when the player is behind a crate and turns the lantern on. Even if the AI turns towards the player, they won't see him, even though they should realistically notice the light.

Link to comment
Share on other sites

It'd be an improvement over the current system though. And having an AI turn towards the player, even if it doesn't spot him, is still tense, so it'd benefit gameplay in any event.

  • Like 1

What do you see when you turn out the light? I can't tell you but I know that it's mine.

Link to comment
Share on other sites

Well instead of each and every AI checking that, instead, whenever the lantern is activated it should do a trace from the lantern to see if it has a direct line to an AI within the radius of the light. And maybe cancel out the trace once it finds the first AI to prevent performance degradation, as the AI who sees the player will alert the other AI.

 

EDIT: Ah, I didn't read your entire post grayman, you already thought of that. And yes the situations where the simulation breaks down would be very jarring to the player.

I always assumed I'd taste like boot leather.

 

Link to comment
Share on other sites

This also wouldn't solve the situation we talked about earlier, when the player is behind a crate and turns the lantern on. Even if the AI turns towards the player, they won't see him, even though they should realistically notice the light.

 

Can't make it perfect.

I always assumed I'd taste like boot leather.

 

Link to comment
Share on other sites

An off the wall idea (heh, pun intended), what if turning the personal light on (and perhaps off) had a noise associated with it? Whether audible or inaudible fake "noise" in code just to trigger AI response? (Since what self respectful thief wouldn't oil the sliding shade on their lamp?)

 

That way it would trigger existing code checks without a performance hit, although similar pros/cons as suggested above. Although if surfaces were lit that weren't directly in line with the AI's view, I'd blame radiosity, their "sixth sense", or subconscious awareness, etc.

 

In addition, if the lamp had an in code inaudible "sound" associated with it when on, it could trigger the behind the crate circumstance. But I'm tired, so not thinking of negative ramifications at the moment. (Close AIs on the other side of a door should respond, "seeing" light bleed under the door, but thin solid walls or other opaque screens obviously shouldn't, while openings obviously should--but it seems sound works this way in the game.)

"The measure of a man's character is what he would do if he knew he never would be found out."

- Baron Thomas Babington Macauley

Link to comment
Share on other sites

  • 1 month later...

Yeah this one should be improved. Other idea:

 

player entity seen = visual stim -> response = alert

"lantern light entity" (make an entity visible only by AI with the right radius, attached to the player when lantern is on) seen = visual stim -> response = lesser alert

 

It would work for the crate case, but there might be issues when the lantern is lit and the AI is already in range so he is inside the "lantern light entity". Might be combined with a range check + RJ's fake sound idea, with fadein=fadeout=lantern range. Probably not really performant though.

 

For all other cases, eg player carrying a moveable candle, let's forget about it it's too complicated, maybe talk about it in 20 years when computers get more powerful.

 

There are a lot of cases which are not realistic, but sometimes it's take too much effort/skill to code (assuming it's possible) and it would use too much resources.

 

A problem I found while playing Patently Dangerous: when I hid in a thin line of shadows behind a post outside Soren's house: logically a guard should see my shape as the area behind me was enlighted, and want to have a closer look. Probably not the best example, because in this case, there is a way to avoid this in mapping, when placing lights and using noshadows spawnarg.

Okay, now this one: a guard is patrolling, you take him off, and then walk his patrol route. Next guard cannot see but is alerted by the sound. Why would he, if you are not running? But OTOH, how to implement a fix? (one could argue the need for that fix, but that's not my point)

 

Sometimes, you should just enjoy the mechanics if it's fun that way.

Edited by Bastoc

Jared, is that you ?

Must be rats...

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

    • Petike the Taffer  »  DeTeEff

      I've updated the articles for your FMs and your author category at the wiki. Your newer nickname (DeTeEff) now comes first, and the one in parentheses is your older nickname (Fieldmedic). Just to avoid confusing people who played your FMs years ago and remember your older nickname. I've added a wiki article for your latest FM, Who Watches the Watcher?, as part of my current updating efforts. Unless I overlooked something, you have five different FMs so far.
      · 0 replies
    • Petike the Taffer

      I've finally managed to log in to The Dark Mod Wiki. I'm back in the saddle and before the holidays start in full, I'll be adding a few new FM articles and doing other updates. Written in Stone is already done.
      · 4 replies
    • nbohr1more

      TDM 15th Anniversary Contest is now active! Please declare your participation: https://forums.thedarkmod.com/index.php?/topic/22413-the-dark-mod-15th-anniversary-contest-entry-thread/
       
      · 0 replies
    • JackFarmer

      @TheUnbeholden
      You cannot receive PMs. Could you please be so kind and check your mailbox if it is full (or maybe you switched off the function)?
      · 1 reply
    • OrbWeaver

      I like the new frob highlight but it would nice if it was less "flickery" while moving over objects (especially barred metal doors).
      · 4 replies
×
×
  • Create New...