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 if I fire machinegun and keep moving my mouse?

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.

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.

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.

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.

LMB is probably Left Mouse Button.

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.

You should probably use a combination of dead reckoning and timestamped messages for that kind of game.

Let me see if I got it right:

When connecting to the server your local time will get sync'ed to the server's.
Your client's time will be about PING milliseconds behind the server's. When you send a "shoot bullet" message to the server, add your local timestamp, position and direction. When the message arrives at the server it can look up how the gamestate was at that time (the server's time will be about 2*PING in the future at that point) and see if the shot hit something.

Feel free to correct me. Haven't done this for some time.