 |
For the second test, the guard was standing by the same door, and I was stepping out into the light directly outside the door that opens to the docks. The distance was a bit closer, approx 600 units. I was crouched, and not light fully (no red line) but close to it. 1. When I just walked out and stood in the light, the AI took 4 to 5 seconds before drawing his sword and charging me at Alert 5. However, when I (from slightly further back) turned my lantern on, the AI charged me after 1 second every time (even though he wasn't alert 5). This difference feels strange. Did the exact same test, walking into the light, but standing up this time. Still no red ring around gem but brightly lit. The results were oddly inconsistent. Sometimes the AI started running at me after 1 second, then drew his sword after 4 or 5 seconds. Sometimes the AI stood there, drew his sword after 5 seconds, and THEN charged me. I recorded 10 tries, and had 3 'run first' results, and 7 'draw sword first' results. When the AI ran first, the whole thing seemed quite believable. When he stood there for 5 seconds before doing anything, it did not. In both cases, he drew his sword after about 5 seconds. Overall impression -- inconsistent results. |
|
|
Test 3. Stood just inside the door in the same place as test 1. Waited until the guard got to the furthest part of his patrol (approx 1300 units away). 1. Turned the lantern on for about 2 seconds. Half the time the AI stopped and went to alert 2, and half the time he ignored it (2 seconds must be right on the threshold). Both results seemed a little bit too forgiving, IMO. You'd think a guard who sees a fully lit person for 2 seconds would go over to investigate, even if it's on the other end of a courtyard. 2. Turned the lantern on for about 4 seconds. The AI came running at Alert 3, searched around a bit, and said, "must have been imagining things". That _definitely_ didn't sound right. Did several time tests. If I just left the lantern on, it took 3-4 seconds for the AI start running towards me, and 5-6 seconds before he drew his sword. Overall impression -- too forgiving at this range. |
 |
"4. If I flash the lantern for a tenth of a second (basically as fast as I can turn it on and then off) the AI does not react at all. I find myself having to burn my suspension of disbelief when that happens. We don't want to penalize the player too much, but I would expect at least a comment and a level 1 or 2 alert if the guard sees a sudden flash of light." Remember that he's not seeing a flash of light. He's seeing you in a brighter light for 0.1s. Since probability factors into whether you're seen or not, you've increased the chance of being seen by flashing the light, but it's not certain that you'll be seen. If you expect to be seen, then we have to increase the odds. But increasing the odds is going to make the AI spot you faster in all scenarios, regardless of how bright you are. If we expect the AI to react to the flashing light, then we have to have the lantern stim the AI so that he sees it regardless of whether he sees you. |
|
|
Yes, that's an important distinction I should keep in mind. I suppose, other than the lantern or quickly cycling through the fire arrow, the opportunities for the player to be fully lit for a fraction of a second are pretty limited. I'll do some more tests at close range today, but my overall impression so far is that the delay is probably fine for average players. |
|
|
We have a couple choices for offering options to the player: 1 - Vary the visibility/probability/delay factors per difficulty level 2 - Add a slider, making these adjustments independent of difficulty level |
|
|
We should probably discuss that on the forums. I lean fairly strongly towards a menu option independent of difficulty. Back to the tests, I did a lantern test at a range of about 300 units. When I flashed the lantern briefly, he generally went to a level 3 alert, which is fine. When I left the lantern on, it took him about 2-3 seconds to draw his sword...sometimes he would start running towards me after 1 second and then stop to draw it, and other times he didn't run until after it was drawn, as above. The reaction time didn't seem too bad. I'm going to switch to testing the AI seeing me in lower light. |
|
|
Ok, short range test. AI at 320 units away. I am standing, and not moving, waiting for AI to turn and face my direction. 1. In 75% light (single ambient_world set to 75) It takes the AI 1.5 seconds after facing my direction to register the alert. It takes him another 1.5 seconds after that to draw his sword and charge. That seems perfectly fine. Video: http://www.youtube.com/watch?v=l7EDsdUIvrM 2. In 50% light (single ambient world, value 50). It takes the AI less than a second to register an Alert 1. Then, about 3 seconds later, he goes to alert 3 and starts walking towards me. A second later he then goes to alert 4 and search-walks to a spot (same every time) several feet away from me (I haven't moved at all). He then goes to alert 5 and charges me. From a player's perspective, this doesn't feel right at all. The lightgem is still fairly bright, but he seems confused about what and where I am for a good 11 seconds (the time between his alert 1 and combat mode). Feels like it should be half that much. Video: http://www.youtube.com/watch?v=SguonsbCIpw 3. In 25% light, the AI did not see me at all! He faced my direction for 20 seconds, and after 4 tests in a row he did not even go to Alert 1. This is WAY too forgiving, IMO. The lightgem is dim, but it's still not dark--an AI should be able to see a standing figure across a room in light that bright. 4. Out of curiosity, I tested 35% light, and had the same result. The AI did not react to me at all. |
|
|
I picked up the attached map. I subsequently deleted the attachment by accident, thinking I was in another issue. Edit: reattached map. |
|
|
I've updated the map slightly. Removed the wall and moved the player start right to the desired spot. Also expanded the range of the light to make sure there is no falloff affecting the results. Added a couple wall details to judge distance easier. Moving on to test close range. AI is 200 units away (about the length of two fireplaces). 1. At 50% light, the AI immediately goes to Alert 3 when spotting me, then takes about two seconds to go to combat state. Alert 3 seems a little bit low to me at that distance, when the lightgem is as bright as it is. I would expect him to at least draw his weapon as soon as he sees me. Video: http://www.youtube.com/watch?v=eBfkFW9M30s 2. At 35% light, the AI immediately goes to Alert 3 when spotting me, then runs towards a spot behind me. |
|
|
Here's what's happening at 50% @ 200: 1 - lightgem value is 12 2 - at this lightgem value and distance, and using the AI's visual acuity of 1.0, the odds of my being seen in any given frame are 3% 3 - each frame, a random fraction is compared to this 3%, and when it's more, the AI doesn't see me this frame Repeat the above each frame until the random fraction happens to fall < 3%. In my test, this happened 1.2s after he turned toward me. Once that happens, I'm spotted, and now we determine how much to add to the alert level. The equation for alert increase is 4 + 9*visibility, where visibility was calculated above. For this example, visibility is 0.517623, so we have an alert increase of 4 + 9*0.517623 = 8.658607 This puts the AI into Searching State. He now decides he's going to search near me, so he'll probably start walking toward me. Meantime, we go back to the visibility calculations the next frame. Since the AI is now in Searching State, his acuity goes up to 1.1, so now the random fraction has to be below 3.3% for a hit. He continues toward me until he gets another hit, at 2.2s. This time his alert level goes up by 9.124469. Assuming he's in a grace period where his alert level doesn't decline, we're adding this to his current value for a total around 17.8. Since entry to Agitated Search State is 18, he stays in Searching State. Continuing on, I get spotted again at 2.4s, this time raising his alert level by another 9.124469, putting him roughly at 26.9. Entry to Combat State is 23, so now he leaves Searching State and enters Combat State. Now that he's in Combat State, the "slight delay based on distance" occurs, giving me time to duck out of sight, which I don't do. At a distance of 200, which is pretty close, the delay is around 1s, after which he yells his combat bark, draws his sword, and comes at me. So a grand total of roughly 3.5s transpired from the moment he turned toward me to when he yells his combat bark. |
|
|
Probably the easiest place to think about changes is in the equation 4 + 9*visibility Off to find some dinner. Back l8r. |
|
|
Back. At 50% ambient, which is a lightgem value of 12, what's a good reaction time from the moment you think you stepped into his view to when he yells "Get him!"? In my example above, it took 3.5s. Remember that we want to give the player some small amount of time during which he can duck back out of sight w/o having the AI go to Combat. |
|
|
It's not so much the speed at which he goes to combat, it's the fact that the first alert is only a level 3. It feels to me like it should be higher at that range when the gem is so bright. If he had drawn his sword and given an alert4 bark, it would seem more reasonable even if it still took 3.5 seconds of searching towards me for him to go to combat. What are the thresholds for entering the various alert states? |
|
|
Dammit. I've found something that throws some of these results into question. Seems like when you save the game and reload, the AI behaves in _exactly the same way_ every time. But when you restart the game (even though neither the AI or player has moved) the AI behaves differently. So when I found something that happened over and over again, there's no way to be sure that it wasn't an outlier result, and it was just happening repeatedly because I was loading a saved game. For example, the AI kept going to that exact same spot behind me every time I loaded the saved game. But when I restarted the game, with everything the same, he did something different. And in that low light situation where the AI "never" saw me, I can't be sure whether he might have seen me the next time if I had restarted instead of reloaded. I'm going to have to go back and redo the tests, I guess. |
|
|
I found the problem of why he wasn't heading right to you. It's so freakin' complicated to describe that I won't bore you. I tried to write something twice, and ended up scratching both attempts. Suffice to say that the visual alerts he was getting prior to actually starting a search were causing him to NOT head straight for you when he finally started his search. I'm fixing and testing this now. |
|
|
"What are the thresholds for entering the various alert states?" 1.5 - The alert level threshold for reaching ObservantState (bark, but otherwise no reaction) 6 - The alert level threshold for reaching SuspiciousState (bark, look, may stop and turn) 8 - The alert level threshold for reaching SearchingState (Investigation) 18 - The alert level threshold for reaching AgitatedSearchingState (Investigation, Weapon out, AI is quite sure that there is someone around) 23- The alert level threshold for reaching CombatState |
|
|
Okay, I fixed the problem and in testing he walked right toward me 5 times w/o ever running off to somewhere else. Now I'll look at some tweak(s) to get him to go to (at least) Agitated Searching on the first sighting when ambient is at 50%. |
|
|
I noticed while testing that there were dark areas in the corners of the map, even though the ambient light extended beyond the map borders. Ambient light has falloff, and is spherical? I never knew that. I thought it was constant wherever it was. I deleted your ambient and added the prefab that includes an ambient plus tools plus all the other stuff a mapper might want the player to have. This ambient has a radius of 7777, and is probably the default ambient that most mappers use. At 0.5 ambient using this light, the lightgem jumps to 24 and the player is really lit. Is there a reason you were running your tests with a small-radius ambient? |
|
|
In order for the AI to jump to Agitated Searching the first time he spots me, at a lightgem value of 12, and at a distance of 200, the alert equation has to be 4 + 28*visibility which is quite different from the original. It would take on average 1.4 seconds for an AI to jump to Agitated Searching. That's one sighting. Was there ever any discussion of what lightgem value was the "cutoff", i.e. below which the player would always think he was hidden, based on what he sees as the brightness of the lightgem on the HUD? |
|
|
"Okay, I fixed the problem and in testing he walked right toward me 5 times w/o ever running off to somewhere else." Great! Is there a way I could get this fix so I can test with it? Re: Threshold values. I am puzzled at those values. There is only a 2 point difference between Suspicious and Searching, but then a 10 point difference between searching and Agitated Searching? "Ambient light has falloff, and is spherical? I never knew that. I thought it was constant wherever it was." Yeah, I didn't know that either...I thought ambient_world was constant across the map. I uploaded an updated version of the testmap yesterday that improved it a bit, including expanding the light radius so there's no falloff. Given that and the saved game problem, I feel like I need to redo the tests to get a more accurate picture of the way the system is working right now. |
|
|
If ambient_world's effect varies depending on where the map author places it, that can make a difference in map lighting and the lightgem. The closer the player is to ambient_world, the brighter his lightgem. In my missions, I use the 7777 radius version, but in nearly all of my bugtesting maps, I drop one into the middle and make sure its radius covers the map I'm working with. I don't remember it being this way when I worked on SATC. There was a point where my map outdistanced ambient_world's radius, and my testers complained about a sudden lack of light on the walls. A "sudden" lack of light, not a gradual light fade. I wonder if someone changed how it works somewhere along the way. |
|
|
"A "sudden" lack of light, not a gradual light fade." Yes, I recall that as well. But maybe that was using a different light texture? This map uses lights/ambient_biground, but maybe that's not the correct texture to use for ambient_world. Anyway, you may not have seen my edit above...is there a way I can get the fix for AI running off to the side? I'd like to redo the vision tests and make them as accurate as possible. |
|
|
Ah, that explains the falloff. The standard ambient_world uses lights/ambientlightnfo, which I guess has no falloff. New tdm_game01.pk4 attached. I only see edits if I happen to go back to read something. The bugtracker doesn't notify us of edits. |
|
|
"Re: Threshold values. I am puzzled at those values. There is only a 2 point difference between Suspicious and Searching, but then a 10 point difference between searching and Agitated Searching?" Don't know the thinking behind these. They haven't changed since I started. |
|
|
Any news on the vision testing? |
|
|
Haven't had time to do them yet. I'm taking a short break to beta-test Melan's new mission and fix up some player footsteps. I'll be back to it tomorrow, I hope. |
|
|
Fixed a problem where an AI spots you, but runs to a spot off to your side. This was caused by multiple “sightings” wiping out the fact that the AI was supposed to run to you first before investigating other spots in his search. Rev. 5830: SearchingState.cpp State.cpp Memory.cpp Memory.h |
|
|
I haven't had him run to the side of me anymore, but I have had him turn and start to run off in different directions (sometimes left, sometimes right) before catching himself and running at me. This happens about half the time. See video for example: http://www.youtube.com/watch?v=INDuz3BeTdQ&feature=youtu.be |
|
|
That's weird. He never did that when I was testing. Will check and try to catch it. Bad AI! |
|
|
Fixed a problem where a standing AI that’s just beginning his movement believes he’s blocked, and tries to extricate himself by casting about for random spots to walk to. Changed the code so that the AI is given one second to get moving before he starts to think he’s blocked. Rev. 5831: MovementSubsystem.cpp AI.h |
|
|
SVN rev 13564 has a new DLL with the fix in it. |
|
|
Seems good now. I'm starting my vision tests again, and will post more when they're done. |
|
|
Ai Vision Tests (ambient_world corrected and set to ambientnfo, making lightgem much brighter than previous tests) ** 200 units = close range ** I definitely saw some problems at this range. There is virtually no difference in AI reaction between 75% and 25% light, and the player is invisible at 10% light. Not only that, but the alert counter goes up WAY too quickly...in the 25% test, it went from 8 to 17 to 26 in less than a second. That gives the player no time to react at all. 75% light (red ring around lightgem) AI typically goes to Alert 3 immediately (alert total 13), giving a, "What's that over there?" bark. His alert total goes to 26 nearly instantly, and after another 1-2 seconds he draws his sword and charges me. http://www.youtube.com/watch?v=bzl5CBDDrKc&feature=youtu.be Impression: Too forgiving. The lightgem is in the red; at that close range he should go straight to combat state. 50% light AI typically goes to Alert 3 immediately (alert total 12). His alert total goes to 25 almost instantly following that. After approximately 1 second, he goes to Alert 5. in the video, you can see he goes to Alert 3 for half a second, but it is enough to use his snd_alert3 bark instead of his snd_alert5 bark. http://www.youtube.com/watch?v=qw54RgLEruY&feature=youtu.be Impression: A bit forgiving. Oddly though, the reaction seems about the same as the 75% test. 25% light AI typically goes to Alert 3 immediately (in the video, his alert total goes to 8 two seconds after seeing me, then instantly bumps up to 17 and then 26 in less than a second). After approximately 1-2 seconds, he charges. Impression: This behaviour seems about right for this range and light level. But I'm confused about why it is so similar to the behaviour for the brighter tests. http://www.youtube.com/watch?v=kVeYEhlmXzU&feature=youtu.be 10% light -- lightgem dim but not black AI did not react to me at all during the 20 second window he is looking at me. I reloaded the map 5 times to be sure. Impression: WAY too forgiving, and I don't know why there is such a big change between 10% and 25% light. I would expect at least an Alert1 or Alert2. No video needed. |
|
|
Can you attach the map you're using? I need to get LG values for your test levels and check the visibility chart. Even though the LG value ranges from 0 to 32, it seems that anything above 10 makes you instantly visible. Also, I think we have a disconnect between the brightness of the LG, which sets a player's expectations of whether he can be seen or not, and the true visibility. |
|
|
Ok, I've uploaded an updated version of the map. I think the light is currently set to .1 .1 .1 (10%). |
|
|
I ran a single test in each of the 4 different lighting conditions. 10% - Lightgem is 4 0% chance of being seen, so you never are 25% - Lightgem is 12 Frame 661: 3.02% chance of being spotted per frame Frame 664: spotted 3 frames later, alert up 8.66 (Searching) Frame 665: chance increased to 3.32% due to increased vis acuity in Searching Frame 733: spotted 69 frames later, alert up 9.12 (Agitated Searching) Frame 734: 3.32% Frame 756: spotted 23 frames later, alert up 9.12 (Combat) It took 95 frames (1.58 seconds) to reach the beginning of Combat, to the point where the AI would bark snd_alert5 and pause for a short time before deciding you're an enemy. In this case, he barked snd_alert3 when he entered Searching, and bypassed snd_alert4 and snd_alert5 because 3 seconds hadn't transpired after barking snd_alert3. 50% - Lightgem is 24 Frame 661: 5.37% Frame 686: spotted 25 frames later, alert up 12.28 (Searching) Frame 687: 5.83% Frame 727: spotted 40 frames later, alert up 13.00 (Combat) Same remarks as for 25%, but it took 65 frames (1.08 seconds) to reach the beginning of Combat. 75% - Lightgem is 32 Frame 662: 5.83% (this appears to be the upper limit for chance) Frame 675: spotted 13 frames later, alert up 13.00 (Searching) Frame 676: 5.83% Frame 729: spotted 54 frames later, alert up 13.00 (Combat) Same remarks as for 25%, but it took 67 frames (1.12 seconds) to reach the beginning of Combat. Using probability to decide when you're spotted leads to very variable results, with the potential of reaching Combat quicker at lower lightgem values. Your comment that 25%->75% give roughly the same behavior is true. They do. This allows us to make a reasonable assumption that you're going to be spotted quickly if the lightgem is 12 or higher. This matches my expectation of being spotted, since a lightgem of 12 is pretty bright on the screen. The actual "quick spotting" threshold might be lower than 12; we'd need to test in the 5-11 range to find it. If you expect an Alert 1 or Alert 2 at 10%, realize that it's not going to stop there. He might start at 1, but then he'll advance up through 2,3,4,5 because once there's ANY chance of being seen, there will ALWAYS be a chance of being seen, which means the alert level will be driven up with each spotting. Probably what we need to do is define what the expectations are for 5%, 10% (lightgem 4), 15%, 20%, 25% (lightgem 12). That would help me adjust the equations. At each brightness level, how long to get to each alert level, what alert levels make sense, how long before entering full Combat. Establish expectations for distances, too. 100, 200, 500, 1000. |
|
|
"If you expect an Alert 1 or Alert 2 at 10%, realize that it's not going to stop there. He might start at 1, but then he'll advance up through 2,3,4,5 because once there's ANY chance of being seen, there will ALWAYS be a chance of being seen, which means the alert level will be driven up with each spotting." Ok, there's a big problem here, I think. The AI is adding up alerts WAY too quickly. There is absolutely no value in having AI ramp up faster than the player can react...that just creates cascade failure situations, as you describe above, where a small stumble turns into a complete failure without the player having any chance to react. Let me try to describe the way I _thought_ the system worked, and you can tell me how wrong I am. :) 1. When the player first enters the AI's FOV, a calculation is done to see if the player is spotted. If it fails, another one is done a few frames later, until there is a successful 'hit'. 2. At that point, a value is calculated based on the player's distance, LG level, and AI's acuity. That value is added to the "alert level" of the AI, and the AI's current "AlertState" is determined by that level (anything over 8 puts the AI into Searching, frex). The AI barks and starts whatever behaviour is appropriate for that State. 3. The AI then DOES NOT check to see if they can see the player again (or just ignores successful hits) until the grace period is over (a second or two). After that, we go back to 1. It would play out like this: 1. Player walks around corner; AI is looking his direction. 2. AI gets a "hit" on the player, his alert level is bumped to 9. AI barks, "What's that over there?" and goes to AlertState3. 3. If the player immediately jumps back around the corner, the AI will walk towards the spot and look around while his alert level is steadily decreasing. After his search is done he'll go back about his business. 4. If the player stands where he is, the AI will walk towards him. A second or two later, another "hit" will register, and the alert level will go up to 20 (because he's a bit closer), and the AI will draw his sword and enter AlertState4. After the grace period, another hit will send him to Combat (bumping the player overrides the grace period, I believe). It sounds like you're saying there is no longer (or never was) a grace period for visual alerts, only audio ones? |
|
|
There is a grace period at the beginning of each alert level. I've never worked on them, so I'll have to research how they're used, and get back to you. I did find this comment, though: // Quick hack: Large lightgem values and visual alerts override the grace period count faster This sounds like we'd get through the grace period much faster when spotting the player. |
|
|
The grace periods are being ignored. The intent of a grace period is that, during that period, alerts under a certain threshold amount are ignored. This is to keep alert levels from rising too quickly. For example, if an alert of 13 puts an AI into Searching, it establishes a threshold of 13 and starts a grace period of 3 seconds. Alerts that arrive during the grace period are ignored if the alert increment they carry is less than the threshold (13 in this case). If an alert arrives with an alert increment equal to or greater than the threshold of 13, the grace period terminates and the alert is allowed. In our case, we have the player standing still, so this guarantees that the alert increment per spotting will be equal to or higher than the previous alert increment. (It can be higher because visual acuity goes up as alert level goes up.) So at a brightness of 75%, each alert increment is 13, and since each is equal to the previous, the grace period is ignored. So what happens if we allow a grace period if the alert increment is equal? If we do that, the AI in the 75% test turns around, says, "Hey, what was that?" as he begins to stroll toward me. He continues to stroll until he's standing right in front of me, at which point he barks his war cry, draws his sword, and starts flailing away. He needed 6 spottings to decide I was his enemy. (W/o the code change, he needed 2 at this light level.) Not at all what I'd expect to happen. Testing at 25% produces the same behavior, requiring 6 spottings. (W/o the code change, he needed 3 at this light level.) The lightgem is pretty bright at 25%, so maybe this behavior makes sense. But my expectation was that he'd come straight at me after turning around. I'd want the lightgem a bit dimmer before I'd start to believe he was having problems spotting me. |
|
|
I think the use or non-use of the grace period in these cases is further evidence that we need to shift the AI's spotting of the player more toward continuous ongoing discovery, rather than the fits and starts controlled by grace periods and randomness. But that's for after 2.0. For now, we have a collection of things we can tweak: + the detection equation (the one posted on the wiki) + how we use the AI's acuity and how it's adjusted per alert level + probability + the distance below which you're guaranteed to be spotted at fullbright LG + the distance beyond which you're guaranteed to be safe at fullbright LG + a "fudge factor" currently set to 0.7, used during the probability check + grace period variables (duration, threshold alert level, separate counters for visual alerts) + the reaction time after entering Combat and before deciding there's an enemy |
|
|
"I think the use or non-use of the grace period in these cases is further evidence that we need to shift the AI's spotting of the player more toward continuous ongoing discovery, rather than the fits and starts controlled by grace periods and randomness. But that's for after 2.0." Yep, I'm completely on board with that. In the meantime, I've having some trouble figuring out what would be the best tweaks to make now. "If we do that, the AI in the 75% test turns around, says, "Hey, what was that?" as he begins to stroll toward me. He continues to stroll until he's standing right in front of me, at which point he barks his war cry, draws his sword, and starts flailing away. He needed 6 spottings to decide I was his enemy. (W/o the code change, he needed 2 at this light level.)" Well, one problem is that the AI should probably go to a much higher AlertState on spotting the player at that light and distance. Frankly, I would expect him to go straight to combat. This is probably related to the detection equation, or the threshold values of the AlertStates (remember that Alert4 is 10 points higher than Alert3, while Alert3 is only 2 higher than Alert2--this makes it easy to go to Alert3 but harder to reach 4.) If the AI went to a higher, more "realistic" alert state in the first place, it would work much better with the grace period allowing alert increments of the same value. Plus, if the AI walks towards you, won't they get a higher alert increment fairly quickly, just because they're closer? |
|
|
If you have some time, I attached a new tdm_game01.pk4. In it, I removed the probability factor for player sightings, and made a few other modifications to the math. A tiny alert level is added each frame the AI can see the player, so that it's more like a continuous stream of sightings that drive the AI up through the alert levels. Since grace periods are geared more toward preventing large leaps in alert levels, I'm ignoring the grace periods for player spottings as well. This appears to smooth out the ride to Combat, which happens very quickly in bright situations. This is an experiment, and I'd like to see how it fares in your tests. I played a small amount of Beleaguered Fence with it, as well as your test map at different light levels, and it seemed fine. If these changes don't get us to where you think we should be, I'll still check in some of them, because I found a few bugs unrelated to visibility that need correcting. In an unrelated turn of events, I found that if I let the guard kill me while I'm on top of one of the fireplaces, he gets stuck in that 'leaning back' posture. That'll probably help with debugging the issue you filed about that. |
|
|
I'll be able to test some today. Thanks! |
|
|
Did some quick tests in vision01.map at 10% and 25% light...so far, so good! I'm still invisible to the AI in 10% light, but if I take two steps forward, he starts to slowly ramp up in a very pleasing way. And at 25%, he goes to combat pretty quickly. I'll have to do some tests in actual gameplay situations to see how it feels there. |
|
|
Okay, good news so far. If it passes preliminary tests, it will still need a few nips and tucks here and there to make it seaworthy. I just wanted to see if I was in the right forest. |
|
|
This should help with the "flash lantern" problem, now that probability is out of the picture. The AI will register you during those frames the lantern is on, and how much his alert level builds up will depend on how long the lantern is on. |
|
|
Doing a bit of testing in Too Late. First impressions are that AI are deliciously sensitive now...I'm actually having to use tricks I wouldn't normally do to avoid getting spotted. Makes me wonder if more casual players will find this too challenging.... |
|
|
There is one spot where I'm applying a fudge factor to visibility, its value determined empirically. We might be able to leave it as is for "challenging", and dial it down according to difficulty level or a menu slider. |
|
|
Huh. I think I've found a problem. Try climbing up on to the fireplace before the AI turns around. When I did this at 25% light, the AI turns around, goes to Alert 3 and walks towards me. However, he does NOT look up at me, but looks straight ahead. As he moves closer to my position, his helmet cuts off his view of me, and the alert counter slowly drops until he returns to alert_idle. |
|
|
The AI's visibility scan for the player was checking the player's eye position for FOV. With the helmet brim in the way, there was no FOV. I added a change, such that if the player's eyes failed that test, check the player's feet. That fixes the problem. I'm going to look into having the AI randomly look at a position above or below the alert spot. I notice that they invariably spend much of any search looking at the floor. |
|
|
How's the testing coming otherwise? I'm going to look at the problem of the AI drawing/sheathing/drawing/sheathing when the player is unreachable. |
|
|
I've been testing in actual gameplay conditions and finding things feeling pretty good so far. Barks sound right, and I'm feeling suitably nervous about being spotted. |
|
|
Any better sense of whether we need a slider for "player visibility"? I have the AI looking up AND down now when they're searching. They only looked down before. Looks more realistic. |
|
|
I think we probably will need a menu option. While I'm really liking the new sensitivity, I'm concerned it could be off-putting to new players. I was playing Chalice of Kings, and there was a spot where I had to stand up to grab a scepter from a statue. When I stood up, I was partially lit, and for the half-second I was there, a guard came running over and started searching. I actually got busted, because another guard came patrolling by a few seconds later, joined the search, and together they cornered me. I loved it, but.... |
|
|
It should probably go on Settings->Gameplay. Unfortunately, there's no room for a slider; all slots are filled. We could put two categories above the divider, 'General' and 'AI'. Then we could move 'Combat Difficulty' under 'AI' and add 'AI Sensitivity' (or something that makes more sense, or is more specific to Player visibility) to 'AI'. Then we need to deal with foreign languages. |
|
|
Those menu categories make sense, but here's the lazy/tired man's option: What about just removing one of the options in Settings->Gameplay? I'd be willing to bet that there's not a single person who has used the "HUD feedback for 'use'" option, and I'd also bet no one outside the dev team (and few in it) could even guess at what it does. |
|
|
What words would you want for varying how sensitive the AI is to spotting the player? Is "AI Sensitivity" too generic? "Player Spotting Difficulty" "Challenge Difficulty" |
|
|
I'd go with "AI Vision". It's not completely accurate, but I think it's the easiest for players to understand. "AI Vision" "Forgiving" for the default, and "AI Vision" "Challenging" would be my suggestion. |
|
|
Can I assume we're going ahead with this method of spotting the player? If so, I need to clean up a few things. What you've been testing is mainly a "proof of concept" to see if it provides more realistic player sighting. |
|
|
I don't see why not. |
|
|
The slider is working. It provides a number from 0.0 to 1.0, and this number is used in an equation to determine 'AI Vision' from Forgiving to Challenging. We know that the setting you've been testing with represents Challenging. To help you establish where Forgiving is, the equation will be set up to treat the left end of the slider as 'notarget'. As you slide it up, and the AI starts to respond, you'll at some point say, "This is where Forgiving should be." Then I'll get the number from you and adjust the equation so the slider goes from Forgiving to Challenging. |
|
|
So it's an actual slider? I was assuming it would be a choice between a few specific difficulty levels like Combat or Lockpicking. 10 different levels to choose from is a lot. What was your thinking for going that route? |
|
|
Note above, written 7/18: "We have a couple choices for offering options to the player: 1 - Vary the visibility/probability/delay factors per difficulty level 2 - Add a slider, making these adjustments independent of difficulty level" Would you rather have something like Forgiving/Normal/Challenging? The Combat Difficulty settings start with Normal and work up to Master. |
|
|
Sorry, I didn't pay enough attention to the word "slider". I thought you were asking about whether it should be tied to the mission difficulty level. I'm not sure what the actual term is for what I was thinking of. With combat and lockpicking, you select a specific difficulty option-- "hard", "master", etc. I think they both have 4 options IIRC. That kind of menu option what I was imagining for AI Vision as well. Making it an actual slider, like for mouse sensitivity, gives the player too much choice without enough info, IMO. With brightness or volume, you can immediately test the difference between .2 and .3. But with something like AI vision, you'd have to play multiple missions and pay a lot of attention to notice a .2 difference, which makes it difficult for a player to know what value to choose. In cases like that, I think it's better to just offer a few preset options. Personally, I'd be comfortable with 2 levels for 2.0, at least until we have time to think about the possible impact more (for example, how should that setting affect the stealth score, if at all?). If you favour a bigger range of options, however, I think 4 should be the upper max, with the current setting as 3. (something like "Nearly Blind --> Forgiving --> Challenging --> Hardcore") |
|
|
Where on the 4 choice spread would you place the version you've been testing? |
|
|
I would consider it the "challenging" one. "Forgiving" would be something similar to default 1.08. |
|
|
Fixed a problem where an AI spots you, but runs to a spot off to your side. This was caused by multiple “sightings” wiping out the fact that the AI was supposed to run to you first before investigating other spots in his search. Rev. 5830: SearchingState.cpp State.cpp Memory.cpp Memory.h Fixed a problem where a standing AI that’s just beginning his movement believes he’s blocked, and tries to extricate himself by casting about for random spots to walk to. Changed the code so that the AI is given one second to get moving before he starts to think he’s blocked. Rev. 5831: MovementSubsystem.cpp AI.h Next round … Changed player visibility to eliminate probability and make sightings of the player more consistent and fluid. This allows the AI to see the player during momentary flashes of the player’s lantern, making that event more realistic. Added ‘AI Vision’ menu choice to provide variable settings for AI vision: Nearly Blind, Forgiving, Challenging, and Hardcore. Enhanced AI searching so an AI will look at spots he can’t get to. Allowed AI to spot the player by looking at the player’s feet and eyes, instead of just eyes. This increases the chances that an AI will spot the player when the player is above the AI. Fixed a few ‘grace period’ variables that weren't being saved/restored properly. Made a change so that cowardly AI will flee after their ‘surprise’ reaction time instead of before it. Shortened the length of the Combat ‘surprise’ reaction time by one second. Since an AI can kill an enemy with a thrown rock, code that was being used in the “death by weapon” code needed to be copied over to the “death by rock” code, so that AI didn't react to the sound of the enemy falling, and various other things that need to be turned off when the enemy dies. Don’t use alert level grace periods when the player is spotted. This prevents gaps in the spotting process where it looks like the AI has stopped paying attention to you, even when there’s lots of light. Don’t let an AI draw their weapon if they’re already running the ‘draw weapon’ animation. This was causing an AI to draw their weapon again while drawing their weapon. Rev. 5833: CombatState.cpp SearchingState.cpp State.cpp UnreachableTargetState.cpp InvestigateSpotTask.cpp AI.cpp AI.h AI_events.cpp Memory.cpp Memory.h SysCvar.cpp SysCvar.h Game_local.cpp Rev. 13578: mainmenu_settings_gameplay.gui all the language string files |
|
|
After you update from SVN, run TDM once, then quit. At the end of your Darkmod.cfg file, you should find these new lines: seta tdm_ai_vision "1" seta tdm_ai_vision_hardcore "1.5" seta tdm_ai_vision_challenging "1.2" seta tdm_ai_vision_forgiving "0.7" seta tdm_ai_vision_nearly_blind "0.1" The first one says that the default setting for 'AI Vision' is "1", which is "Forgiving". You don't need to fiddle with that one, since you can change it on the Gameplay menu. As you test the player's visibility, you can change the values for the other four cvars by changing their values in Darkmod.cfg. When you've arrived at what you think is reasonable for the four cvars, let me know and I'll put them in the code as the settings we plan to ship. |
|
|
I made changes to strings/all.lang for English, for the words used by 'AI Vision'. We'll need to get translations from the translators for the other languages. Those will need to go into all.lang. |
|
|
I've been out a good deal, so only just had time to start testing this. Starting with "forgiving", and so far, so good. AI seems to spot me at reasonable light levels and distances, but I have lots of time to recover. |
|
|
That's a good start. Remember that you can adjust the different difficulty levels in Darkmod.cfg. If a particular vision level doesn't feel right, you can bump its number up or down until it does. When we're finished with beta, I'll cement the final numbers in place. |
|
|
Can you give me an idea of what the numbers do? Do they affect the light level the AI detects you at? Or the amount the alert counter increases while you are visible to an AI? Or the threshold values for alert states? Or some combination? It will help me judge the differences if I know exactly what I'm looking for. |
|
|
They directly affect the amount of alert level increase. |
|
|
One thing I'm noticing while testing is that AI almost never go into Suspicious state. That's probably due to the weird threshold levels: 1.5 - Observant 6 - SuspiciousState 8 - SearchingState (Investigation) 18 - AgitatedSearchingState 23- CombatState There's a 4.5 range for Observant, 10 for Searching, but only 2 for Suspicious...? Maybe this made some kind of sense on the old system, but I'm noticing that I almost never see AI in SuspiciousState (unless they're ramping down). I'm going to recommend raising the threshold of SearchingState to 10 to give AI more of a chance to land in SuspiciousState when alerted. I'm assuming it's fairly trivial to change the threshold values (if it's not, ignore this) and if so I submit that it makes more sense to do this now, while we're still testing the vision system. Bumping Searching to 10 will make things a bit more forgiving for the player so it may have an effect on the final values we want for the AI Vision setting. |
|
|
I can make the change. It's a number defined in a single place. I also need to change the amount of time spent in Suspicious and Searching, because I'm sure those were tuned to the current alert thresholds. One ramification, though, is that I'll need to look at Suspicious from the perspective of ramping down. Atm, I'm not happy with what the AI does when ramping down through Suspicious. He just stands there. By doubling the amount of time spent in Suspicious, this behavior will be more evident. For a while, I've been thinking he needs to look around, perhaps turning to look at different locations. Something like Searching, but w/o moving anywhere, and possibly with his weapon holstered. |
|
|
I've always interpreted it as the moment before he's about to give up. At one point I had thought of suggesting a perplexed, hands on hips animation for that stage. I don't see any problems with having him look/turn around, though, but probably only when ramping down. When going to Suspicious from an alert, it would look odd if he stared at the spot he saw something and then turned his back and looked the other way. |
|
|
Right, I'm only talking about adding the looky-look during the rampdown. As far as 'hands on hips' goes, if it's the moment before he gives up, it shouldn't last too long. Currently that duration is between 7 and 9 seconds. If I keep the same alert decrease rate, and move the Searching threshold from 8 to 10, it doubles the duration to between 14 and 18 seconds. That seems like an awfully long time for 'about to give up'. So I suspect that I have to keep the duration as it is, which means his alert level will fall twice as fast with the threshold change. And this faster rate will apply to both cases: when his alert level is going up, and when it's going down, because the same code is used. So when he rises to just below Suspicious and stops there, he will at most spend 7 to 9 seconds looking toward whatever alerted him. |
|
|
Also, raising the Searching threshold from 8 to 10 affects either the amount of time he spends searching, or the rate at which his alert level comes down. So ... do you want him to spend the same amount of time in Searching? This would apply to both rising and falling alert levels. |
|
|
Here is a table of how many seconds an AI spends on average in each alert level: 5 Observant 8 Suspicious 30 Searching 65 Agitated Searching Sotha just commented in the testing thread that he thought the search times were too long. Do you want to consider that now, or push thinking about it until 2.01? |
|
|
Sotha might have a point...I'd be fine with shaving about 25% off those numbers, but I think searching is sufficiently separate from "spotting" that it could be left for 2.01. I'm fine with him searching for a bit less time in Searching state as a result of the threshold change. I agree 8 seconds is plenty for Suspicious. |
|
|
I'll leave Suspicious at 8s and drop Searching from 30s to 25s. |
|
|
Since we're not changing the amount of time spent in Suspicious when coming down, I'll leave the AI's behavior the way it is. Any changes can wait for 2.01 or later. These changes will go into tonight's build: 1 - Searching alert threshold changed from 8 to 10. 2 - Searching duration changed from 30 to 25. |
|
|
Great. I think .6 is feeling pretty good for "Forgiving", so I'll move to test Challenging after these updates go in. |
|
|
Ok, so these are the final settings I think work the best. Not much of a change from the originals: seta tdm_ai_vision_hardcore "1.5" seta tdm_ai_vision_challenging "1.2" seta tdm_ai_vision_forgiving "0.6" seta tdm_ai_vision_nearly_blind "0.2" |
|
|
This just missed tonight's build, so it'll be in tomorrow's. |
|
|
Ok, I think we can set this resolved. While we might want to look into increasing the range of AI vision for Challenging and Hardcore, that can be left for later. |
- Anonymous
