>
> Please note that you will require lag compensation (rewinding time) if you try to create a real-time shooter or something similiar.
> https://www.scirra.com/tutorials/892/mu ... pts/page-8
>
> Ashley covered that already in his tutorial.
>
>
I had implemented this, and other user's suggestions on how to work around it using functions.
Bullets were easy to sync; one set of instructions were synced to all players. But because each player's platform position was inconsistent on each machine, none of that mattered.
The big problem was that the player's position was never the same. Especially when jumping. There was a discussion about this some time ago.
Disclaimer: I've never actually completed any multiplayer projects myself, so please excuse me if I'm missing something specific to your situation or saying something that was obvious to you already. My hope is to possibly give you an approach or idea that you might not have thought of to try.
Position will always be inconsistent/different on every peer due to the limitations of latency, there is pretty much no way around this. The only thing you can do is fudge it with lag compensation and input prediction. All multiplayer engines need to deal with this in one way or another.
One method that looked decent for me was to have all "real" (read: host synced) sprites invisible (top down projectile shooter). Every visible sprite object (on each peer's device) was tied to the invisible master one, but by doing it this way I could set up my own rules for how the object looked and behaved (interpolation and input prediction) from each peer's point of view. Then I could make any small tweaks I needed to hide the latency factor. On the host side for lag compensation, I allowed small "burst movement" after an input is received to catch up to the peer's local input prediction position. Because the host version was invisible, it didn't look unnatural to the player. On the peer side, I also added a tiny bit of consistent, simulated input delay rather than instant local input predicted feedback, so the discrepancy between host and peer didn't get too far apart.
Most of that is done by the built in actions in the plugin, but those don't allow for much fine tuning, which is why I ended up trying to make my own.