The problem with your code is, that it's not really well synced.It's always pretty off and then resyncs the position, so you see other players warping/bugging around like crazy.

You notice that already when normally moving, but it becomes much worse if the players is hitting multiple directions at the same time, like jumping to the right and mid air to start pressing left while still pressing right.So other players will see you still moving to the right until it's synced which then warps you a long way to the left.

Or by pressing left and right at the same time, the peer starts twitching.

That's far from perfect, the official behaviour with InputPrediction works way better for me.The only positive thing i've noticed as slight improvements on the latency.

@troublesum - just skimming through the comments here... this looks like a great proof of concept, man. thanks so much. doesn't seem like any of the described problems will be too big of a deal if you know your way around construct. this is about how I figured things could sync up a bit better.

I'm curious to hear how you've applied this to any personal projects - got anything in the works right now?

I'm surprised that nobody with actual Multiplayer experience has commented on this.

The multiplayer functionality in Construct 2 is perfect. It's some of the best multiplayer programming you'll find and uses all modern multiplayer coding methods.

The solution to your problems ISN'T in not using Scirra's multiplayer examples as a starting point. Look at them, learn proper input prediction.

[*]Use Construct 2's interpolation[*]Use subtle extrapolation, through peer states (stored within byte values)[*]Slow it down, allow the host and peer time to make sure they're synced up before important events[*]When sending data back and forth, don't use strings in the middle of gameplay. Use bytes, or byte sized values. Not sure if it's Construct 2, Javascript, or the underlying C code, but any whole number within 256 is already equal to the byte equivalent.Remember that, because you'll be able to use that to your advantage often.[*]Run cell checking for player characters. Basically, what I mean by this is divide your layout into 256 evenly sized sections, or cells, and sync the player's current cell position to the host. Having both values, the host can interpolate (slightly), pulling the player closer to that cell's position. This will make up for some of the positioning latency, even if just a little.[*]OPTIMIZE! Not just your multiplayer programming, but everything else to. Once one peer suffers from poor performance, so does everyone else.[*]Round synced positions.