Another dilemmas is that i use UDP. That means some shots CAN be lost. What can be done about that? (guess nothing Probably its enabling reliabilty algos for UDP wont help becouse it cause lags.
What do you thing about all that?
UDP, multiplayer and shooter
Author
I''m trying to write simple multiplayer game- shooter. And becouse of that I have some dilemmas. Should client shot be eveluated on server or directly on client. Methinks that games like quake eveluate hits on server side. But that will require very low lantency connection... for example its hard to play in counterstrike with ping 100 when everybody got 20. However its looks like Red Faction multiplayer eveluate hit on client side and send damege info to server. Even with ping 300 Red Faction is playable due to this fact. What do you think? And... dont say that server should manage everythin becouse client can cheat.
Another dilemmas is that i use UDP. That means some shots CAN be lost. What can be done about that? (guess nothing Probably its enabling reliabilty algos for UDP wont help becouse it cause lags.
What do you thing about all that?
Another dilemmas is that i use UDP. That means some shots CAN be lost. What can be done about that? (guess nothing Probably its enabling reliabilty algos for UDP wont help becouse it cause lags.
What do you thing about all that?
server side is still the best method imho, for example:
server handles :
client presses fire
events and effects played client side
fire event sent to server which does events and works out who was hit
hit infomation delt with and any change of states sent to targets
Client handles L
client presses fire
client using data which could be very old (n computing terms) to work out who is hit and damage
target and damage infomation sent to server
server makes changes to infomation and resends infomation onto client who was hit
pretty much the same steps, however one important difference (aside from the client lieing about damnage) is that, with the second system your infomation regarding the players postions and direction of movement could be completely wrong, thus you tell the server ''I''ve hit player 12 for 200 dmg'' where as in effect you''ve missed player 12 by a good couple of feet (he''s behind a wall say) at which point player 12 gets hit and they start complaining about cheating etc as the details dont tie up.
So, while you are getting rid of the lag in one direction, you are probably making a worse situation for yourself in the other
(btw, re: CS, I used to play on a 56K modem with a ping around 180 and regulary beat players with a ping of around 20-40ms)
As for shot infomation being lost, from my understanding of it most FPS games use both UDP and TCP, TCP for important infomation (shots fire, important events etc) and UDP for quick state updates (movement etc)
server handles :
client presses fire
events and effects played client side
fire event sent to server which does events and works out who was hit
hit infomation delt with and any change of states sent to targets
Client handles L
client presses fire
client using data which could be very old (n computing terms) to work out who is hit and damage
target and damage infomation sent to server
server makes changes to infomation and resends infomation onto client who was hit
pretty much the same steps, however one important difference (aside from the client lieing about damnage) is that, with the second system your infomation regarding the players postions and direction of movement could be completely wrong, thus you tell the server ''I''ve hit player 12 for 200 dmg'' where as in effect you''ve missed player 12 by a good couple of feet (he''s behind a wall say) at which point player 12 gets hit and they start complaining about cheating etc as the details dont tie up.
So, while you are getting rid of the lag in one direction, you are probably making a worse situation for yourself in the other
(btw, re: CS, I used to play on a 56K modem with a ping around 180 and regulary beat players with a ping of around 20-40ms)
As for shot infomation being lost, from my understanding of it most FPS games use both UDP and TCP, TCP for important infomation (shots fire, important events etc) and UDP for quick state updates (movement etc)
The server _must_ have the final say, or else your game is completely open to rule cheating.
FPS don''t use TCP (at least the Quake-based ones don''t, and IIRC Unreal-based don''t either). They do implement their own guarantueed delivery mechanism. Look at the Quake source code, for example.
Opening an additional socket simply isn''t worth it, unless maybe you want to transfer huge amounts of data, such as automatic downloads of maps.
Half-Life is actually very playable with high pings, compared to some other games. Of course this may be different with Counter-Strike where you die almost immediately.
In Half-Life, the server decides who gets hit. However,
1. Client-side prediction is used. This means that you get to see the weapon animation (and even some decals) immediately. This is purely asthetic, it gives you an increased feeling of immersion. Note that it is actually correct, when used together with point 2.
2. Lag compensation is used. When the server receives an event that Client X fires, it calculates (based on the average ping) when the fire command was actually issued. The engine then temporarily places all players back to where they were at the time the client fired, and uses this state of the world to trace the shot and calculate whether another player was hit.
Lag compensation does have problems. For example, in the initial version of the new HL netcode, it was possible to temporarily fake extremely high pings. This would effectively freeze your view of the world, and since the server trusted the timestamp sent by the client completely, you could take up to a second or so to aim at an enemy.
Also, lag compensation doesn''t work for projectile weapons.
cu,
Prefect
FPS don''t use TCP (at least the Quake-based ones don''t, and IIRC Unreal-based don''t either). They do implement their own guarantueed delivery mechanism. Look at the Quake source code, for example.
Opening an additional socket simply isn''t worth it, unless maybe you want to transfer huge amounts of data, such as automatic downloads of maps.
Half-Life is actually very playable with high pings, compared to some other games. Of course this may be different with Counter-Strike where you die almost immediately.
In Half-Life, the server decides who gets hit. However,
1. Client-side prediction is used. This means that you get to see the weapon animation (and even some decals) immediately. This is purely asthetic, it gives you an increased feeling of immersion. Note that it is actually correct, when used together with point 2.
2. Lag compensation is used. When the server receives an event that Client X fires, it calculates (based on the average ping) when the fire command was actually issued. The engine then temporarily places all players back to where they were at the time the client fired, and uses this state of the world to trace the shot and calculate whether another player was hit.
Lag compensation does have problems. For example, in the initial version of the new HL netcode, it was possible to temporarily fake extremely high pings. This would effectively freeze your view of the world, and since the server trusted the timestamp sent by the client completely, you could take up to a second or so to aim at an enemy.
Also, lag compensation doesn''t work for projectile weapons.
cu,
Prefect
quote:Original post by Prefect
FPS don''t use TCP (at least the Quake-based ones don''t, and IIRC Unreal-based don''t either). They do implement their own guarantueed delivery mechanism. Look at the Quake source code, for example.
ah, I stand corrected, for some reason I thought it did, cheers for clearing that up for me
Author
"Lag compensation does have problems. For example, in the initial version of the new HL netcode, it was possible to temporarily fake extremely high pings. This would effectively freeze your view of the world, and since the server trusted the timestamp sent by the client completely, you could take up to a second or so to aim at an enemy."
the same things happen in Red Faction multiplayer- player with high ping can easily kill other player but drawback is that others can kill easier such a lagged one. Also i think RF server reject very old hit-messages (ping above >1000) and lagged players often are kicked off servers by admins (becouse they are ruin game).
"The engine then temporarily places all players back to where they were at the time the client fired, and uses this state of the world to trace the shot and calculate whether another player was hit."
now thats is good on first thought. but if you look closer it doesnt differ from client-side shot eveluation. i mean that server COULD have obsolate and missing data about player position. The same things happen to client so shot eveluation by client wont be differ from servers in accuracy (at least too much). And if ping will be rather good - 50-100 everyting sould look fine.
Last question is: does quake send client shot events using udp and then wait for delivery acknowladge?
the same things happen in Red Faction multiplayer- player with high ping can easily kill other player but drawback is that others can kill easier such a lagged one. Also i think RF server reject very old hit-messages (ping above >1000) and lagged players often are kicked off servers by admins (becouse they are ruin game).
"The engine then temporarily places all players back to where they were at the time the client fired, and uses this state of the world to trace the shot and calculate whether another player was hit."
now thats is good on first thought. but if you look closer it doesnt differ from client-side shot eveluation. i mean that server COULD have obsolate and missing data about player position. The same things happen to client so shot eveluation by client wont be differ from servers in accuracy (at least too much). And if ping will be rather good - 50-100 everyting sould look fine.
Last question is: does quake send client shot events using udp and then wait for delivery acknowladge?
quote:"The engine then temporarily places all players back to where they were at the time the client fired, and uses this state of the world to trace the shot and calculate whether another player was hit."
now thats is good on first thought. but if you look closer it doesnt differ from client-side shot eveluation. i mean that server COULD have obsolate and missing data about player position. The same things happen to client so shot eveluation by client wont be differ from servers in accuracy (at least too much). And if ping will be rather good - 50-100 everyting sould look fine.
No, there is a very important difference between server and client shot evaluation. If the client had the final say in who gets shot, it could say "Look, I hit player B in the head for 200 damage" even though player B is at the opposite end of the level.
quote:
Last question is: does quake send client shot events using udp and then wait for delivery acknowladge?
The Quake client sends a usercmd packet every frame. This usercmd packet contains information such as the current view angle, the movement command and finally a set of button states as a bitfield. One of these buttons is the fire button.
There is no usercmd ACK in Quake; however, when a usercmd is dropped, the server simply reuses the latest known usercmd, so if the client just keeps firing, the server should keep evaluating the shots, too, even if some packets get dropped.
cu,
Prefect
[edited by - Prefect on November 3, 2002 10:06:41 AM]
Author
"Look, I hit player B in the head for 200 damage" even though player B is at the opposite end of the level."
that is why shot eveluation has to have additional condition:
- last players postion/state have not to be too much obsolte
If this condition is match IMO there is no difference in big accuracy between client and sever shot evaluation.
Server always recieves obsolate player postion - client has the same problem, if lag isnt too big - there will be no diffrence.
That brings some profit: player can aim in to
object that are really in that place (from client point of view).
If shot would be eveluated by sever and server could have diffrent information from client''s (faster data update or packet loss) there probably will be many false miss on client side. (false to client but not to sever) And player will quit game with thoughts "I know I hit him! Why he dont die! Cheater!"
that is why shot eveluation has to have additional condition:
- last players postion/state have not to be too much obsolte
If this condition is match IMO there is no difference in big accuracy between client and sever shot evaluation.
Server always recieves obsolate player postion - client has the same problem, if lag isnt too big - there will be no diffrence.
That brings some profit: player can aim in to
object that are really in that place (from client point of view).
If shot would be eveluated by sever and server could have diffrent information from client''s (faster data update or packet loss) there probably will be many false miss on client side. (false to client but not to sever) And player will quit game with thoughts "I know I hit him! Why he dont die! Cheater!"
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
