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?
Client <-> Server communication
Moderator: Transport Empire Moderators
- uzurpator
- Transport Empire Moderator
- Posts: 2178
- Joined: 10 Jan 2003 12:21
- Location: Katowice, Poland
Client <-> Server communication
All art and vehicle stats I authored for TT and derivatives are as of now PUBLIC DOMAIN! Use as you see fit
Just say NO to the TT fan-art sprite licensing madness. Public domain your art as well.
Just say NO to the TT fan-art sprite licensing madness. Public domain your art as well.
-
- Engineer
- Posts: 32
- Joined: 12 Jul 2005 08:14
- Location: Melbourne suburbs, Victoria, Australia (GMT+10)
Re: Client <-> Server communication
I think it >= good. But as you say, we need to cluster the data such that it doesn't eat memory like... well... something that eats a lot of memory in a very short time... That is really the only issue, except perhaps the memory used by 'FULL,' which can perhaps be solved by swapping to/from the HDD.uzurpator wrote: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?
William.
For static data (like terrain)
can't we use an event-based system?
Like:
"event 487 : vertex 56,70 new height : 298" ?
Ofcourse we need to make sure everything is ok on all clients, so we could calculate a checksum over that data and compare those.
However, I don't know how time-consuming such a checksum-calculating would be.
can't we use an event-based system?
Like:
"event 487 : vertex 56,70 new height : 298" ?
Ofcourse we need to make sure everything is ok on all clients, so we could calculate a checksum over that data and compare those.
However, I don't know how time-consuming such a checksum-calculating would be.
On holiday from 16/07 till 31/07
Who is online
Users browsing this forum: No registered users and 4 guests