There’s a number of approaches. One approach is that you need to make your local simulation deterministic so that every client can do their own work and simply agree that they’re on the same page. You then send events, not state, in turns.

Saving state in a hashable structure can make it easy to check if all clients agree.

Decoupling the local sim from the multiplayer events can make the game feel smooth, even if at times there’s rubber banding.

This is such a good read: https://www.gamedeveloper.com/programming/1500-archers-on-a-...

I think my backend and overall strategy are good, sending events rather than state, deterministic simulation, event buffering, client prediction, etc, ultimately my issues arise on the client side when using these frameworks, I haven't found one that considers how a game server operates, so it ends up requiring a good deal of hacking to inject server messages into the game state at the right places, and ultimately the math is always a little bit off, rounding issues add up, rubber banding appears, etc. I guess I could write my own engine from the ground up with a backend in mind, but I don't have the free time to make the engine and the client and the server and the actual game, so I was hoping that maybe Melon2 would have considered my use case.

Also, a piece of advice I once heard that resonated with me: you either make a game engine or a game. Never both.

There are race conditions all over and I'd imagine you'd need to have a hash of current and next positions to prevent conflicts.

In this situation you can stream movement waypoints from remote clients and lerp between those waypoints locally to simulate movement. If latency is low enough you can make predictions about the next waypoint and it won't look bad when you're wrong.

If you're PvE, you're done. Nobody needs to know precisely where their teammate is as long as the game feels fair. (The AI players on the other side won't complain.)

In PvP the opponent will complain, and they're also a customer, so you have to do something about it. This is an entire technical discipline within gamedev if you want both accuracy and player freedom.

Don't be afraid to let technical constraints guide your design. If you don't want to spend your life building remote physics validation or latency-aware consensus algorithms, make your players interact with the world via clicking so you always know exactly where they wanna go next. One of the super powers of being a programmer + designer combo is making trades across disciplines to maximize your output.

The biggest source of these inconsistencies is Math.sqrt(). You need to implement deterministic version of sqrt() and that should fix 99% of your issues. Hit me up if you need some additional pointers.

I'm using this sqrt implementation (found it long time ago on some old action script blog, this link is not the original source). It's plenty fast, accurate and fully deterministic. I successfully implemented it in my multiplayer gta2 clone in javascript.

I've been building a MOBA, using Photon Engine for the networking. It's a framework that handles everything you just described, using different paradigms depending on your preference.

The one I'm using, called "Photon Fusion", runs the entire game on the server to replicate all the game logic and physics that the client side has, as you described. However, it takes care of desync issues by using some clever interpolation and client side prediction with tick-based simulation, while keeping the server as the state authority with extremely optimized compression of communication to support lower bandwidth.

https://www.photonengine.com/en-US/Fusion

https://www.amazon.com/Multiplayer-Game-Programming-Architec...

I only have experience with 2d (so it might not be useful to you, but perhaps will others), where typically it's a worse experience for the player to have CSP (client side prediction) at-least in a fast paced game, as for example a player behind a wall can more clearly see something missed them, yet they still got hit.

The way I do things (and I've seen is common across other "io" games), is "CSP" only for particular actions (such as your own rotation, or swinging your own weapon), but otherwise just let the client move in step with the server in terms of any physics entities etc.

It's using phaser on the server in this instance (which I recently ripped out, and moved to just using matter)

It's pretty ugly code, but the foundations are there, maybe it's a starting point or of some use!

By the sounds of things you’re sending positions updates and broadcasting them from the server. If that’s the case some bog standard interpolation should just work. If you’re seeing divergence then you’re probably running code with a non-deterministic result on the different machines. Typically speaking you want to work out who ‘owns’ each part of the simulation and make sure anything you do elsewhere converges back to that.

I went through most of these issues and solved them.

For my case it was simple to reimplement the physics server side as there were no fancy physics. Just simple collisions. There is no alternative if you want to avoid cheaters.

If you have an entity's position and speed at a given time, you can then calculate the position going forward. A misstep here is assuming that your client's game speed in pixels is consistent. You may need to normalize the entity's speed based upon the client's frame rate. Do this for both displaying entities and reporting the player's movement to the server.

Hop on the Melon.js Discord if you have specific questions.