- Home /
best way to make a multiplayer physics heavy game (3000+ rigidbodys)
well I have my game running 3000+ rigidbodys perfectly fine and now it is time to start on multiplayer. does anybody know of a good way to make a game with 3000+ rigidbodys with about 700 non-sleeping blocks multiplayer?
I was thinking the clients do all the physics and the server manage the players positions and when they have fired so the bandwidth is at a minimum
does anybody have any other suggestions on how to do this and what server side software should i use for this, it would be really nice if the server software was open source. thanks
also is there a way to edit prefabs inside of prefabs?
FYI: physics will not work identically on everyone's machine running your game. You cannot rely on physics as being deter$$anonymous$$istic. The physics will try to maintain a constant timestep, but if a machine can't support it it will vary. As soon as the physics timestep varies, your physics simulation will vary - this is discrete physics, not continuous physics.
So you will have to have an authoritative physics simulation (most likely a headless Unity instance on your server) and then send out periodic updates from there to make sure all clients stay in sync.
Well, the downside to letting users run physics and syncing with the host is that you're no longer authoritative. That means that the user has authority, and if they have the technical skill, they can cheat by sending whatever physics information they want.
If that's not an issue for you, then by all means just do it on the user side and let them be authoritative. It'll take a lot of load off of your servers.
This is very hard, and very much impossible to properly make authoritative
now it is time to start on multiplayer.
Where did you get the idea that the time to start on multiplayer is after investing significant time into a gameplay mechanic that is only really workable in single player? I really wonder because that seems to be a very commonly held belief. Just prototype the whole thing as single-player, and then worry about how to tack on the multiplayer stuff as the final step. No. The proper time to start on multiplayer is after deciding that the game you are going to make will be a multiplayer game and before doing anything else.
I'd agree about 90% :)
Prototyping a certain amount in single player, I think, is fine, as long as you understand what it will take to get to multiplayer.
In other words, it's fine as long as you understand how to design for multiplayer and design with multiplayer in $$anonymous$$d.
It's like any other major component of your game - you don't get to the end of your prototype and say "okay, now it's time to add a UI" - you design with the eventual UI in $$anonymous$$d, maybe you sketch it out before you even get started, and you only design so far before you start working on UI elements.
Answer by Julien-Lynge · Jul 10, 2013 at 03:49 PM
There is no simple solution for this, because this is not a simple question. The only real answer that can be given is "it depends..."
If you aren't worried about being authoritative, e.g. you trust all players not to cheat, you can run the physics on client machine(s) and take the load off of your server. You'll either need to pick a user to be the authoritative physics or find a way to manage divergence among your users. If you do want physics to be based off of more than one user, that will entail more communications (rather than one-to-many, you'll have many-to-many syncing).
If being authoritative is important to you, then you have to run the physics yourself, on your server. The easiest way to do it is to run a copy of Unity running the same game with the same state the players are, and let it have the final say on physics. Alternatively, you could set up PhysX to run without Unity, use another physics solution, or write your own physics calculations that will run in Java or some other language (preferably a native one, not a VM).
Either way, you will have to communicate that information over the network to players. You will run into a couple major issues there:
Latency: by the time the physics gets there, it will already be old
Bandwidth: sending position and rotation for 3000 objects will take at least 72 kB per frame, so at 30 frames per second that's 2.1 MB per user, assuming no compression.
The short answer is: it's not possible to send that much information over the network. You will likely need to come up with a solution that interpolates or extrapolates (to account for latency), and send the data less frequently, more as a 'correction' than a driver of physics. E.g., let the local user handle physics, and send them rough corrections every so often for when their physics diverges from what is authoritative.
I have to stress that this is a monumental task that professionals would struggle with, which is why people get paid big bucks to design gaming servers.
just to add to Julien's excellent answer, you might want to look up a strategy called Dead Reckoning, sort of a hybrid where client and server run the physics, the client getting more occasional "corrections" from the server. From wikipedia:
"Networked games and simulation tools routinely use dead reckoning to predict where an actor should be right now, using its last known kinematic state... This is primarily needed because it is impractical to send network updates at the rate that most games run, 60 Hz."
right - I've never heard it called "DR" dead reckoning, but yeah "predictive" $$anonymous$$P is just the normal way anything complicated or fast-moving is done these days.
even if someone trusts to players is it ok to run simulations on client side, because engine may perform slightly different simulations on any end user so what they have seen might differ I think
Answer by IsaacP · Jul 30, 2015 at 06:09 PM
Well.. it depends how much accuracy is needed.
One way, of many, is a lock-step method with a deterministic physics engine. You will be able to avoid sending loads of physics information. However, there will be a slight input lag which is not great for competitive play. This is what halo does for their multiplayer Campaign mode.
If you can't do that, you will have to find someway to compress, cull, and prioritize that information. For example, the player does not need to know that a box shifted 2 feet on the other side of the map right away. You can send this information at a later time. So, "sending position and rotation for 3000 objects will take at least 72 kB per frame, so at 30 frames per second that's 2.1 MB per user." Now if you prioritize that info where 10% (300) of the objects are sent at 30 fps and and the rest are sent at 1 fps then you have 281 KB per user
Something to remember is that what you're trying to do is create the illusion that everyone is playing together. I recommend watching this video: http://www.gdcvault.com/play/1014345/I-Shot-You-First-Networking
I was thinking the clients do all the physics and the server manage the players positions and when they have fired so the bandwidth is at a minimum
So this maybe a good idea for a players vs monsters(npc) game. However, this becomes a problem in a pvp game. Lets say you crouch behind a box. If the physics is out of sync another player may see you crouching but they may not see the box! it could be on the other side of the map. They shoot you, you die, you rage quit.
does anybody have any other suggestions on how to do this and what server side software should i use for this, it would be really nice if the server software was open source. thanks
You will most likely need a server with the exact same physics engine (headless unity). Unless, you are ignoring all physics, or physics is somehow calculated and sent by the players.