Transport Tycoon Forums

The place to talk about Transport Tycoon
It is currently Tue Dec 12, 2017 6:16 am

All times are UTC




Post new topic  Reply to topic  [ 3 posts ] 
Author Message
PostPosted: Thu Sep 29, 2005 7:45 pm 
Offline
Transport Empire Moderator
Transport Empire Moderator
User avatar

Joined: Fri Jan 10, 2003 12:21 pm
Posts: 2125
Location: Wroclaw, Poland / Katowice, Poland
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.


Top
   
PostPosted: Fri Sep 30, 2005 12:10 pm 
Offline
Engineer
Engineer

Joined: Tue Jul 12, 2005 8:14 am
Posts: 32
Location: Melbourne suburbs, Victoria, Australia (GMT+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.


Top
   
 Post subject:
PostPosted: Wed Oct 26, 2005 4:06 pm 
Offline
Route Supervisor
Route Supervisor
User avatar

Joined: Tue Mar 09, 2004 8:30 pm
Posts: 429
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


Top
   
Display posts from previous:  Sort by  
Post new topic  Reply to topic  [ 3 posts ] 

All times are UTC


Who is online

Users browsing this forum: No registered users and 2 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000-2017 phpBB Limited

Copyright © Owen Rudge/The Transport Tycoon Forums 2001-2017.
Hosted by Zernebok Hosting.