Jump to content
  • Advertisement
Sign in to follow this  
Barabashka

"The Quake3 Networking Model" Question

This topic is 5052 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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.

Share this post


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

Share this post


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

Share this post


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

Share this post


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

Share this post


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

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?

Share this post


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

Share this post


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

Share this post


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

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!