Hello!
As far as I know server of fps game should handle all game mechanics and updates and send snapshots of changes every specified portion of time. I seem to understand that concept well.
Problem comes with input in my case.
Basic movement is no big deal, if player hits UP key i send packet that user is currently moving top and when he releases I send he stopped moving. In the meantime I also run the same code for moving on user setup just to minimal lag and server keeps me on track all the time
However problems happen with camera and looking around with mouse. It's very important for shooting obviously so I need to have that rotation float of my player always up-to-date on server. However sending float to server everytime something happened might be pretty consuming. What should I do?
FPS Game Server
your server probably doesn't care where the guy is looking, only when he is shooting. So sending updates less frequently for that unless firing ~1/s maybe ok.
What he is saying is that unless each client is animating the facing direction of each player you're probably only interested in transmitting the data about where a shot has gone. This is needed to determine when someone gets hit.
Essentially you need to realise the separation between what the user does on the client and what really only needs to be transmitted to to the server.
Essentially you need to realise the separation between what the user does on the client and what really only needs to be transmitted to to the server.
Author
I dont think you understand
I hit LMB and send server that info, server then keep firing bullets (creating them and updating) according to my rotation.
I hit LMB and send server that info, server then keep firing bullets (creating them and updating) according to my rotation.
Quote:Original post by waxx
I dont think you understand
I hit LMB and send server that info, server then keep firing bullets (creating them and updating) according to my rotation.
Not sure what LMB is. But consider that a float has a size of prolly 4 bytes. Compare those 4 bytes to a DVD of 4.7 Gigabytes that can be downloaded in, say, 4 hours, that would be
1.175 GiB/h
== 0.02 GiB/min
== 0.33 MiB/sec
== 342 KiB/sec
== 350457 Bytes/sec
== 87614 floats/sec
== 29204 cartesian 3d-Vectors/sec
== 14602 fully qualified cartesian look-at informations/sec.
Now, typical machine-guns like our MG3 reach up to 1300 rounds/min == 22 rounds/sec. That leaves plenty of space, I guess.
Of course downloading a DVD is different from downloading gamestats, but I find that ppl often forget about The Modern Dimensions of Stuff and then worry about performance way to soon.
Unfortunately, this is largely something you just have to eat. What you can experiment with, however, is using a largest-component compressed quaternion (this can be packed into 32 bits) to store rotation information. Even at 30 updates/sec, that's still a ways under a kilobyte per second.
For an example of how a (highly regarded) professional handles this, check out Valve's article on the Source engine.
For an example of how a (highly regarded) professional handles this, check out Valve's article on the Source engine.
Most FPS games show the player heading to other players -- it is actually important gameplay information. Thus, the movement packet typically includes movement command bits (forward, sprint, etc), plus heading information. However, not all is lost. For example, you can quantize look direction. Seven bits for up/down and nine bits for heading is generally sufficient.
Regarding the bandwidth calculation, you should realize that players have bandwidth of different quality, and you have to design for the lowest common denominator. Three years ago, that was 64 kilobits per second (!) for the 99th percentile. This means you're telling one out of hundred players to go away. If you want a higher send rate, you'll slide down the percentages, telling one in ten players to go away, or one in two, or whatever.
So, with 64 kilobits per second, and a 15 per second packet update rate, and a 28 byte UDP overhead and 16 byte your-own-protocol overhead, you are looking at, at most, (64*1024/8/15) == 546 - (28+16) == 534 bytes per update. For an 8-player game, that means 66 bytes per player including chat and scoring and whatever else is going on. However, fitting 16 bytes per player per update for heading, pitch, position (three 24-bit values), command state and weapon state seems reasonable.
Regarding the bandwidth calculation, you should realize that players have bandwidth of different quality, and you have to design for the lowest common denominator. Three years ago, that was 64 kilobits per second (!) for the 99th percentile. This means you're telling one out of hundred players to go away. If you want a higher send rate, you'll slide down the percentages, telling one in ten players to go away, or one in two, or whatever.
So, with 64 kilobits per second, and a 15 per second packet update rate, and a 28 byte UDP overhead and 16 byte your-own-protocol overhead, you are looking at, at most, (64*1024/8/15) == 546 - (28+16) == 534 bytes per update. For an 8-player game, that means 66 bytes per player including chat and scoring and whatever else is going on. However, fitting 16 bytes per player per update for heading, pitch, position (three 24-bit values), command state and weapon state seems reasonable.
I would probably send the ray/vector information which the player's bullet is heading and the player's client side location. That would probably be quite hackable (what fps isn't tbh) but it would be very accurate for whoever is doing the shooting. That appears to be what most fps games do from my experience playing them. It will result in lots of dieing while round the corner from your opponent, even with a fairly high quality connection & tick rate - but it is better than using the server side angle/player location... Now hplus tells me there is a better way :D
Thinking about all this. Does that mean that multiple bullets from one player are sometimes being checked server-side on the same tick, like they left the player's gun at the same time?
Player look direction and location should be separate from the shooting system, however the location may need to be checked with the input from the shoot event to make sure it is not obviously from an impossible location. There is no way to validate the direction in a PC game (unless you want to ruin it with max turning speed... Only real way to get rid of aimbots is server admins, and even they aren't that accurate all the time :P), but with consoles it is possible to know how fast they could have turned - though lag spikes could still get in the way of gameplay if the cheat prevention is too strict.
Thinking about all this. Does that mean that multiple bullets from one player are sometimes being checked server-side on the same tick, like they left the player's gun at the same time?
Player look direction and location should be separate from the shooting system, however the location may need to be checked with the input from the shoot event to make sure it is not obviously from an impossible location. There is no way to validate the direction in a PC game (unless you want to ruin it with max turning speed... Only real way to get rid of aimbots is server admins, and even they aren't that accurate all the time :P), but with consoles it is possible to know how fast they could have turned - though lag spikes could still get in the way of gameplay if the cheat prevention is too strict.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
