We currently have the AudioListener component on the camera, as is usual in many Unity games. This is totally fine for a 1st person game, but for our 3rd person perspective, where do you think the audio listener should be?
If we choose to go with a solution that requires some code, we’ll use this thread as a basecamp for that task.
PS: I brought the question to Twitter too, plenty of interesting replies there! I suggest to check those replies before commenting - for the sake of not duplicating comments.
(and you can vote here or there, we’re more interested in the reasoning behind)
Check the Twitter discussion linked above because the replies are on fire!
Can the audio listener move around every time a sound is played?
After a few (many) tests, seems like the best position would be close to the character. However, this yields another small-ish task. I’ve put it on the roadmap, in case someone wants to take a shot at it.
https://open.codecks.io/unity-open-project-1/decks/15-code/card/1gw-orient-audio-listener-to-camera
I’d like to give this one a shot!
Proposed, very simple, fix: Add script to orient audio listener with the camera by pointfivetee · Pull Request #457 · UnityTechnologies/open-project-1 · GitHub
Possible issues:
- Is it overkill to run this script every frame?
- Will this have the desired effect when the camera does something unusual, like switching to a cutscene?
While it might be more “performant” (but how much?) to not use a Unity message like LateUpdate, I think running it every frame is important, to give immediate feedback. Sound is super key to the experience.
That’s a thing I have been thinking too. One way would be, through the cutscene, to disable that AudioListener via an Activation track (or disable the whole playing character?) and activate another one (in the CameraSystem?).
Or, switch the character Prefab to “cinematic mode”, which in turn would disable the AudioListener object… need to give it some thought!
I was also thinking maybe to fetch the transform we could use the “Anchor” system we have in the project, did you see it? That would be better than polling Camera.main (that also has a cost, but it could be cached) - and at the same time I don’t trust Camera.main to always return the correct camera 
1 Like
Had not seen Anchor, will look into that next.
I think that’s good! Need to test it though. I will soon.
Thanks!
Yes, it was implemented, that’s why it’s green (done). I just need to move it to a non-todo deck.