Sound Event Propagation

[RoguelikeGCS]

I'm thinking about creating some kind of system for semi accurately allowing sound events to travel around a dungeon or other area. The events should have an intensity value based on the type of sound and loudness; the intensity should decrease as the sound moves, and if the sound passes through a wall (walls will have sound proofing values to determine how much they muffle). Sharp corners (in corridors) might be able to deflect sounds in a perpendicular direction, allowing sounds to properly navigate labyrinthine corridors. This could have the interesting effect of allowing a delayed repetition of a sound. Consider this:



In that image, if the sound is propagated in a somewhat realistic fashion, then the PC would presumably hear the event (muffled), followed by an echo, depending on the intensity. If it's a footstep, it will likely not reach the PC at all.

My maths abilities are somewhat lacking, so I'm having trouble figuring out how to use circles, increase the size of them as the sound event propagates, but maintain the correct muffle values for the relative pixels in larger version of the circle as it increases.

[getter77]

Yay, welcome to Roguetemple!     I've been keeping tabs on thy youtube progress---good to see you've a site going for the project now.

My only suggestion, and not even entirely well thought out, is to pop by Chaosforge and see what methods they undertook on the sound design of DoomRL as it is the only thing that really comes to mind that focused on ambient/tactical use of sound thus far.

[corremn]

First thing ask your self if this is something that would have any real effect in a game.
Secondly would echos really be worth the effort.

Anyway this is how I would approach it.

I would use a A* algorithm for sound (or any other path finding algorithm) , with heavy weights (high attenuation) for traveling through walls, and low attenuation for open space.  Just find the best path from the sound source to the player and that is you sound path.

If you want echo you can calculate the direct path and the best reflected path and find the time delay (number of steps) between them.  In your example, the direct path will go through the wall (we will ignore change in sound traveling speeds as it travels through different mediums) this will arrive first but will probably be quieter than the reflected version.

You could of course sum up the intensities of all reflected waves, instead of echos.

To determine which direction it comes from, find the last step of the A* algorithm before it hits your player and that is the direction (relative to the @). In your example a muffled sound will come directly west first followed by a clearer sound from the north west.

However because sound in a dungeon will fall away very quickly I doubt you will here echos between turns.  You might get a message "You hear a muffled footstep from the west. You hear a loud footstep from the north east." In one turn.

Honestly echos will just really confuse the player.  I would just like to be told the loudest sound, not its echos because echos would really be coming from everywhere. (or not at all because of the sound absorbing of stone walls).

Let me know if you want me to help more clearly. As I seem to be babbling on a bit.

[Krice]

I think there is going to be only little difference in realistic and non-realistic way. No one is going to notice the ultra realistic way, but if you want to spend extra time creating realistic systems it's ok.. I would just draw a line between player and monster and count wall tiles from that line, and the distance. That should be fast and accurate enough I think.

[corremn]

By having propagating sound waves you can have sound coming from the direction you need to travel to get to it (or avoid). I.e the doorway to the north west.  

Cool effect, but like most things just gets in the way of finishing a game.  Its funny how no one ever comes up with the idea to have a '@' walking around and bumping into other monsters to kill them.  We always want to create something new and exiting.  We forget that what people really want to play is a good rogue clone.

[Z]

Keep it simple. I think modelling echos would be strange rather than fun. Unless you see some situation where this helps?

For each cell, calculate how much does it block sounds (attenuation). And then to see whether the sound at X is heard at Y, find the path between X and Y which has the smallest total amount of attenuation, and let the sound be heard be blocked if this total is smaller than the threshold. (I have used that myself for echolocation (a bat can sense all locations for which the total attenuation is smaller than threshold) and I think it works very well.)

That's similar to what corremn said, but A* is a bad choice for algorithm, IMO. If you want (A) only player be able to hear monsters (and/or vice versa), precalculate attenuation between player and each location in the dungeon whenever the player position or the dungeon changes. Since you do this for each target location, Dijkstra algorithm would work well for that. If you want (B) monsters to hear each other, use Dijkstra whenever a sound event happens to determine other monsters which can hear it. In both cases, Dijkstra is easier to implement than A*, and more effective (in case (A), since you then precalculate only once per player move (unless you model changes in attenuation due to monster movement), and you probably would have to use Dijkstra anyway to make monsters able to hear the player, and in (B), since you perform a algorithm better suited to multiple targets).

[corremn]

Note sure why A* is a bad choice. If finds the best (less attenuation) path which is what you want.  Surely Dijkstra would do the same thing. I think it just comes down to a preference between the two. 

Pre-calculating attenuation for each square on each player move sounds a little overkill. However if there a lot of sounds generated this may be worth it. But I think calculating propagation on the fly would be better.

[Z]

Probably it depends whether the dungeon is constructed in a way which is good for A* or not (i.e., whether there are many situations where the A* search falls into a dead end and is forced to search exhaustively like Dijkstra). I am not sure what exactly does the situation look like in roguelikes.

If the dungeon is difficult for A*, that is, A* is roughly as effective as Dijkstra, then it is better to run Dijkstra once per player move than A* once per monster move (assuming that a sound event happens whenever a monster moves).

Anyways, premature optimization is the root of all evil, optimize only when it becomes obvious that it works too slow.

[corremn]

A* will be fine because sound will always reach the target, because it can move through walls, but may no be audible.  A limit on radius for each sound depending on intensity will also help. 
I only suggested A* because that is what I use . 

[Z]

That's not a good argument. A* will always want to find the best path, so even if it sees that there is a direct path through walls (which I assume to have much bigger attenuation than corridors, say 10x), it will not be satisfied and try to find a way around. The path through walls will only be taken if every other reasonable try fails. And to try everything else, it will do an exhaustive search.

[corremn]

That was exactly what I was thinking as I wrote that reply. I was kinda hoping no one would mention that.

Anyway with computers nowadays any good implementation of any algorithm will do the trick.

Anyway I have just implemented the A* algorithm to handle sound and it works like a charm. 
The only problem is how to tell the user where the sound is coming from (for a non sound game). Spamming messages just get lost in the clutter. I am currently having '!'s appear where the sound came from on the edge of the players vision as well as a message.  But the question is how long do I leave the '!' for.

Code: [Select]

#######  ######
#.@...#  #  X #
#.....#### x  #
#.....!xxxx   #  X sound origin
#.....####    #  x sound path
#.....#  #    #  ! player indication of sound.
#######  ######

You hear footsteps from the south east.

Of course adding sound effects and surround sound would be the best idea.