I have setup a standard footstep system in FMOD but as we’re making a multiplayer game I’m just having trouble thinking how we’re going to manage the positional aspect of it… Ideally we’d want the player’s footsteps to be audibly mono and centered but also need the steps positioned in a 3d space so we can network them and other player’s can hear them.
There’s obviously some automation I could do with distance & Sound Size etc but I’m not sure that’s going to sound the best and before doing anything like that I’m just curious if there’s a standard practise for dealing with this situation.
It’s my first commercial FMOD project so never come across it before.
Standard practice is to add a spatializer to the event, and it’ll just work. This is because sounds at to the exact same position as the listener are not panned by the spatializer. Thus, when it’s the local player making the footsteps, the footstep event will have the same location as the player’s avatar, and so have the same panning as if it was not spatialized; and if it’s another player making the footsteps, the event will be spatialized appropriately.
That being said, if you’re not happy with that behavior and do want the local player’s footsteps to come from the center speaker only, there’s a way to do that: Expand the spatializer effect’s “2D Pan Mix” drawer, and automate the “Mix” property that appears on a distance built-in parameter such that “Mix” is 100% at distance 0, but 0% at all higher distances. Then, drag the white dot in the circular “panner” widget to the right of the “Mix” knob up to the top of the circle. The result will be that the spatializer’s normal spatialization behavior is overridden when the distance between the listener and emitter is 0; when it happens, the spatializer effect will pan the signal to the center channel instead.
Thanks for the reply and sorry for the delay in replying back!
Thanks for the information, so the listener isn’t at the same position as the footstep emitters, the footsteps are on the feet and the listener is at head level, I did try to do some automation with the 2d panner etc with a distance of around 2 units which does work but then there’s the problem of what if another player’s feet are extremely close to my listener? for example I’m standing next to some stairs and another player walks up it, the other player’s feet are now 90 degrees directly to my right and say 0.5 units away and I hear them as 2D which obviously is going to sound weird.
If your game allows a non-player character’s feet to be as close to the listener as the player character’s feet, you will need to use a different method.
Broadly speaking, if you want sound effects generated by the player’s character to be treated differently to sound effects generated by other characters, there are two ways to do it. You can either use one set of events for the player character and a different set of events for other characters, or you can create one set of events that behaves differently depending on its parameter values, and have those parameters set to different values depending on whether the sound is created by the player’s character or a different character.
The method you have attempted so far is the latter. This method works, in the sense that changing the parameter’s value does change the behavior of the event; the only problem is that distance from the listener is not a reliable method of determining which character spawned the event in your game, and thus does not reliably result in your parameter being set to the correct value.
The solution, therefore, is to change the parameter’s type from “Built-in: Distance” to something else that can be used as a reliable measure of whether the sound is spawned by the player’s character or another character. For example, if you set the parameter’s type to “User: Labelled,” gave it labels named “player” and “non-player” and had your game’s code set the value of that parameter to the appropriate value after the event instance is created but before it begins playing, it would achieve the behavior that you want.
Hey Joseph, many thanks for the detailed explanation!
Blockquote
if you set the parameter’s type to “User: Labelled,” gave it labels named “player” and “non-player” and had your game’s code set the value of that parameter to the appropriate value after the event instance is created but before it begins playing, it would achieve the behavior that you want.
This could well be the solution, just need to check one thing then, say the player’s footstep plays and we set the parameter to Player, in studio I toggle the 2D pan to 100% which works great but will the other player’s hear that in 2D as well?
It depends on whether your game is splitscreen multiplayer (where all players share the same device) or networked multiplayer (where each player plays on a different device).
If your game is a splitscreen multiplayer title, all players will hear exactly the same event instances because they are all sharing the same set of speakers. There’s no way to avoid that.
If your game is a networked multiplayer title, the key thing to understand is that each player is playing a different instance of your game. Conceptually they might all playing in the same virtual environment, but in reality each player’s device contains its own instance of that virtual environment, and the states of those instances are only kept synchronized by constant communication over the network. This is important, because just as each player’s device is running a different instance of your game, each of those game instances contains its own instance of the FMOD Engine, and its own instance of every event that gets played.
So, when a player does something that makes a sound, what actually happens is that their game will tell the other instances over the network that their game states need to be updated. Each instance of the game will then independently update its state to include the action taken by the player, and create an an instance of the associated FMOD event. From the point of view of the game instance whose player is making the sound, the event was triggered by the player, so that game instance will set the parameter value to “player”; but from the point of view of the other players’ instances of your game, the sound wasn’t made by their player, so the parameter should be set to “non-player” instead.