If using MA Multiplayer 1、Could all clients get the same Random result such as Random Pick of Variations, Random Pitch, Random Volume, Random LoopStart, ...? 2、Could a Sound Group(with long-time Music clip) Emitted minutes ago be heard by the new Client just join in the game and play the music clip at the same Time Position which makes every client hear the same music?
If using MA without Multiplayer 3、How to achieve 1 and 2 if just using MA and Photon to Sync Random Results and Current Sound Time Position?
Post by DarkTonic Dev on Jun 25, 2017 17:23:08 GMT
1) Each client has no idea what the other clients random choices are - including the originator, and they will each choose independently, usually with different results. 2) There is no buffering in our RPC's, so no. For some things, buffering is a good idea, but not for audio. You could get let's say 50 sounds all playing at once when you join. Not good. So any audio started before you join will not be heard. The way around this is usually to have your client trigger certain audio - non multiplayer style. Like your music starts when you spawn into the level. 3) I suppose you could write your own RPCs that send the relevant parameters such as current position and call the Master Audio API(s). However things like random pitch and random volume are not part of the Master Audio API method signatures at all, so that would require extending the API itself prior to doing it. But in general, things that are random like that should not really have the choice to be non-random, except for Variation Name, which does have a parameter. I'm not sure why you'd even want to eliminate the randomness. Usually the clients are in different locations anyway so they wouldn't know if the random choices were different or not on each client.
If it's just bothering you during testing running multiple clients on the same computer, I would say turn off the randomness until ready to test on different machines maybe.
Thanks for your answer. I agree that most of the sounds don't need to be exactly the same, but there still got situations that we wish all clients hear the same sound in a multiplayer game. And random always make the game more interesting which MA is good at. If MA multiplayer could first random a seed int and all the client could get a random result by that seed, random will be synced in a multiplayer game. If there are 2 check boxes behind the Multiplayer Broadcast which called Sync Sound TimePosition and Sync Random Seed. MA will be great.(Cause even Wwise and FMOD can't manage the Multiplayer Sync so easily.)
Post by DarkTonic Dev on Jun 26, 2017 19:17:27 GMT
Ok, we could set Unity's Random.Seed to a value and synchronize that between clients. However other plugins / code might set that to something else and screw this up, since it will affect all Random.Range calls, so that's not a good idea.
We could use System.Random (.NET) instead of Unity's Random.Seed and then we would have a seed that only Master Audio uses, this is better.
However, if a client doesn't have the same number of calls to Master Audio random functions, the random values will be out of sync anyway (let's say user A clicked a UI button 1 extra time before joining room). So I don't see how this is possible even with the same seed. I think it will fail more often than not and be me writing a bunch of code to no good effect.
Yes, I am aware that even the huge products of FMOD, WWise and Fabric have zero multiplayer functionality and you'd have to write all your RPC's yourself. That's why we wrote this plugin, to make it dead simple.
Re: syncing time position, I don't see how that's possible since we aren't buffering RPC's, as I said in my first response. When player 2 joins, it doesn't even know what SFX have been played prior to joining the room. And buffering the SFX is a bad idea, I already explained why.
I would love to have both of these features, but I don't see a good way to do either one.
By my experience, I will use a management structure to control the Sync.
1, Any Client triggering a sound send a Request RPC to the MasterClient contents sound name, Master Client generate the RandomSeed and Send the Play RPC with name and random seed to All Client. If the Sound is a Loop or a long-time one, Every Client (Incase Master Client Left or Change) will add to an array or list to register the sound with other properties. When the sound is off it should unregister by some sound over event. 2, When New Client joins in the game, he sends a Playing Request RPC to another Initialized Client, the other client send the register array and generate a time position array back to the new client to sync everything. And the new client would be marked Initialized.
I never used Buffered RPC in any game, I think it is not a safe and clear solution. Normal RPC could just finish the job.
I don't think I understood any of what you explained there.
Take a look at how the code is now (all 95 RPCS are there in source code: MasterAudioMultiplayerAdapter.cs) and let me know how to do modify just one of the RPC's to work as you said (such as PlaySound3DFollowTransform). It sounds like it would need to be done to each and every RPC though, which is fine, if I knew how to do it. The loop / register / unregister stuff I totally have no idea what you mean.
I thought that the seed would be set just once, but it sounds like you have another idea that I don't understand.