The reason is that the peer creates it`s own player object then calls the "Sync_SpawnPlayer" function which tells the host to spawn a new player and then signal the peers to spawn all player objects. So the host tells the peer to create a player for itself but it already has one.
This will happen again and again as more peers connect. The simple fix is in the "SpawnPlayer" function, it just needs a test to see if a player object with the requested peerid already exists, which can be achieved using an event for the PlayerObject.PeerID = peerid (as above) and then adding an Else (IE didn`t find one).
While I am here just wanted to add my thanks to troublesum for this lovely bit of code, it took me a while to get my head around (I eventually took to carefully re-writing it, event by event, in my game, just so I could get a clear understanding of it).
"PlayerObject.PeerID = peerid (as above)" don't work. It's work only once. Please help me
You need to use a counter inside the function, you can use a global variable, and everytime the functions is executed you can add 1 point to the global variable, so you can add a filter: system counter = 2 (empty) and a ELSE with the function
Is working fine for me with this counter.
Develop games in your browser. Powerful, performant & highly capable.
I'm straight to the point. Has anyone managed to solve this problem and adapted for mobile devices. In other words find an optimized solution. And I hope that someone will appear.
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.
Still great to see another aproach though.
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
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.