Transport Tycoon Forums

The place to talk about Transport Tycoon
It is currently Tue Nov 21, 2017 3:26 pm

All times are UTC




Post new topic  Reply to topic  [ 5 posts ] 
Author Message
 Post subject: Backbone
PostPosted: Thu Oct 06, 2005 10:35 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
Ok - so we need to start the writing of the backbone of the game.

Obviously we need to start with a client-server architecture.

But what precisely do we need?

Server
Main loop
Time measurement
Constant frame speed (like - we go at 25 fps)
Sychronisation (client/server)
Communication (waiting for clients, establishing connection etc)

Client:
Main loop
Connection to the server
Sychronisation with the server
Some sort of time measurement

The problem we need to fix is the whole client server protocol

Esp the problem of _what happens when client is lagging/dropped off_ and _when server is lagging_ is to be solved.

_________________
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
   
 Post subject: Re: Backbone
PostPosted: Sat Oct 08, 2005 12:28 am 
Offline
Tycoon
Tycoon
User avatar

Joined: Fri Oct 03, 2003 11:59 pm
Posts: 1429
Location: Lancashire, UK
uzurpator wrote:
The problem we need to fix is the whole client server protocol

Esp the problem of _what happens when client is lagging/dropped off_ and _when server is lagging_ is to be solved.

I think the server lagging is much more serious than a client lagging.
Since all of the data processing is done at the server, a client lagging won't affect object movement, for example.
The only thing it will affect is that specific client (the player may place a piece of track, only to see someone else place in that spot before them, but in their view after them).

With regard to the backbone, I think it should be up to the client to determine the frame speed - I don't think the frame speed on one client would affect any other client.


Top
   
 Post subject:
PostPosted: Sat Oct 08, 2005 4:56 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
DominionSpy:

A frame here is one server 'tick' - eg the smallest amount of time to move the action. If we go for 25 fps then a frame is 40ms - eg we update the game each 40 ms. A client gets a snapshot - eg a state of the given area. The client does not need every frame - just enough to draw sensibl smooth animation.

As for the communication - I have an idea here (a bike ride can do wonders to you :) ) .

We go for completely asnychronous communication.

Basicly - we have network class (for client and server) which spins off a thread that constantly does keepalive (ping or somesuch) with a server / client.

The client will form a request, give it a number and give it to the network class. It sends it to the server.

Server recieves it via its own network class. This class puts the request in the request queue to be processed.

On each frame the server gets one request from each client and creates a 'reply' whitch is sent to the client.

The client network class recieves the reply and puts it in the 'reply' queue. The client will move if there are replies to be processed in the queue.

What is unique is the 'request/reply' ID. It is a number.

Basicly - The client processes reply #1700. Now it formulates what it needs to draw next frame - now numbered #1701. Then it sends it to the server.

The network classes will put recieved requests in the request queue if the request ID is higher then the ID of the last request on the queue, or there is a gap in the requests on the queue that fits the ID (eg requests 1699, 1700 and 1702 are there, but 1701 isn't)

The server creates a reply #1701 sent to the client to process.

Likewise on the client - incoming replies are sent to the reply queue (on the same terms as server requests are) - the client will process all pending replies, and then create requests etc.

This system is foolproff. If the server lags the clients will wait, If the client lags it will just have a queue (up to, say 5 replies) to process.

Also - client may send the request every X ms as long as the X is bigger then the server frame time (40 ms typically)

Also - if we make sure that there are always 2 replies in the reply queue then we can make very efficient animation interpolation - and then we can even send the replies ony 5 times/second and despite 200 ms lag the client will see as smooth animation as his machine allows.

_________________
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
   
 Post subject:
PostPosted: Mon Oct 24, 2005 10:06 am 
Offline
Tycoon
Tycoon
User avatar

Joined: Fri Oct 03, 2003 11:59 pm
Posts: 1429
Location: Lancashire, UK
I don't think we should prescribe a framerate on clients, or a tickrate on the server. I personally think that we should have the server updating its data as frequently as possible and let the clients dynamically choose whatever framerate they can sustain.

One thing I think should be controlled tightly is the frequency of communication between the server and clients. This is where the bottleneck will be in the program rather than the rendering or updating of data.

_________________
Image
You're saying I'm a Dominion spy, and don't even know it! - Dr. Bashir
That's the Joker in my avatar, not me. No wait it is me.


Top
   
 Post subject:
PostPosted: Tue Oct 25, 2005 9:21 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
I think we have an ambiguidity of terms.

Server frames - how many updates of the game world the server does per second. Usually 20-30 suffices. Depending on data size in question that is.

The server should run in constant fps - simply because it makes everything sooo much easier to synchronize. You have a nice time unit: 1 frame. If the server does not make it - the game will simply slow down.

The client frames is the speed of animation. Obviously it will not be constant. They key is to make the client demand data less or equally often as server updates it - otherwise the client will flood the server, or cause extra bandwidth load.

With constant server speed and variable client it is possible to make a server running at constant 30 fps and a client with raging 1-500 fps. Also it allows a neat bandwidth control by specifying how often the client should demand new data (it may be each 1 server frame, 1.5 server frame, etc).

As for communication. I am for two seperate threads that will watchdog the connection and handle incoming/outcoming data.

_________________
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
   
Display posts from previous:  Sort by  
Post new topic  Reply to topic  [ 5 posts ] 

All times are UTC


Who is online

Users browsing this forum: No registered users and 1 guest


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.