I would like to use destructibles as a part of a multiplayer game and affect its gameplay. But as it currently stands destructible chunks do not replicate their location nor state of the mesh still undestroyed: if I apply damage to the destructible mesh the extent of the damage varies from client to client. As in a hole in a wall can be either bigger or smaller on different clients, this makes the game unfair.
To go even further it would be really, really nice to replicate the location of higher level chunks and structures made up of them, as in if a player destroys a bottom of a pillar making a bridge this would happen on all clients.
The only way to implement this would be via c++? Is this even on Epics roadmap in the future or of interest?
There have been tests with networking replication of destructibles, but the only one with proper chunk location and structure of the still unbroken mesh seems to be using different actors to form the destructible in the first place making it unusable for larger structures and very cumbersome to implement.
Syncing state over the network is hard. Latency is always an issue.
Automatically syncing the position, rotation, and velocity of numerous physics objects is difficult.
Your best approach may be to treat anything that affects gameplay as a full fledged actor and replicate its state.
Each of these actors can be destroyed independently on each client, as long as the game play affect is just whether or not the actor is destroyed.
e.g. consider a bridge. you can replicate the destroyed state across all clients, and let them do their own fragmentation. This works as long as all clients either have the bridge or not.
If possible, do not design around having individual fragments affect gameplay. That path is very difficult.
Physics and network for anything else than cosmitic stuff is currently pretty unusable. For either destructable meshes or normal meshes with simulated physics.
For example a cube with simulated phycis could land 50m away from the same version of the cube on the server. If collision is on and the client runs to the location where the cube is on the server he would find an invisible cube that is blocking him because the real location of the mesh is not replicated and (even worse) he could jump on it and would be teleported by the engine to his own version of the cube (even if it is 50m away) until he jumps down from his client-cube and is back again (50m away) to the location where he found that scary invisible server version of his cube.
If you do the same with destructable meshes you get similar results but usually you don’t teleport on top of the debris parts but do some “endless jump” (floating above some invisible wall debris) on the client side while you stand already on the wall debris on the server side that is located by physics somewhere different. If you attach some projetile to those “ghost” wall parts (e.g. a sticky snowball) then it’s again like with the normal simulated physics cube … the projectile would be “teleported” to your version of the debris. For example if you fire on the invisible broken wall part that is already down on the ground on the server-side and still standing upwards on your client-version by “phyics luck” then the projectile would be sucked in at the (invisible) location where the debris part is on the server and would be teleported to the same debris part that is somewhere completely different on the client side (even if that debris part is still standing upwards or yet again 50m away from the same part on the server).
Spawned on break for gameplay relevant items in a multiplayer game might be too slow and/or have to simultate physics yet again if it should reproduce the behaviour of a destructable mesh. But in that case it’s yet again the same issue with very unsync locations caused by usync physic (showed below). In my opinion “simulate phsyics” and every similar behavior (like it could be caused by destructable meshes) is currently just a trap in multiplayer games and should be disabled by the engine as it breaks the game (or opens huge leaks for cheating).
It’s very easy to reproduce the current issue with physics in multiplayer games:
Create a third person template. Add a cube into the map. Select the cube and switch to “simulate phyics”. -> Desaster is done.
Start a client and a listening server player jump a bit around (and on the cube) and you would get results that are totally crazy (unusbable in a multiplayer games). So everything that is just a bit gameplay relevant have to be binary: 1 (blocking everything in the state where it is not destructed) and 0 (non blocling and absolutely non gameplay relevant anymore after it fractures just a bit) like a character that got killed and uses phycis only for ragdoll anymore. This is ok for a window that is only blocking 100% at start or is broken (and blocking 0%) if somebody shot it. All those droping glass parts have to be absolutely non-gameplay relevant anymore until it fractures. You could still create complex objects like a bridge but you have to split it up into parts of many destructable meshes and change the collision settings to “phycis only” after fracture -> 0 or 1 (solid and gameplay relevant or fractured and only costmetic anymore). You could still get some broken bridge, window or whatever parts that could be pushed by phyics around that way (but at the point where physcis may count gameplay may not count).
