Advertisement

Stealth And Detection System

Started by March 19, 2024 10:30 PM
19 comments, last by AliAbdulKareem 8 months, 3 weeks ago

Hello all, I am a senior in the Game Design and Programming major at Southern New Hampshire University, and I am working on a Proof of Concept for a stealth and detection system.

The asset to create is rather simple: The character must be able to sneak and sprint, and there needs to be an NPC that can search for the player, listen for the player's footsteps (louder if they are sprinting, very quiet if crouching), detect the player and chase the player. So far, I have a character that crouches by default and can sprint, but I'm about to start work on the rest of the asset, and I'm curious if anybody has any recommendations on how to accomplish this in an Unreal 5.3 C++ project. I know that I could simply place down a nav mesh and give the NPC a sight and listener component that comes built into Unreal, but I'd also like to accomplish this task via code if it makes any sense to do so. Thus, I come to you all with your vast experience and knowledge to seek aid. Any resources or tips would be welcome, Thank You!

-Jonathan Savastano

Some simple thoughts:

Visual Detection

  1. Check to see if the player is in the enemy's viewing frustum. I use the Radar Method.
  2. If in the frustum, cast a ray from the enemy's eye to the player's bounding box(BB) vertices. If all casts return an object other than the player, the player cannot be seen. If all BB verticies are visible, the player is fully visible. If only some are visible, the player is partly hidden. You could make it so the more vertices visible, the more likely the player is to be detected.

Auditory Detection

  1. When ever the player make a sound (footsteps, firing weapon), send a message to all enemies that a sound was detected, along with the location
  2. Let the enemies decide what to do with the above information when they process messages. If it's far away or there are walls inbetween the location, maybe do nothing. Or maybe just look in that direction. Or investigate (move to that location). A gunshot may produce a stronger response than a floorboard creaking.

Misc

  1. When an enemy is engaged with the player, they store the player's location and velocity. If the player becomes not visible (moves behind a wall), the enemy can walk to the player's last known location, then upon arrival investigate by moving in the player's last known direction/velcoity.

2. I found it useful to give enemies a ‘short term memory’ of the player's current location. If the enemy loses sight of the player, the enemy still knows where they are for a small amount of time. This fixes some simple problems like: a. the player strafing out of the enemies viewing frustum. b. Some other object (like a truck) temporarily blocking the enemies view of the player. c. The enemy gets knocked down and ends up on their back looking at the sky.

Advertisement

@scott8

This is some very useful information, thank you so much. That website lighthouse3D seems to have some amazing insight that will be very helpful for me in the future. I'm going to attempt to codify all of this information, wish me luck!

JonathanSavastano said:
The asset to create is rather simple: The character must be able to sneak and sprint, and there needs to be an NPC that can search for the player, listen for the player's footsteps (louder if they are sprinting, very quiet if crouching), detect the player and chase the player. So far, I have a character that crouches by default and can sprint, but I'm about to start work on the rest of the asset

You SNHU guys are using the term “asset” in a novel way. In my experience, “assets” refers to audio and graphics/animation. Code is made by typing. Audio is not made by typing, and neither is the art and animation (pre-AI-gen). Above, you seem to be using the term “asset” to mean “algorithm” or “process” or “script.” You're the second SNHU student to use the term that way this week, since (apparently) you all just got back to school after spring break. I, for one, am curious to learn more about this novel new definition of the term “asset.” Care to share?

-- Tom Sloper -- sloperama.com

@undefined

Although you are correct and an asset generally refers to artwork, I believe that a code chunk or system could be referred to as an asset as well.

JonathanSavastano said:
I believe that a code chunk or system could be referred to as an asset as well.

Is that a belief shared by your professors at SNHU? Because it's wrong. Code chunks are “code.” There's code and there're assets. You can't start calling assets code and code assets, not if you want to be understood by others in the game development process. One of your fellow students also used the term “asset” oddly this week, so I'm wondering if this comes from your professor(s).

-- Tom Sloper -- sloperama.com

Advertisement

@undefined

Thank you for your input, but I’m here to learn, not to argue semantics with you. It’s a very odd thing to be caught up on, as I think my question was quite clear. My initial post was easily understandable, so your point is moot. Have a nice day, and if you have any real input that has to do with my question, then I’m all ears.

scott8 said:
If in the frustum, cast a ray from the enemy's eye to the player's bounding box(BB) vertices. If all casts return an object other than the player, the player cannot be seen. If all BB verticies are visible, the player is fully visible.

But what if all vertices are occluded, although the player is otherwise partially visible? E.g. if he stands behind a narrow opening in a wall.

I propose to trace at random points in the box volume instead, and make a temporal average over time. This reduces false positives and tells visibility in percentage for the same cost.

JonathanSavastano said:
I’m here to learn, not to argue semantics with you.

And you have been taught what “assets” really means in the game industry. But you choose to react peevishly.

Learn this: clear communication is essential in the game industry (and in the world, and in college). Which means there are words that mean what they mean, and not necessarily what you choose to use them to mean. It's not “semantics.” It's communication.

I hope your professor reads this thread and sees how you behave outside of class. Try this at GDC sometime (using terms incorrectly and then getting snotty with game industry pros who correct you).

-- Tom Sloper -- sloperama.com

@undefined

Good thinking Joe, I’ll take this into consideration as well.

This topic is closed to new replies.

Advertisement