running identical sim requires some setup that decouple physics and render/game thread. Rocket League is a good example even though it only simulate 6 player controlled box with cosmetic cars render in place. RL is server authoritative, so your local sim is just there until server ask your client to sync up.(with modern rubber banding interpolation across frames basically.) Any game with frame rate dependent physics(Unreal is still kinda frame rate dependent) can’t approach running sims on all client and hope them to sync up. cause their delta will not be the same. And if they do have a fixed delta physics engine, then like you mentioned, the slowest client will affect how the server can progress the clock. It’s a good enough implementation pre dedicated server era, but for modern approach with anti-cheat in mind, it’s no longer adequate.
I think for multiplayer game, there are a couple things are in current “trend”:
server offload simulation, basically the dedicated server off load the physics to a bunch of cloud nodes that only does the physics sim, take the result and ask the client to sync up. It’s not really “new” just that the implementation would get better. Search StarCitizen’s server meshing shown recently. This can scale up really big sims but the network bandwidth required would be prohibitive, cause it not only scale with the players also the physics bodies needs to be updated. (so yeah, always trade offs. )
fixed time delta physics engine on server, like Rocket League mentioned. This works fine with limited amount of physics body and are really stable, but you can’t do large scale sim with fixed time delta physics engine. (the more physics bodies, the slower it is to update the sim result.) Also this type of sim is has really limited range in space cause floating point error if physics body go really far from origin. But on the other hand it’s much more reliable, predictable and easier to do input buffer so it’s really responsive if you only need to handle limited amount of physics bodies.
async/multithread physic engine, it can still be deterministic if the inputs are the same(see JoltPhysics as example), it can scale up to large amount of physics bodies since most would be in “sleep” state once they are stabilized. very “mature” in single player game, but for multiplayer you still need to wrangle the “sync” up part. Less expensive to update compare to first one, supports more physics bodies than 2nd one, but nothing is free so you need good server(no offload) and your game framework needs to be able to support it.(what ChaosPhysics is working on). It would cost “less” to host compare to first, but significantly higher than 2nd. (well, if someone use fix time delta to sim large amount of physics bodies, then their server will cost way more than async, but no one would do that anyway. ) Example game would be like The Finals that was doing beta recently from what I can see in the gameplay videos. (they have mixed cosmetic, running only on clients, physics and server synced physics. )
running identical sim requires some setup that decouple physics and render/game thread. Rocket League is a good example even though it only simulate 6 player controlled box with cosmetic cars render in place. RL is server authoritative, so your local sim is just there until server ask your client to sync up.(with modern rubber banding interpolation across frames basically.) Any game with frame rate dependent physics(Unreal is still kinda frame rate dependent) can’t approach running sims on all client and hope them to sync up. cause their delta will not be the same. And if they do have a fixed delta physics engine, then like you mentioned, the slowest client will affect how the server can progress the clock. It’s a good enough implementation pre dedicated server era, but for modern approach with anti-cheat in mind, it’s no longer adequate.
I think for multiplayer game, there are a couple things are in current “trend”:
server offload simulation, basically the dedicated server off load the physics to a bunch of cloud nodes that only does the physics sim, take the result and ask the client to sync up. It’s not really “new” just that the implementation would get better. Search StarCitizen’s server meshing shown recently. This can scale up really big sims but the network bandwidth required would be prohibitive, cause it not only scale with the players also the physics bodies needs to be updated. (so yeah, always trade offs. )
fixed time delta physics engine on server, like Rocket League mentioned. This works fine with limited amount of physics body and are really stable, but you can’t do large scale sim with fixed time delta physics engine. (the more physics bodies, the slower it is to update the sim result.) Also this type of sim is has really limited range in space cause floating point error if physics body go really far from origin. But on the other hand it’s much more reliable, predictable and easier to do input buffer so it’s really responsive if you only need to handle limited amount of physics bodies.
async/multithread physic engine, it can still be deterministic if the inputs are the same(see JoltPhysics as example), it can scale up to large amount of physics bodies since most would be in “sleep” state once they are stabilized. very “mature” in single player game, but for multiplayer you still need to wrangle the “sync” up part. Less expensive to update compare to first one, supports more physics bodies than 2nd one, but nothing is free so you need good server(no offload) and your game framework needs to be able to support it.(what ChaosPhysics is working on). It would cost “less” to host compare to first, but significantly higher than 2nd. (well, if someone use fix time delta to sim large amount of physics bodies, then their server will cost way more than async, but no one would do that anyway. ) Example game would be like The Finals that was doing beta recently from what I can see in the gameplay videos. (they have mixed cosmetic, running only on clients, physics and server synced physics. )