Client <-> Server communication
Posted: 29 Sep 2005 19:45
The client and server obviously need to communicate. So we need to develop a protocol that will ensure low bandwidith usage and smooth gameplay.
I propose something like this:
Data is divided in three classes
- static - data that is very seldom changed - like terrain information
- dynamic - data that changes from frame to frame - like vehicle positions
- periodic - data that is changed regularly every X frames - like vehicle brakedowns (eg - we check for brakedowns every X frames) or economy changes.
Now - create an 8 byte frame counter, on each frame we increase it.
Each example of static data contains an 8 byte field showing when this data was last changed (frame number). Also it contains a field showing when each of the clients last accesed this data.
If last access > last change - the server will send "you have up to date" response. If last access <= last change the server will send the data.
Obviously we need to clauster the data in question as keeping the counter for each - say - map vertex - will eat memory like donuts.
For periodic data the client will ask for it when it is in its viewport and the "change" time has come. (for some info - when change period is long enough - we can treat this a static data)
The dynamic data will require an update on each snapshot for each of the clients.
There will be two modes for the client:
FULL - the client will slowly build a copy of server data in its own memory space. This will cut the requirements for bandwidth (potentially - when the client is hopping left and right - quite notably), but increase memory needs.
CACHE - the client will keep a cache of X last accessed objects and request always up-to-date information. This is mode for the LAN games, LOCALHOST games and places where there are memory constraints, but no bandwidth constraints.
Waddya think?
I propose something like this:
Data is divided in three classes
- static - data that is very seldom changed - like terrain information
- dynamic - data that changes from frame to frame - like vehicle positions
- periodic - data that is changed regularly every X frames - like vehicle brakedowns (eg - we check for brakedowns every X frames) or economy changes.
Now - create an 8 byte frame counter, on each frame we increase it.
Each example of static data contains an 8 byte field showing when this data was last changed (frame number). Also it contains a field showing when each of the clients last accesed this data.
If last access > last change - the server will send "you have up to date" response. If last access <= last change the server will send the data.
Obviously we need to clauster the data in question as keeping the counter for each - say - map vertex - will eat memory like donuts.
For periodic data the client will ask for it when it is in its viewport and the "change" time has come. (for some info - when change period is long enough - we can treat this a static data)
The dynamic data will require an update on each snapshot for each of the clients.
There will be two modes for the client:
FULL - the client will slowly build a copy of server data in its own memory space. This will cut the requirements for bandwidth (potentially - when the client is hopping left and right - quite notably), but increase memory needs.
CACHE - the client will keep a cache of X last accessed objects and request always up-to-date information. This is mode for the LAN games, LOCALHOST games and places where there are memory constraints, but no bandwidth constraints.
Waddya think?