Open omidastine opened 3 months ago
Dissonance cannot handle a session of 10,000 users with any of the standard network backends.
The objects being created here are the "playback pipelines" which handle buffering, decoding and playing back the audio for each remote speaker. Every client needs to be aware of every other client in the session, this can scale to hundreds of users but definitely not thousands!
It's not really possible to have 10,000 people all in an open voice chat session though. The noise would be overwhelming and nobody would be able to understand anything anyone said!
If your game splits the session up in smaller "sub sessions" (for example, an MMO with 10,000 total players but each player only able to speak to the nearest ~10 players) this can be done with a custom network backend (OrbusVR used Dissonance in this way - hundreds of players in a server but each only in a session with the nearest 5-10 players).
Our structure is as follows: ten thousand users connect to a server. Players who are in the same game join a common room and can talk. The problem is that for all the players who connect to the server, objects are created automatically on all clients. Our goal is to create objects only for players who are in the same room
Hello , i have this same problem in my own project. i am developing a voice chat feature with dissonance and Unity. How can i separate the users by creating different sessions? The dissonance documents haven't mentioned anything about sessions and how to create different sessions for different groups of users.
Which network backend are you each using? I'm not sure there are any backends we support that will scale smoothly to 10,000 players out-of-the-box!
The problem is that for all the players who connect to the server, objects are created automatically on all clients. Our goal is to create objects only for players who are in the same room
The Dissonance network packages are built to host a voice session for everyone in the same network session, so the problem here is a mismatch in expectations on what a "session" really is. Dissonance thinks it's everyone connected to the network, you think it's everyone in a smaller group. I think you should be able to address this with a custom network backend.
The core of a backend consists of 4 methods:
Normally there is one single server instance running on the network server, when a client calls Send
that packet is sent to that single server instance. In your case if you create many server instances (one for each game "session") and then make sure that packets sent from a client are delivered to the correct server for that client's session, this should work. Each client will only be aware of the other clients who have packets routed to the same Dissonance server instance.
Thanks martin.
We use NetcodeForGameObjects , at first we prevented Player objects to be spawned on all clients and we made them to be spawned only on the clients from the same group. And now it doesn't make sense to spawn 1 Gameobject per client on all clients scenes , even for 500 clients it doesn't make sense and it would be a burden on the player's device performance. Would it be a good idea to destroy the extra objects on the client scene?
If you're using NFGO I would advise discussing with the NFGO devs about what they consider "large scale". Searching around a bit I cane asily finds discussions from a couple of years ago where they were talking about large games with 64-128 players being possible with NFGO, with some work. 10,000 is obviously a long way beyond that!
at first we prevented Player objects to be spawned on all clients and we made them to be spawned only on the clients from the same group
Is there any reason the players from different groups are all connected to the same network server? Instead of having one more reasonable size server per group? That would work out-of-the-box with Dissonance (and not push NFGO past it's limits either).
And now it doesn't make sense to spawn 1 Gameobject per client on all clients scenes , even for 500 clients it doesn't make sense and it would be a burden on the player's device performance.
There's no way around 1 gameobject per player in the voice session - there needs to be one AudioSource per remote speaker for voice playback. That's why I'm suggesting smaller sessions (either with actually smaller sessions, or through the custom network approach I mentioned above which effectively runs many small Dissonance sessions within one large network session).
Would it be a good idea to destroy the extra objects on the client scene?
Definitely not, you'll be deleting various behaviours used by Dissonance for audio playback! Also while the playback objects are the most obvious effect of an enormous session, there are various other things that scale with number of players within Dissonance.
Hi we have a problem that in the script of DissonanceCommsImpl.cs There is a callback called Net_PlayerJoined which instantiates 1 object per each connected client and this will be a problem for us in production because we have too many users and if 10,000 clients connect to our VoiceServer , the client's game will crash. how can we fix this problem?