Sound & Hearing - A new sense group

[bubblobill]

There is a long-held desire in the community to add sound to maps and we now have the capability to play sounds.

With this new power we can implement concommitant capabilities;

• Atmospheric: Noise that is all-pervading and everywhere. No matter where you are on a map, it can be heard.
• Atmospheric-Local: Noise that is intended for players when they are in a certain map region. Everyone can hear the river if the river is in the screen region and max zoom of 0.3.
• Localised: Sound that has a source and;
  • Interacts with a Hearing sense
  • [optionally] attenuates over distance
  • [optionally] has a detectable range
  • [optionally] interacts with sense-blocking map features
  • [optionally] is hearable by tokens

So, reason for the discussion, how to implement?
We have a media class in the code that contains the JavaFX essentials. A URI, start, stop, volume, etc.
For users, we should play sound based on the selected token's ability to hear a sound. Sounds easy, but isn't.

1. A sound source can be everywhere, an area, or a point.
2. Everywhere is easy, we have one or more sound definitions and/or playlists included in the Zone model.
3. An area is harder, we need to attach the sounds to an object. A drawn object, a token's footprint, etc.
4. Point is easy. Only really applies to tokens, add sounds to the Token model.
5. Sound interacts with blocking elements. At it's crudest, it does not pass through walls, which, as everyone knows, is a lie.
6. Sound also goes around corners.
7. Sounds have ranges like sub-sonic, normal, ultra-sound.
8. Sound is attenuated by different environments to different extents. A movement cost. It's one of the reason we plant trees and bushes and build walls next to roads.
9. This all complicates Hearing and associated calculations.
10. We first need a sense that is capable of hearing the associated sound range.
11. So, like sight we define Hearing types. Each being a capability of detecting sound in assorted ranges.
12. Then you get to the calculation trickiness.
13. Atmospheric sound is easy. Constant volume, always audible.
14. Atmospheric-Local is simple-ish. If criteria are met, just play it.
15. Localised is more complex.
16. How far has the sound travelled?
17. A* path-finding including movement costs, i.e. attenuation factors?
18. For a point source this is probably the best way.
19. Not sure about areas. A house on fire is not a point-source, so calculations need to be the best path from a sensor to an area.
20. Fog of War. It's backwards for passive hearing. To stop people just scrolling around the map until they can hear the dragon breathing, we need to limit the sounds to be dependant on a token having been able to hear it at some point.
21. Elevation. I can hear tokens on the level above me in the tower, but not really the ones below me.
22. Filtering. Want to get clever? Pass the audio through band filters so you only get the bass for sounds far away.

So we need a Playlist class that contains lists of sounds/ sound records(?) and how to play them. Sequentially, randomly, concurrently, etc.
We need to be able to attach that to the the appropriate models.
We need a first-step methodology for determining audibility at a simple level that can be modifiable as more complexity is added.
Should we just apply vision-blocking rules to sound initially?

Think about who can hear what in the following picture for the green-zone representing different blocking types

Enough for my initial thinking. I've written it down now and hopefully others will chime-in with their experience and ideas for the best way to implement it.

[kwvanderlinde]

Focus on the core idea and keep that as simple as possible. Expand on it later as needs become clearer.

E.g., if you want localized sounds, just do that. Assume all tokens can hear (or give a "can hear" toggle on tokens), define the sound as a point + range, and then any owners of any token in range can hear the sound. That will be widely useful with very little complexity.

Once it's in the wild and more people use it, we'll have a better idea what direction to go next. Let's also keep in mind that existing features may not be a great fit for some of the proposed sound behaviours. E.g., why would existing *BL types interact with sound? There's plenty of things that block movements and vision, but have little effect on sound. So that could lead us to wanting a new *BL for sound, but there's already so many *BL types which is a problem in its own right. So maybe a completely different approach is needed for sound, or *BL needs some reworking to be better... Anyhoo, my point here is just that these decisions don't need to be made right away. We can let the core idea simmer a bit before deciding on the more advanced features.