Archived

This topic is now archived and is closed to further replies.

Jedaye

Lag defeating in action game (eg Q3) ?

Recommended Posts

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

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
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

Share this post


Link to post
Share on other sites
>> 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.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
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

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
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

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
oooh ya one important note of course u need to have a timer sending the state packets, which wont send anything if no entity''s direction, speed, position changed. Or else you would be sending so many dam packets u would have a 6-pack! (anyone who laughed at that... i pity u)

-maniak

Share this post


Link to post
Share on other sites
Q3 source is on the ID site as i recall.

Anyway, at the moment i am sending out position updates at time intervals. This seems to work oki and there apears to be no slowdown with 5 machines pumping out 30 updates a seccond. I understand about building up a mass of msgs and clogging the pipe with packets but this game will be 8 players max - LAN only. For now i think i will stick to this method having tried exterpolation/prediction among other methods.



**
Ste

Share this post


Link to post
Share on other sites
Thats not the source code for Quake 3, its the SDK you use to make mods. The source code has been released for Quake 1, so you could dig that up and find the networking code there. But the Quake 3 networking code is not available.

Share this post


Link to post
Share on other sites
You are indeed correct, I should have pointed that fact out myself...however some interesting source is included...for example the function: CG_PredictPlayerState



**
Ste

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Oh yeah i forgot another technique commonly used. Retroactive event handling, used to determine events based upon a universal time instead of being bias toward low ping players with a purely current event driven model.

Good Luck

-ddn

Share this post


Link to post
Share on other sites