Time Sync
In order for cubic dead reckoning to work, don''t you need a common start time?
When a client recieves a packet with a position/velocity/acceleration/jerk data in it, you need a known common/sync''ed time to extrapolate from. Or do most games just ignore the latency/lag, and assume t=0 on recieve? seems like that would suck awfully bad - like descent.
I see a couple ways to do this.
Easiest way, other than not dealing with it, would be to keep a ''lag hint'' associated with each player. Maybe every 2-5 seconds or so you could send an echo packet to the server with a timestamp, then the server just bounces that back. Calculate round trip time, divide by half and you have a method of figuring lag that is probably pretty close to what you''ll see in-game. You could apply some pretty advanced algos here, some that take into account the prior 10 calculated times... giving different weight based on variance from the norm etc...
Or, you could use a system of associating one object''s position with another object''s position at that same time. You could then keep a sort of timeline on the client and just constantly move the current time pointer forward. This actually wouldn''t be THAT hard to do, but it would still be much more complex than the timestamp / echo trick.
There''s another simple way, although not terribly efficient. The structure send from the server would be something like:
The easiest way to optimize this server side is to trim the players / objects that the client you''re sending to can''t see, but even if you don''t, 32 players and 40 items would still only take up 864 bytes. More than you''d like by a bit, but not TOO insane. Cut down to 16 players, figure fewer items and you''re in the money.
Easiest way, other than not dealing with it, would be to keep a ''lag hint'' associated with each player. Maybe every 2-5 seconds or so you could send an echo packet to the server with a timestamp, then the server just bounces that back. Calculate round trip time, divide by half and you have a method of figuring lag that is probably pretty close to what you''ll see in-game. You could apply some pretty advanced algos here, some that take into account the prior 10 calculated times... giving different weight based on variance from the norm etc...
Or, you could use a system of associating one object''s position with another object''s position at that same time. You could then keep a sort of timeline on the client and just constantly move the current time pointer forward. This actually wouldn''t be THAT hard to do, but it would still be much more complex than the timestamp / echo trick.
There''s another simple way, although not terribly efficient. The structure send from the server would be something like:
struct PLAYER_STATE
{
short Id;//Unique player ID
short X;
short Y;
short Z;
short H;//Heading
short V;//Velocity
}
struct ITEM_STATE
{
short Type;//Bullet, Missile, blah blah
short X;
short Y;
short Z;
short H;//heading
short V;//velocity
}
struct WORLD_STATE
{
short nTime;
short nPlayers;
short nItems;
PLAYER_STATE *pPlayers;
ITEM_STATE *pItems;
}
The easiest way to optimize this server side is to trim the players / objects that the client you''re sending to can''t see, but even if you don''t, 32 players and 40 items would still only take up 864 bytes. More than you''d like by a bit, but not TOO insane. Cut down to 16 players, figure fewer items and you''re in the money.
I''m figuring on 10,000 players so sending everything isn''t exactly the plan 
How about sending the server an echo time packet, contains the time sent in client ticks to it, the server returns the original packet along with its clock tick in it
That way every client can adjust its time stamp to be in sync with the server''s ticks on send and every packet received will have a universal syncronised time stamp.
Once a minute or so resync the time with the server. maybe once every five minutes...
Thanks Mr. Stelly.
How about sending the server an echo time packet, contains the time sent in client ticks to it, the server returns the original packet along with its clock tick in it
That way every client can adjust its time stamp to be in sync with the server''s ticks on send and every packet received will have a universal syncronised time stamp.
Once a minute or so resync the time with the server. maybe once every five minutes...
Thanks Mr. Stelly.
That''ll work too.
And you could send all of the player information for 10000 people... You just need to figure out a way to encode the entire player state into 2 bits. =)
And you could send all of the player information for 10000 people... You just need to figure out a way to encode the entire player state into 2 bits. =)
I was thinking that the clients would decide what to send to who;
Some sort of tree'd out network of sockets. Status updates would flow around the network according to location in game. The the goal is that players/npcs that are far apart recieve less frequent updates than of players/npcs that are close. Instead of everything being sent to the server and re-broadcast, the clients would also act like servers. In order to connect to the game you would need to connect to a main server and several other players in your area (in game).
The trick is to build a tree of the connections and send data out in an efficient manor, so that eveyone who should get the update does, and those that shouldn't don't.
In stead of having the server do all checking/validation of player commands, the server would assign other computers to do this. Each player would have another players computer calculating his attacks/etc...
I thought about pushing npc AI out to the clients too, on connect your client is assigned some group of npc's to control. What do on sudden disconnects though...
Edited by - Magmai Kai Holmlor on October 4, 2000 9:12:38 PM
Some sort of tree'd out network of sockets. Status updates would flow around the network according to location in game. The the goal is that players/npcs that are far apart recieve less frequent updates than of players/npcs that are close. Instead of everything being sent to the server and re-broadcast, the clients would also act like servers. In order to connect to the game you would need to connect to a main server and several other players in your area (in game).
The trick is to build a tree of the connections and send data out in an efficient manor, so that eveyone who should get the update does, and those that shouldn't don't.
In stead of having the server do all checking/validation of player commands, the server would assign other computers to do this. Each player would have another players computer calculating his attacks/etc...
I thought about pushing npc AI out to the clients too, on connect your client is assigned some group of npc's to control. What do on sudden disconnects though...
Edited by - Magmai Kai Holmlor on October 4, 2000 9:12:38 PM
I''ll tell you how it''s done in a commercial coin-op linked game that I worked on.
One machine is designated as "master" using arbitration technique (EG: lowest numbered IP address or other simple method).
Each machine measures latency to master (how long does it take to send a packet from one machine to the next).
Master sends packets to set the time on other machines.
Each other machine sets time to value sent by master plus value determined to be latency from master.
Any events from that point on happen in a mutually synchronized clock.
The end.
Hope this helps!
Here''s a link to the game that successfully uses this technique:
http://www.rush2049.com
One machine is designated as "master" using arbitration technique (EG: lowest numbered IP address or other simple method).
Each machine measures latency to master (how long does it take to send a packet from one machine to the next).
Master sends packets to set the time on other machines.
Each other machine sets time to value sent by master plus value determined to be latency from master.
Any events from that point on happen in a mutually synchronized clock.
The end.
Hope this helps!
Here''s a link to the game that successfully uses this technique:
http://www.rush2049.com
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
