Meeting Summary

Date: 14th Mar 2000
Time: 2:58pm GMT
Channel: #cyphesis
Co-ordinator: N/A
Present: Sal & Aloril
Log Text

_Different Approaches to handling Client<->Server Movement Updates_

Sal got Xclient communicating with Cyphesis and there was much rejoicing but movement communication between Cyphesis and Xclient wasn't working because it was found that Cyphesis and Xclient handle movement differently. Cyphesis currently expects from the client for movement to be in the form of:

Client -> Server: I am at point A and I'm moving to point B using X velocity.

Xclient transmits movement in the form of:

Client -> Server: I am at point A using X velocity moving in Z direction - I'll let you know about my position at regular intervals

The discussion then wandered to optimizing Atlas from which a couple of things were agreed upon:

Atlas needs to be optimized to reduce network lag using custom binary layers and compression techniques.
Porting libAtlas from Python to C++ to increase libAtlas' for better network preformance for Cyphesis (Aloril is working on this now)

The discussion eventually came back to how server<->client movement should be handled. Sal & Aloril disagreed on the best way to handle client<->server movement communication and a large cat fight ensued. ;) They both discussed what form movement updates in Atlas should support. Here are their ideas for future implementation within Atlas regarding Client<->Server movement communication:

Alorils ideas about movement:

Clients should transmit movement information in the form of Im currently at A and Im now going to B using X velocity. AND/OR
Client only sends positional updates whenever velocity/direction change occurs. Client's current position is based upon server predictions in this method. This method would greatly minimize the amount of bandwidth that is needed for client<->server communications.

Sals ideas about movement (which are currently implemented in Xclient):

The client sends positional updates along with changes in velocity, heading etc. every so often to the server. This would allow for easier coding (less time to required tweaking prediction alogrithms) and more accurate player prediction because client position updates are given to the server periodically lessening the margin of error.

Both of them agreed that server code should have these features:

Server needs to do prediction of where the client is currently. This is needed bc once the server receives positional updates the information is already a little old bc of lag and other clients need the most up to date position information.
Having a very small (not noticable) amount of lag between the time from when the player pushes the move button to when the movement actually occurs on the screen is desirable. The moment the client pushes the move button however their movement will be transmitted across the server. This will help reduce the positional differences that the client and the server will have between them due to lag, therefore reducing the amount of estimation that the server will have to do (reducing margin for error).
Server prediction will be based upon the clients last know position, heading, velocity and the amount of lag between the server and the client.
The server will stop predicting (and stop the clients movement totally) if the server hasnt heard from the client in a while (i.e. client is lagging badly).
The server will ignore a request to move distances which are outside of the PC/NPC's physical ability. This helps cut down on cheating and is more protection against lag.

In the end they agreed to implement both of their ideas regarding movement in Cyphesis and Xclient and let testing/coders' preferences decide which method would be used.

The meeting then tapered off into general code wrangling & hacking trying to get xclient and cyphesis to talk to each other properly