How we solved an infamous sliding bug
joostdevblog.blogspot.nl
How we solved an infamous sliding bug
1–10 of 24 posts
Re: How we solved an infamous sliding bug
#2Re: How we solved an infamous sliding bug
#3I 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.
Re: How we solved an infamous sliding bug
#4Re: How we solved an infamous sliding bug
#5How do you stop clients from cheating in a peer-to-peer game like Awesomenauts?
Re: How we solved an infamous sliding bug
#6I wonder what their reasons were for going with peer-to-peer instead of anointing a player as the 'server' 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.
Re: How we solved an infamous sliding bug
#7Problem: Lag + collision detection = characters slide. Solution: Turn off collision detection. 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.
> The solution we finally managed to come up with is also a good example of how very incorrect workarounds can actually be a really good solution to a complex problem.
So you knew they were presenting a "very incorrect workaround"---which, counterintuitively, worked better than some of the more "correct" things they tried.
Re: How we solved an infamous sliding bug
#8How do you stop clients from cheating in a peer-to-peer game like Awesomenauts?
You probably can't. If stopping cheating is a goal you need to go for client-server were you host the servers yourself. A lot of developers are not prepared to take that on.
Every player uses a tick-engine (ie tick every 0.1s) that performs the same commands on the same ticks. When a player issues a command, such as "Build Unit X", it sends it to every other player to run a couple ticks ahead (how far ahead is based on average lag or whatever). If anyone performs differently, then a de-synchronization occurs and the game is over.
It's explained much better here http://www.gamasutra.com/view/feature/3094/1500_archers_on_a... "Because the game's outcome depended on all of the users executing exactly the same simulation, it was extremely difficult to hack a client (or client communication stream) and cheat. Any simulation that ran differently was tagged as "out of sync" and the game stopped. Cheating to reveal information locally was still possible, but these few leaks were relatively easy to secure in subsequent patches and revisions. Security was a huge win. "
Re: How we solved an infamous sliding bug
#9Problem: Lag + collision detection = characters slide. Solution: Turn off collision detection. 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.
Well, the first paragraph did say > The solution we finally managed to come up with is also a good example of how very incorrect workarounds can actually be a really good solution to a complex problem. So you knew they were presenting a "very incorrect workaround"---which, counterintuitively, worked better than some of the more "correct" things they tried.
It actually made it a bit more enticing, I was expecting a horrific chain of gotos or some other cliche programming paradigm being completely violated for the sake of pragmatism.
What we got instead was, "This is a hard problem, let's just not solve it." which was written up with a title of "How we solved a hard problem"
Re: How we solved an infamous sliding bug
#10Earlier quoted context omitted.
Well, the first paragraph did say > The solution we finally managed to come up with is also a good example of how very incorrect workarounds can actually be a really good solution to a complex problem. So you knew they were presenting a "very incorrect workaround"---which, counterintuitively, worked better than some of the more "correct" things they tried.
>So you knew they were presenting a "very incorrect workaround" It actually made it a bit more enticing, I was expecting a horrific chain of gotos or some other cliche programming paradigm being completely violated for the sake of pragmatism. What we got instead was, "This is a hard problem, let's just not solve it." which was written up with a title of "How we solved a hard problem"