"The Quake3 Networking Model" Question
Author
Hello,
I just read this article at
http://www.bookofhook.com/Article/GameDevelopment/TheQuake3NetworkingModel.html
and I'am trying to understand why:
"server sends sequenced game state updates that are delta compressed from the last acknowledged game state the client received".
If "first person" side does client side prediction, what does it matter, how other third person players had moved till I got new game-state update?
OK, I missed few updates, made prediction for them (possible got some of them wrong) but now with new update packet I can fix it all.
So why would I need all that game-state updates I missed?
If "Dropped packets are handled implicitly..." why it is so important to send them?
Thanks.
You seem to be asking whether the Quake 3 model re-sends dropped packets.
The answer is that it does not.
For each packet that DOES get through, the other end acknowledges in their next packet. This way, the two can share a common baseline for delta compression.
Delta compression is used to minimize the amount of data sent; movement as a delta from where you were half a second ago can be sent with fewer bits than movement in an absolute (world-space) coordinate frame.
The answer is that it does not.
For each packet that DOES get through, the other end acknowledges in their next packet. This way, the two can share a common baseline for delta compression.
Delta compression is used to minimize the amount of data sent; movement as a delta from where you were half a second ago can be sent with fewer bits than movement in an absolute (world-space) coordinate frame.
Author
Now everything on their places, THANK you hplus0603 & Happy New Year to everybody.
just wondering but why doesn t he include visiblility calculations to the networking system?
do you really have to know whats going on 4 blocks behind you?
do you really have to know whats going on 4 blocks behind you?
In Quake, it's possible to turn 180 degrees with a flick of the wrist (skilled players do this all the time). The levels are usually fairly small, too. And there are ranged weapons (such as rocket launcher) that you absolutely need to know about wherever they are on the map. Thus, typical FPS-es don't do visibility filtering much.
Author
What is still a mystery for me is if server generates one update packet and send it to all clients, so if just one client does not get some packet - server now have to increase delta range.
For instance:
Server sent delta(Pos(1) - Pos(0)).
Got ack from all clients.
Server sent delta(Pos(2) - Pos(1)).
Did not get ack from only one client-A.
Now Server sends to all delta(Pos(3) - Pos(1)).
...
So the delta range can grow is'n it ?
For instance:
Server sent delta(Pos(1) - Pos(0)).
Got ack from all clients.
Server sent delta(Pos(2) - Pos(1)).
Did not get ack from only one client-A.
Now Server sends to all delta(Pos(3) - Pos(1)).
...
So the delta range can grow is'n it ?
Well, i may be wrong but as far as i understand it, you have to store the last ack for every client independently. So in your case you would send delta(Pos(3)-Pos(2)) to all clients except client A and delta(Pos(3)-Pos(1)) to client A only.
Yes, that's right.
Now i have another question: How about more data consuming things like chat messages? Would you send them again and again in every packet until you receive an ack for at least one of those packets containing the chat message? Or is it better to send those only something like every 10th frame? But wouldn't that break the delta compression mechanism?
Quote:
So the delta range can grow is'n it ?
Yes, that's right.
Now i have another question: How about more data consuming things like chat messages? Would you send them again and again in every packet until you receive an ack for at least one of those packets containing the chat message? Or is it better to send those only something like every 10th frame? But wouldn't that break the delta compression mechanism?
Author
Please correct me if I'm wrong but I was sure that if server
1. Prepare data for client.
2. Add CRC
3. Encript packet
for each client that would be some waste of time/performance(more latency).
I thought server could send the same data packet for everyone.
1. Prepare data for client.
2. Add CRC
3. Encript packet
for each client that would be some waste of time/performance(more latency).
I thought server could send the same data packet for everyone.
Quote:Original post by Basiror
just wondering but why doesn t he include visiblility calculations to the networking system?
do you really have to know whats going on 4 blocks behind you?
I don't know about Q3, but Half Life (and probably HL2) does do a PVS check. This is mostly useful for preventing wallhacks.
Quote:Now i have another question: How about more data consuming things like chat messages? Would you send them again and again in every packet until you receive an ack for at least one of those packets containing the chat message? Or is it better to send those only something like every 10th frame? But wouldn't that break the delta compression mechanism?
I think the easiest way round that one would be to keep a TCP socket open for non-time-critical (but still important) data. That way you can blame the service provider for any missing chat packets [grin]
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
