Can I use (Physics) Revolute Joints with Multiplayer?

Hey everyone,

we're working on implementing online multiplayer into our 2-player arena duel game.

We have hit a wall and can't continue due to an unresolved issue:

We're tying two physics objects together to form the player - we're doing this via the "create revolute joint" action. On the host, everything works fine. On the peer, however, Local Input Prediction seems to cause problems.

LIP seems to override the calculations in regards to the revolute joint. If we disable LIP everything works fine on the peer but the perceived latency is unacceptable.

We know this is a very specific issue so we would be thrilled if someone could enlighten us on this issue ( Ashley ? ).

I would be really thankful if someone could comment on this. We can't continue working until this is solved.

Local input prediction won't work unless the player's inputs directly control the object and are also run by the host, as described in multiplayer tutorial 3. If the physics behavior is just simulating by itself without using player input, then it is inappropriate to use local input simulation.

For just syncing objects in general, it should not matter what behaviors you use. Simply run everything on the host, then on the peers disable all the behaviors and sync object will move them like they appear on the host.

Another guy from the game here!

Local input prediction won't work unless the player's inputs directly control the object and are also run by the host, as described in multiplayer tutorial 3.

This is what we did. We connect 2 physics objects via the revolute joint and the players control the whole construction ('the player object') by applying forces to both objects at the same time (see picture below).

[attachment=1:2emu1fwi][/attachment:2emu1fwi]

The problem is, that the joint does not seem to work properly on the peer side. The physics objects don't keep their distance as soon as the peer starts to input something and the forces are applied (see picture below). On the host everything is correct of course.

[attachment=0:2emu1fwi][/attachment:2emu1fwi]

For just syncing objects in general, it should not matter what behaviors you use. Simply run everything on the host, then on the peers disable all the behaviors and sync object will move them like they appear on the host.

We tried this for testing purposes and it worked perfectly fine, as expected. But this is not the solution since the peers need direct feedback on their inputs.

Our question here is:

Is this a bug with multiplayer/local input prediction? (My guess is that the forces are applied correctly in regards of the joint but then overwritten by the local input prediction which is just ignoring the constraints).

Or is it just not possible to control connected physics objects on the host and the peers with local input prediction?

Maybe we just did something fundamentally wrong but we tried everything imaginable and don't seem to be able to solve it ourselves.

If you need a .capx, I can create one for you of course, when I got some spare time. But I hope the images and descriptions are clear enough now. Feel free to PM me or just answer right here.

Ashley: Thank you so much in advance and for making all this possible in this wonderful program of yours!

We keep recommending Construct to our friends and fellows!

Physics is a bit of a special case since trying to move a Physics object with 'set position' or 'set angle' counts as teleporting the object in the physics world which is obviously unrealistic and can lead to weird results. The multiplayer object internally will be doing 'set position' and 'set angle' so it might just be that they just won't work well together. You might just have to disable LIP and live with the input latency.

Ashley beat me to a reply... again

As a rule of guide most games don't do object syncing for networking. They work by instructions which is the more common way for non player entities. You best bet is to use a controller that gives physics objects instructions. however I would be concered with latency and Fixed Time step. You may need to tinker with a network timestep. This would be modifying the two main physics simulation values on certain perodical increments.

The other method is to do Ashley suggestion. Where Physics are controller on one computer and the position state are then mimiced to the others.

In Roblox which is amazing engineering for network physics. Roblox uses a model where the nearest player to objects has authority of the physics and handles the simulation. They send the results to other players who then follow suit of the simulation. Then the simulation is updated by the authority every x period of time and updates the others who are not the authority. This model however will require you develop spacial tree's of objects.

Thank you very much for your response! This is a bit of a bummer but at least we now know that we can't really do anything on our side. We will now try using another kind of input method.

My gut feeling with Multiplayer +Physics is to have the whole simulation happening only on the host computer. So the host would be the only one with the "physics behaviors" applied, while for the peers you have the same objects without the physics behavior so that u can do set position and set angle based on the positions and angles of the objects on the host computer.

So in a way you're trying to create a pantomime on the peers computer that looks just like what's happening on the hosts side. You don't have to have revolute joints on the peers side becos if the peers objects get their positions and angles from the host then it will all look and work the same anyways.

Any inputs get sent to the host and calculated on the host's side.

I dunno, am I talking crap or is this the way you guys would do it?

EddyDingDongs resume sounds pretty good. Did anybody have any success on this (multiplayer + physics) topic?