Backbone

Discussions related to programming Transport Empire.

Moderator: Transport Empire Moderators

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

Backbone

Post by uzurpator »

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.
User avatar
DominionSpy
Tycoon
Tycoon
Posts: 1429
Joined: 03 Oct 2003 23:59
Location: Lancashire, UK
Contact:

Re: Backbone

Post by DominionSpy »

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.
User avatar
uzurpator
Transport Empire Moderator
Transport Empire Moderator
Posts: 2178
Joined: 10 Jan 2003 12:21
Location: Katowice, Poland

Post by uzurpator »

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.
User avatar
DominionSpy
Tycoon
Tycoon
Posts: 1429
Joined: 03 Oct 2003 23:59
Location: Lancashire, UK
Contact:

Post by DominionSpy »

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.
User avatar
uzurpator
Transport Empire Moderator
Transport Empire Moderator
Posts: 2178
Joined: 10 Jan 2003 12:21
Location: Katowice, Poland

Post by uzurpator »

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.
Post Reply

Return to “Transport Empire Coding”

Who is online

Users browsing this forum: No registered users and 1 guest