Sign in to follow this  

Quake 2 Networking model

This topic is 4839 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

Hi! I have a question about quake 2 networking model. Is there some documentation on the architecture of this part of Quake 2 Engine. Yeah, I could do some reverse engineering, but I would prefer to read some (even blur) description. The information I am interested in are: - what data is exchanged - how does server checks whether the client is not cheating - how are the clients synchronized (for example taking the same medipack) - how often are the packets sent - and even more:) Thanks for answers.

Share this post


Link to post
Share on other sites
There is no need to reverse-engineer. Just read the source code. This is not a complete answer, its just something simple to give you ideas. The full answer is complicated :)

- what data is exchanged
C->S: Your intended angle of rotation and intention of movement
S->C: All player information, gamestate, your actual movement

- how does server checks whether the client is not cheating
The server makes sure that the client has a limited speed of movement, clips it if the client goes too far. On some later implementations, BSP culling can be used to only send other player info if the other player is in the same sector (anti-wallhacking strategy). But in reality the original Quake2 cannot protect against aim cheats (because aim is done with fixed angles, not delta movements) and wallhacks. Nor can Counter-Strike, thats why there are so many cheats.

- how are the clients synchronized (for example taking the same medipack)
Name of media pack is compared, hashes of maps are compared. If not match attempt to download. If download fail, abort.

- how often are the packets sent
That depends on the 'rate' settings. Depends on server and client configuration.

- and even more :)
Read the source.

Share this post


Link to post
Share on other sites
Here's an interesting article about the Quake 3 network model. It says (among other things) that Carmack was never really happy with the networking in Quake 2.

It might be worth checking out.

Share this post


Link to post
Share on other sites
Konrad,

I'll try to explain some of the answers you are interested in based on what I've learned from my own reverse engineering. Keep in mind this isn't official and is my own interpretation so it is most likely not 100% correct:

Quote:

what data is exchanged


Voxelsoft pretty much summed it up in his two lines. The client will send it's keyboard and mouse state as well as it's view angles (I believe) every frame. This data is sent out in the form of an unreliable message (with the exception of a weapon fire (and jumping/crouching) which is sent reliably) each and every client frame. This is the biggest reason that Quake II and Quake III implemented frame caps otherwise you would overrun your max rate and as a result you would lag.

As far as the server is concerned I believe it's every 10 or 20ms a "gamestate" update is sent to the client which will include items such as viewable entities (clients, spawned items, etc.) and "playerstate" updates which will force the local client to the position where the server thinks it is. It will also send out events (which last one frame) such as muzzle flashes, and if a weapon is fired it will inform the client of where it was spawned at what time and it is then up to the client to predict where it will be in it's ping time / 2 from when it was fired.

Quote:

how does server checks whether the client is not cheating


The server does a number of checks in regards to moves (such as only allowing one more per packet) as well as grants each client a certain # of milliseconds (believe the method is GiveClientMilliseconds()) which is a brief time to allow the client to move. It would take much too long to explain all the checks it does but I'd recommend looking at the main server game loop and browse through it and you should come across most of them.

Quote:

how are the clients synchronized (for example taking the same medipack)


This is where prediction comes into play which is not perfect but really helps in handling synchronization. Basically since the server keeps track of where all the clients are, if client X hits the medpack just before client Y, the client must wait for the event from the server before picking up the healthpack. The server predicts every frame where things are going and will fire an event to client X informing it that it picked up the healthpack and client Y therefore will not play the pickup animation or have health added etc. I think at this point the client would still predict that someone picked up the medpack and therefore remove it from the world and then wait for the server event saying "yes you picked it up".

Hope this has helped you out somewhat, like I said this is what I've gotten out of analysing the Quake II source so it's probably not 100% correct but should help to get you rolling.

Permafried-

[Edited by - Permafried- on September 15, 2004 11:13:07 AM]

Share this post


Link to post
Share on other sites
Quote:

Quote:

- how are the clients synchronized (for example taking the same medipack)

Name of media pack is compared, hashes of maps are compared. If not match attempt to download. If download fail, abort.


No, I don't think that was the problem the original poster asked. The original poster asked something like:

Suppose there's a medpak. Suppose two players run up to the same medpak, each on their own machine (there's some lag in where the other player is displayed). Only one player can ACTUALLY get the medpak, as it is consumed on "getting". How does Quake II determine which player actually got it?

I don't know how Quake II does it, but the source is available for public download from Id software. The way I would do this is have each client request the medpak, have the server validate the request (are they actually there, and does the medpak actually exist?) and then send out changes in medpak availability (and results of medpak application) to everyone. This means that you don't actually get your HP boost until the server sends you back the result and tells you that you won.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Quote:
Original post by hplus0603
Quote:

Quote:

- how are the clients synchronized (for example taking the same medipack)

Name of media pack is compared, hashes of maps are compared. If not match attempt to download. If download fail, abort.


No, I don't think that was the problem the original poster asked. The original poster asked something like:

Suppose there's a medpak.


GIGO. Also already answered by another poster.

Share this post


Link to post
Share on other sites
I see how the client knows who picked up the medipack, but how does the server?
Suppose clients A and B both rush to pick it up. A gets there first (according to an observer watching both computers) but their packet to the server is lost....

Share this post


Link to post
Share on other sites
Quote:
Original post by DBX
I see how the client knows who picked up the medipack, but how does the server?
Suppose clients A and B both rush to pick it up. A gets there first (according to an observer watching both computers) but their packet to the server is lost....


Pretty straightforward - if A's packets get lost and B's packets don't, then B will be first to take medipack:)

Share this post


Link to post
Share on other sites
Quote:
Original post by MickeyMouse
Quote:
Original post by DBX
I see how the client knows who picked up the medipack, but how does the server?
Suppose clients A and B both rush to pick it up. A gets there first (according to an observer watching both computers) but their packet to the server is lost....


Pretty straightforward - if A's packets get lost and B's packets don't, then B will be first to take medipack:)


So, basically players with lower pings and better connections get priority? Seems a little unfair.

Share this post


Link to post
Share on other sites
Quote:
Original post by DBX
Quote:
Original post by MickeyMouse
Quote:
Original post by DBX
I see how the client knows who picked up the medipack, but how does the server?
Suppose clients A and B both rush to pick it up. A gets there first (according to an observer watching both computers) but their packet to the server is lost....


Pretty straightforward - if A's packets get lost and B's packets don't, then B will be first to take medipack:)


So, basically players with lower pings and better connections get priority? Seems a little unfair.


Depends on your point of view - imagine there was a mine instead of medipack:D

In fact that's how I believe it's done in every multiplayer game. You would otherwise require server to wait certain time after having received first request for the medipack and in case there comes request with earlier time value, then give medipack to the second one.
This however except for frustration of players with high ping, might lead to cheats too, so it's not a good idea.

Share this post


Link to post
Share on other sites
Quote:
Original post by hplus0603
Quote:

Quote:

- how are the clients synchronized (for example taking the same medipack)

Name of media pack is compared, hashes of maps are compared. If not match attempt to download. If download fail, abort.


No, I don't think that was the problem the original poster asked. The original poster asked something like:

Suppose there's a medpak. Suppose two players run up to the same medpak, each on their own machine (there's some lag in where the other player is displayed). Only one player can ACTUALLY get the medpak, as it is consumed on "getting". How does Quake II determine which player actually got it?

I don't know how Quake II does it, but the source is available for public download from Id software. The way I would do this is have each client request the medpak, have the server validate the request (are they actually there, and does the medpak actually exist?) and then send out changes in medpak availability (and results of medpak application) to everyone. This means that you don't actually get your HP boost until the server sends you back the result and tells you that you won.


many people say halflife is based on the quake2 engine

well i don t know it, but i have programmed a lot with the hl sdk and the way they handle medpacks for example is like this

each entity has 3 calls on the server
1. preframe
2. frame
3. postframe

this is called in every gameloop

now the client sends down reliable button and key input messages
and the view angle is only updated when it really changes

now to the medpack
the server checks if the client picks up a medpack, if so he tells the client via reliable message that he picked it up ....

muzzleflashes and other every are not send via network, only a gunfire event, since the viewangle is synchronized the client knows the position to place the muzzle at, so he waits for incoming messages and handles them view event handlers

e.g.: each fire event stores the index of the player and the angle he fired at + origin


thats basically everything he does

another node if you send characters(CHAR)
don t send 1 byte for each CHAR,you can compress it to 6-7 bits


hl uses bitpacking
maybe send coordinates as integers and let the prediction do the decimal interpolation

Share this post


Link to post
Share on other sites

This topic is 4839 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.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this