Lately I've been working on an implementation of client movement prediction and lag management. This is important because when a player movement is sent to the server, by the time the server receives the movement update that movement is already out of date - the player that sent the movement update may have already moved beyond that position it sent to the server. Beyond that, when the server broadcasts a players movement to all other players in the area then by the time other players receive the position of another players moving around them, it is several frames if not a lot more frames behind where the player actually is. Given that I've set our server to send movement updates at a rate of 15 updates per second (option to adjust will be available, use at your own risk) and yet the game might be running at 60+ frames per second, obviously this will lead to gaps between movements. If we leave it as is, players will jump from point to point and the result is very unsmooth gameplay. Now, how to deal with this? We can overcome this problem with predicting where the player may be moving. This is how the majority of online MMO's deal with this sort of problem. With the data received we can interpolate the players position based on velocity to make a best guess at where the player may be. Based on the velocity of the player in combination with knowing the approximate latency to account for transfer time from Player A -> Server -> Player B, we use the data to calculate the players current position. So with this in mind, we now know approximately where the player may be even if the data we receive is out of date. Now that we have the general idea of how to overcome where the player may be at a given time, how can we smoothly move that player from one point to the next with gaps in the middle? Remember, this is all happening on another players computer - We could simply do a straight line and that might be good enough in some instances but if there is a big gap in between position updates or if a player in a shuttle makes a sharp turn then it could lead to warping and unrealistic movement on other players screens. To overcome this we can use cubic spines, a form of dead reckoning. With the cubic splines algebraic equation we can input a series of positions from start to end to formulate a smooth rounded transition from point a to point b. In this graph you can see how using cubic splines can smooth the transition between points. Notice the red line versus the black cubic spline rendering in the graph below, the red points are points received and with cubic spline we calculate a smooth transition from each point rather than a hard straight line. Imagine this is a space shuttle flying through the Stardale universe, it would look a lot better if the shuttle followed the black line rather than red. This method is one of several methods used to smooth out predicted player movements, however, it is one that Stardale will be using. I've been testing it out and so far it seems promising. At this point I am dealing with a few jitter problems still after implementing cubic splines, nonetheless I know where the problem is and I am just working out a few kinks in my implementation of cubic splines. I've never worked with this before so it is my first time working out movement prediction. Nonetheless I'm proud we've made it this far and I am happy with the results. Anyway, that's all for this post. I hope everyone is doing well! Welcome to the new faces who recently registered and thanks to everyone again who keep coming back for updates and following our progress. You guys are amazing.