   [Python] Network player movement in a 2D game...
  Yo!I'm currently writing a small real-time multiplayer game in Python with pygame.I don't really need to tell exactly how the whole game are going to work, but the main thing is to be able to move balls around the screen and each ball represents a user, pretty simple.And before you read my whole post, I can tell you that my problem is described at the bottom of this post, so read that first and see if you recognize it. And I decided to exaplin how the game works as well:Let me tell you briefly how it works.The mainloop of the client look like this:* Check for user inputs (keypress)* Checks for messages from the server, on a non-blocking socket (using select).* Updates every players position and blits everything to the screenWhen a player wants to move, lets say he press the DOWN-ARROW, a message to the server is sent which looks like "1|17,17|0,1"."1" is the playerid, "17,17" are the coordinates on the screen and "1,0" is the velocity, just a vector.The server then takes this message and sends it to every clients connected, nothing else.Now on the client, every ball has got their own instance of the Player()-class, which contains thow methods: set_direction() and move_player().When a message arrives, the client calls the set_direction() method on the correct player-instance and gives it three arguments, position "17,17" and velocity "0,1". Now set_direction() updates a private velocity- and position-variable, and sets the position of the ball, to the given position.And now that that is done, we move on to the move_player() method:It takes one argument, dt, which is deltaTime for each frame.Now it calculates in which way the ball is moving, so if the velocity is "0,1" it would be traveling down, if it was "0,-1" it would be traveling up on the screen, you get it?So basicly, it take deltaTime * 100(which is pixels/s) * velocity , and this gives it a new position to travel to.You see, this move_player() is called once every time in the loop so it updates the ball to go 100 pixels / second on the screen... I think you are familiar to this!And then when a player releases his key, the server gets a message with "0,0" as velocity, which will stop the ball from going anywhere.So what Im saying is, that I'm not spamming my server with packages which contains´the position for the ball, and then moves it like 1 px ahead and then the client updates. Instead I tell the clients in which way the ball is moving and it updates it every frame until it gets the "stop message".I should also say that the client that moves, doesn't wait for the server to reply and give it it's direction and so. The client that moves is moving collateraly with the server with other words.So what's my problem anyway?When a player moves or stops, the ball kind of "jumps" to its corrected position, as if it were out of sync or something. And I don't understand why it do this, I've been tryign to solve it for days but can't find the problem!So therefore I ask you guys (or girls if there are any, lol), for help! :)[Edited by - pjuke on May 8, 2009 8:24:21 AM]
  Sending information takes time, and that time is not constant.Problem 1: "I should also say that the client that moves, doesn't wait for the server to reply and give it it's direction and so. The client that moves is moving collateraly with the server with other words." Actually, the client is moving before the server, because movement has begun while the information hasn't even reached the server yet, never mind been processed and sent back. So if the server sends back notification that the client has started moving, the client has already travelled some distance at that point. If it snaps back at that point in order to obey the server's command, that will be very noticeable.Problem 2: If the client sent the start and the stop 10 seconds apart, and the server received them 11 seconds apart due to latency variations, then the object will have overshot by 10%. This problem is doubled in magnitude when you have to broadcast the information back out again to other clients. Each client could have moved an object a different amount if it moves purely based on time.Probably the simplest solution to this is to send updates more often, so that the error is split up into smaller and less noticeable chunks.To improve on that, you can perform gradual blending between the previously predicted position and the corrected predicted position so that instead of discrete jumps at each point of correction, you get a smoother change of velocity to perform the same compensation.   ;Quote:Original post by KylotanProbably the simplest solution to this is to send updates more often, so that the error is split up into smaller and less noticeable chunks.To improve on that, you can perform gradual blending between the previously predicted position and the corrected predicted position so that instead of discrete jumps at each point of correction, you get a smoother change of velocity to perform the same compensation.Thank you man for that!I'll test it out right away and see what happends!And while I'm still writing, I might ask another issue I've been thinking about:How do to the collition detection?Should it just be client-side and then be broadcasted to all other clients?This requires a lagfree environment right? Because if one ball is 30 px ahead compared to the other, it will announce a collition - while it's not colliding on the other side... or am I just talking? ;  Typically the server handles collision detection. It is already authoritative for user position so it should handle this as well.  As an example of why this is so think about the case where the player generates a collision then receives an update saying that it is somewhere else and this invalidates the collision that it just reported, or it missed the collision because it received a position update and jumped through the collision area.   ;Quote:Original post by pjukeAnd while I'm still writing, I might ask another issue I've been thinking about:How do to the collition detection?Just a few posts down....Quote:This requires a lagfree environment right?Lag free environment violates laws of physics. At very best, you can hope for low latency. Recent post. Search for more, there are plenty discussing the topic.   ;  Never mind, I got it working perfect now! :)[Edited by - pjuke on May 9, 2009 1:36:45 PM]