How we solved an infamous sliding bug

Problem: Lag + collision detection = characters slide. Solution: Turn off collision detection.<p>I was sincerely hoping for an actual technical solution for dealing with peer-to-peer networking and lag. I feel somewhat cheated out of the time it took me to read that article. While it did explain the problem very nicely, the solution was to just disable the feature outright.

How do you stop clients from cheating in a peer-to-peer game like Awesomenauts?

This is the first time (as a non game-dev) I&#x27;m reading about a P2P game where each peer computes only part of the world. That&#x27;s quite clever, especially for an indie developer who&#x27;d be hurt more by spending lots of money on server resources. It should be possible to build quite massive multiplayer worlds this way. Has this ever been attempted, say, in a WoW or Eve type game? I imagine that for massive battles, each peer could serve as a proxy for all the data it has received already, such that only one connection to another peer is needed to see the whole thing - similar to how bit torrent works. Lag could become a larger problem there of course, so it probably only lends itself to a slower paced gameplay where players don&#x27;t target each other using a visor - but it should work for a WoW style combat system, no?

It seems like this solution implicitly acknowledges (and fails to resolve) the fact that their game has frequent, pervasive desyncs. The bug being described is <i>only</i> possible when in a state of persistent desync - that&#x27;s a little scary in a competitive or semi-competitive game (like most games in the &#x27;MOBA&#x27; genre are, including Awesomenauts).<p>I wonder what their reasons were for going with peer-to-peer instead of anointing a player as the &#x27;server&#x27; as many other console multiplayer games do (Awesomenauts started out on console, IIRC)? That would solve a lot of these desync problems because the server would be responsible for resolving all the collisions.

Would it work to have a different response to collision, namely to apply a reverse of your last step? (A full reverse or partial).<p>There might still be corner cases, but it would seem to resolve the described issue, since irrespective of where you think the other player is, if you both reverse your motion you should disengage.<p>I can see 3-body problems being more problematic, but that&#x27;s probably also the case with the original code.

How does the player with the lower objectID detect that the sliding bug is happening? The way it was described, only the player with the higher objectID would be able to figure that out. Did they change it so both players sends the message? Or does the player with the higher objectID simply send a message when they detect the bug, meaning they turn off their collision first? Or something else entirely?

Could you resolve the issue by introducing an element of stochasticity into the distance players are displaced to avoid collisions?<p>That way, one player would move right (or left) more than the other player and the collision would still resolve itself.