AI sound detection. Possible?

#1 1. Of course.
2. For a beginner? Could be hard.
3. I think so.

You might want to call the container search good enough, or do something simple like whenever a sound is spawned, notifying anything within a specific radius.

#2 You could also check the velocity of the player objects within the radius. More velocity = more 'noise' or sound being created.

B--

#3 Making the bots actually hear the sounds is overkill, not to mention useless. For player footsteps, just have the player do a radius search for AiPlayers while it's moving, and notify any AiPlayers it find about it's "noise". Do the same for other player-triggered sounds (look for AiPlayers in the sound radius and notify them about the noise).

#4 Probably the thing to do is to use the resource initially. Keep the 'sound detection' and the result of the detection in separate procedures / modules / whatever. Then down the road, if you decide that the current sound detection isn't working well enough, you can recode that one piece and your game logic should be untouched.

#5 I'm an inexperienced programmer (1 class in C++, a few in other languages) just starting with game design and the torque engine

A possible reason you might need real sound detection:

- VOIP. If users will be using mics and bots (AI) need to hear "Live" sounds made from the users.

If you could monitor the volume level then output numerical values to the AI to have the AI check a probability of hearing the sound based on the sounds volume level.

Example:
Users speaks into mic and a bot is some distance away ->
actual "peak" volume level (might check once a second while mic is active) is sent to function to find volume over distance (VOD) ->
VOD is sent to probablity of hearing function ->
AI responds if heard or doesn't if didnt hear.

Not exactly sure how possible that is or if that would be too much information to proccess.

concerns:
making sure that all users mics and settings responded the same way (volume output to game). Might need a way of tunning the volume output ingame.

Feel free to let me know if thats just crazy talk :)

-Chris

#6 While I can see tying VoIP to the bots being able to detect you as neat in practice, why then would they use the in-game VoIP?

If the in-game VoIP worked the same as Teamspeak/Ventrilo/etc, but had drawbacks the other two do not, who in their right mind would take what could be viewed as 'inferior'?

Not saying in-game VoIP isn't a great feature, but it needs to provide something comparable to what you can get via an external program.

#7 But onto the original question.

I'd think (and correct me if I'm wrong, since I'm still 'new' to TGE) that you can get the distance between the player making noise, and each AI.

From there, have the chance the AI detects the noice based off a few things.

1) The decibel level of the sound
2) The distance the AI is from the sound
3) How well said AI can hear sounds


So you figure out how much sound is made. Then figure out the distance to each AI that would possibly hear it (keep in mind that the further away the AI is, the lower their effective decibel level). Then multiply by how well they can hear sounds (in the datablock for said AI).

From there, you either have anything above a set threshold always be heard, or have that that value be a percentage chance that noise might be heard.

Myself, I'd take the latter. It makes it more interesting if the AI isn't always predictable.

#8 Yeah... thats kinda what I was getting at... The VoIP thing was the only reason i could think to have actual sound detection though.

Your procedural description seems a little more clear than mine... good job.

#9 Sorry, I haven't responded before. My computer gave it's last breath this weekend so I have been having to check via webmail by my provider.

Ken, what you describe is basically what I was looking for. I want the bot to have the ability to hear someone or something make any kind of noise. That chance should change based on how loud the noise would be at the bot. Also background noises in the area of the bot should be able to drown out other noises.

If I wanted to make a game where you could sneak up on a bot, I could use the senses resource and just add some extra checking for speed and all that. But if I could just have the bot "listen" for sounds then I would be able to have the bot pick up changes in the footstep sound (i.e. one sound for walking on a carpet, and another for trampling through dried brush). That is what I am looking for. Think about how many time as a player in a FPS have you have been snuck up on by another player because you didn't hear them. I would just like to make it as level of a playing field with the bots as possible. So I guess the first task for me would be to learn how torque handles sounds in the game world. Any pointers in the right direction? Thanks for all the feedback by the way.

#10 I don't know if I'm reiderating but doing this without c++ would probably cause constant updates for every bot lag slower (or medium or even fast) computers. Maybe even with c++.

#11 That is a posibility, but unless some tries we won't know the impact. The first try may not be pretty or the best way but it will hopefully get the "little grey cells" (I watch way to much Periot :P) going and a better solution with as little impact as possible can come out of this. I believe that currently the engine sends sound information to each players connection object so that each player can hear them. Again this is theory, but doesn't the bot also have a connection? If the bot's connection is the same as a players then that same data should be there for the bot. Again this is just theory on my part and I have not delved into how sounds are sent. But if this is true then it might be as simple as just making this information available to the bot to process.

#12 Why not just do an event system similar to Unreal's? I implemented one of these in about 2 minutes (literally) for my game.

Whenever any character does something that require's sound to be heard by bots, just call a function called: GameConnection::MakeNoise(%noiseLevel). Then MakeNoise loops through the AI connections in the game and calls their AIConnection::HearNoise(%noiseLevel) functions. Then, you can implement the AI behavior to react to these noises. For continuous types of noises, you could make a toggling event type where you toggle the noise on and the AI will continuously react to the noise until you toggle it off. Something along the lines of GameConnection::ToggleNoise(%noiseID, %noiseLevel, %noiseOn) and then just call it with some unique ID, the noise level and whether it is being turned on or not. The ToggleNoise function would then loop through all AI and call their own HearToggledNoise function or something... You get the picture.

You might think this would require quite a few changes to your script (a call to MakeNoise for every single noise that is made), but you'd be suprised how few noises players/AI generate...

This is certainly better performance-wise than doing a radius check (quite performance intensive) for each AI character connected. Plus, it isn't any more difficult to implement. This is pretty much what Ben was suggesting up above, but you can do away with the radius check all-together.