Lag defeating in action game (eg Q3) ?
Author
lo, sup?
Im playing about with an actiony type network game and am trying to defeat the lag problems. Altho the game is LAN only I dont want to overload the pipe with packet updates.
So...my questions are...How does something like Q3 deal with this issue? How often does Q3 send state packets? Over a LAN only what is a max feasible state update rate? (currently im using 10/second)
Thanks for help and advice in advance...
**
Ste
Additional: answering my own question but posing a new one -
Q3 clients send state packets at a rate of 30 per second and gets updates at a rate of 20 per second (default). I always thought 10/second was an un-written max?! Of course this all depends on the size of the packets but at some point wont the overhead of so many packets kick in and slow things down?
Edited by - Jedaye on July 24, 2001 2:47:33 PM
Lag problems can be defeated. From what i''ve found using a combination of several algoritihims you can effectively hide the latency from the player. This if for an action game, but can be applied to any other game even more effectively as action games have proably the tightest requirements for network applciaitons/games.
1)extrapalation
2)timming syncrhionization
3)compression
4)autonomus event creation
5)smart packet management
6)minimizing data need to be transmitted
1: i use a simple linear extraplation from given entity state to predict where the play will be at a given time, which has been synchronized using alrogithim 2.
2:i use NTP as described in www.codewhore.com
3:i compress all packets using data truncation, as other compression algorthims i explored actualy increases packet size when they are in the 10 - 50 byte range.
4:i spawn non-critical events on the client side if i can, to make the game more responsive. For instance the movement events, i actually spawn them after a delay of 1/2 ping on the client side, which is the expected time it takes for a packet to reach the server which then would implemenet the packet on its side aswell. It improves the responsiveness of the vehicle for really lagged players, however care must be taken when the network is really lossy or has high standard deviation in pings.
5:manage your packets, coallate them so as to reduce the packet header overhead. Try not to send more than 10 packets/sec.
6:dont send packets if you dont have too. Cull out any unnessecary packets if you can, using spatial, temporal, or other filters. The fewer packets you send the better.
Good Luck
-ddn
1)extrapalation
2)timming syncrhionization
3)compression
4)autonomus event creation
5)smart packet management
6)minimizing data need to be transmitted
1: i use a simple linear extraplation from given entity state to predict where the play will be at a given time, which has been synchronized using alrogithim 2.
2:i use NTP as described in www.codewhore.com
3:i compress all packets using data truncation, as other compression algorthims i explored actualy increases packet size when they are in the 10 - 50 byte range.
4:i spawn non-critical events on the client side if i can, to make the game more responsive. For instance the movement events, i actually spawn them after a delay of 1/2 ping on the client side, which is the expected time it takes for a packet to reach the server which then would implemenet the packet on its side aswell. It improves the responsiveness of the vehicle for really lagged players, however care must be taken when the network is really lossy or has high standard deviation in pings.
5:manage your packets, coallate them so as to reduce the packet header overhead. Try not to send more than 10 packets/sec.
6:dont send packets if you dont have too. Cull out any unnessecary packets if you can, using spatial, temporal, or other filters. The fewer packets you send the better.
Good Luck
-ddn
Author
>> Try not to send more than 10 packets/sec.
>> Dont send packets if you dont have too.
The game in question is LAN only...is it not feasible to send more packets when players are closer to one another and alot less when they are not in the same part of the game? ie packet sending is proportional to the distance players are appart.
>> Dont send packets if you dont have too.
The game in question is LAN only...is it not feasible to send more packets when players are closer to one another and alot less when they are not in the same part of the game? ie packet sending is proportional to the distance players are appart.
Truthfully if its on lan, you proably wont need many of the techniques i mentioned. Lan usually has less than 10 ms ping, high bandwidth, and no loss. But still limiting to 10 ups max is a good idea. After a certain point if your prediction algorihtims are good enough, any more than 10 ups doesnt help the smoothness any nor accuracy and your just sending redunant information as your prediction algorithims already extrapaltes to the correct position.
Good Luck
-ddn
Good Luck
-ddn
Author
Unless say after a status packet has been sent the player reverses their direction...the prediction based upon the velocity will be far from the new position of the player by the time the next status update comes in...let me try and explain that better with the aid of a crude diagram...
Time = 0 ms : packet send player travelling east
P1 ->
Time = 1 ms : player travels in west direction
By time 100 ms when the next packet update is sent out the remote machines have taken the player to a point east of P1s position at time = 0ms but the player in actual fact reports that they are almost as far west of their position at time 0ms
Does that make my fear any clearer? I considered some sort of counteraction movement (involving a slight increase in velocity of the player on remote screens) to get them to the next predicted position from the last falsy predicted position... (this is how Q3 does it from the source i have seen)
Thanks
**
Ste
Time = 0 ms : packet send player travelling east
P1 ->
Time = 1 ms : player travels in west direction
By time 100 ms when the next packet update is sent out the remote machines have taken the player to a point east of P1s position at time = 0ms but the player in actual fact reports that they are almost as far west of their position at time 0ms
Does that make my fear any clearer? I considered some sort of counteraction movement (involving a slight increase in velocity of the player on remote screens) to get them to the next predicted position from the last falsy predicted position... (this is how Q3 does it from the source i have seen)
Thanks
**
Ste
You can expect that such rough changes happen very seldom. So, I think it wouldnt heart the bandwidth or anything else if the computer who''s player suddenly changes direction would detect such a change, realize that the clients cannot predict it and send an extra packet. Diagram :
0 ms frame drawn ; packet send player dir is 0 degrees
20 ms frame drawn ; player goes 10 deg
40 ms frame drawn ; player goes 95 deg ; difference to last packet too big ; send new packet
50 ms packet received on remote machines
60 ms frame drawn ; player goes 100 deg;
80 ms frame drawn ; player goes 105 deg
100 ms frame drawn ; packet sent with 110 deg
Chances that the network would become bogged down by these extra packets is extremely small. Even in tough fight, most players try to aim <=> not change direction with 180 deg in 100 ms.
0 ms frame drawn ; packet send player dir is 0 degrees
20 ms frame drawn ; player goes 10 deg
40 ms frame drawn ; player goes 95 deg ; difference to last packet too big ; send new packet
50 ms packet received on remote machines
60 ms frame drawn ; player goes 100 deg;
80 ms frame drawn ; player goes 105 deg
100 ms frame drawn ; packet sent with 110 deg
Chances that the network would become bogged down by these extra packets is extremely small. Even in tough fight, most players try to aim <=> not change direction with 180 deg in 100 ms.
Abrupt changes in direction are common in action games.\
You can use a small amount of time distortion as well; you show the player what''s going on 50-100ms ago. The idea is to make the distortion small enough that the player barely notices, but the network gets more time to send & retrieve packets.
You can use a small amount of time distortion as well; you show the player what''s going on 50-100ms ago. The idea is to make the distortion small enough that the player barely notices, but the network gets more time to send & retrieve packets.
Time distorsion seems like a great idea. Of course, it would not only show on the players screens, the server would take it into account when calculating instant bullets intersections. The server has to keep a short history of every player. When he receives a "shoot" message from player x at time y, he intersects the firing direction with all players at time y - 100ms.
i haven''t really done much net coding (in games at least) but basically the best thing for you to do with LAN is to send a message from the server on the directions, locations, and speeds of all the entitys in the game upon entering the server, then when an entity changes course simply send a packet stating the entity has changed to x course and is going y speed. O yah but also every time an ent changes corse make sure to send where the location of the ent is cuz the client may have missed a packet for some reason which means the ent would probably be running in to walls (which may be amusing but not for long) since the updates dont update the location. As for picking up items and such it shouldn''t be to hard just have the server send a struct or something on the currents client''s status, and thats if your protocal is mostly server side. Hope I helpd.
-MaNiAk, USA
YoUnG N'' DuMb
-MaNiAk, USA
YoUnG N'' DuMb
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
