After the last devlog I had the basic controls for scrolling and zooming a larger level. Mostly for a laugh, I threw in 1000 units and set up a huge battle. Tha...
So when you join, the server sends the full state and from there it's only delta updates.
The way I see it, the actual implementation would be pretty close to the way git works when handling text file contents. But then just like git, you can run into merge conflicts but in practice these would be the same ones as a regular implementation.
I think the big problem is delta updates don't send a position, so over time errors would accumulate and everything would drift too far from where it's meant to be. Sending the full updates over 2 seconds uses a tiny amount of bandwidth and means errors only accumulate for up to 2 seconds.
but thinking in vectors, why don't just update destinations on delta? so basically
if CurrentDestination != FinalDestination != StartingPoint then delta FinalDestination, so they will move in a predictable way only if the destination is not the starting point (they reached destination) or have a different target to move to.
That's the case for your implementation, and I suppose that in a game where everything either moves in a straight line or does not move at all, I guess that makes sense.
In a more general context, I can't see why just sending the position as well with the delta updates would cause any issue.
I don't know how the MP plugin works, but since pretty much everything in Construct can save and load from JSON, I can definitely see how it would be doable to implement this as a general purpose layout synchronisation technique. Unless the performance hit from saving/loading JSONs in substantial that is. But in real case scenarios you'd only tag the objects you want to synchronise and that should work fine.
If you send positions with deltas, then do you send deltas when the position changes? If so it's near enough reinventing full updates, which use too much bandwidth for this project. If not then there's probably still going to be drift away from the true position, so you'd need something like full updates to occasionally correct it.
The bandwidth requirements for this project are pretty serious too - sending any data that is not strictly necessary could push the bandwidth over the 100 KiB/s goal.
Hmm yeah I guess that's true for the project you're making. That's interesting to think about!