In a FPS game like Battlefield or Arma, when playing online, should the bullet trajectory be calculated by the server or by the client?
Note that most of us cannot answers specific questions about either of the games you mentioned. We aren't the authors of that code and can't reasonably know exactly how it was built.
Generally speaking, there are multiple approaches.
One approach is that the server is authoritative on everything. When a client wants to fire a weapon a round-trip to the server is required. The server tells the client which trajectory to use. This approach adds significant latency to firing. Games that use this approach might hide the latency by animation or a smoke particle effect of the like so that the player doesn't realize that the client is waiting on the server (on well-behaved networks).
Another more complicated approach does firing as part of client-side prediction. The client fires the weapon. It tells the server that it fired the weapon along with information about the specific time of the fire request. The server is then able to simulate the same firing trajectory (or very close to). The server's fire message, when received by the client, is used to adjust the projectile (if necessary). Note that the server should still be in charge of determining what the projectile hits and what the results are. The weakness of this approach is that, in some situations, the client can see a firing effect that is wildly different than what actually happens. However, in most cases the client should see something close to what happens, and the firing will feel instant, which makes this approach "feel" good on low-latency connections.
These are not the only two approaches, nor did I describe the most advanced approaches. Networking games is really hard. There's a good reason that network programmers are some of the best paid engineers in the game industry.
Always assume the client is a lying, cheating, bastard.
The client is responsible for:
- Receiving input from the player (and sending commands to the server, which validates)
- Rendering the known gamestate
The client is in no way allowed to calculate the gamestate except as client-side interpolation for smooth animations.
More than likely, it works like this (major speculations):
Client sends Shoot command to server, along with parameters such as position, direction, velocity, type, etc...
Server accepts command and broadcasts to all players on next frame.
Clients render the shot.
If shot hits a player, server broadcasts kill.
Can't tell for sure though, as I don't have access to the source code.
One thing a lot of people say here and is pretty fangerous is to have the player send information about his state when he shoots. The server is a machine, he can't decide who cheats and who doesn't. "Yes, I really did stand in front of him for 30 seconds without he noticing it, then I shot him in his eye while he was running around in a thight place, looking down...while crouching...on a ledge." You need to store information about the playsrs server side.
What a client should do
- Draw the scene
- Talk with the server, sending him his current position, and receiving the positions of other players
- Handle keyboard and mouse control.
What a server should do
- Have a nice, clean command window.
- Manage collision detection
- Speak with the client
Servers tend to have a better CPU, than clients, so they can manage more complex things, like collision detection, or player movement without having a hard time.