Client <-> Server communication

Discussions related to programming Transport Empire.

Moderator: Transport Empire Moderators

Post Reply
User avatar
uzurpator
Transport Empire Moderator
Transport Empire Moderator
Posts: 2134
Joined: 10 Jan 2003 12:21
Location: Wroclaw, Poland / Katowice, Poland

Client <-> Server communication

Post by uzurpator » 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?
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.

fujitsu
Engineer
Engineer
Posts: 32
Joined: 12 Jul 2005 08:14
Location: Melbourne suburbs, Victoria, Australia (GMT+10)

Re: Client <-> Server communication

Post by fujitsu » 30 Sep 2005 12:10

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?
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.

William.

User avatar
PJayTycy
Route Supervisor
Route Supervisor
Posts: 429
Joined: 09 Mar 2004 20:30

Post by PJayTycy » 26 Oct 2005 16:06

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.
On holiday from 16/07 till 31/07

Post Reply

Return to “Transport Empire Coding”

Who is online

Users browsing this forum: No registered users and 2 guests