4
\$\begingroup\$

In a FPS game like Battlefield or Arma, when playing online, should the bullet trajectory be calculated by the server or by the client?

\$\endgroup\$
  • \$\begingroup\$ I would say that both. Client calculates it, so the gameplay is smooth, and every n-th frame everything is synchronised with the server. \$\endgroup\$ – Mars Feb 4 '16 at 18:09
3
\$\begingroup\$

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.

\$\endgroup\$
18
\$\begingroup\$

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.

\$\endgroup\$
  • \$\begingroup\$ +1 for making me laugh. You touched just the right parts of this problem. \$\endgroup\$ – Bálint Feb 4 '16 at 20:50
  • 2
    \$\begingroup\$ That header? I've made that statement a dozen times this year already. It never ceases to be accurate and straight to the point. \$\endgroup\$ – Draco18s Feb 4 '16 at 20:52
  • \$\begingroup\$ hahaha, I agree 100% , have some more internet points! \$\endgroup\$ – jgallant Feb 4 '16 at 21:03
  • \$\begingroup\$ @Jon Yay internet points! I always wanted those! \$\endgroup\$ – Draco18s Feb 4 '16 at 21:07
3
\$\begingroup\$

More than likely, it works like this (major speculations):

  1. Client sends Shoot command to server, along with parameters such as position, direction, velocity, type, etc...

  2. Server accepts command and broadcasts to all players on next frame.

  3. Clients render the shot.

  4. If shot hits a player, server broadcasts kill.

Can't tell for sure though, as I don't have access to the source code.

\$\endgroup\$
  • \$\begingroup\$ The client only needs to send the "shoot" command; in theory, the server already knows where the client is (position, direction, etc). \$\endgroup\$ – Vaillancourt Feb 4 '16 at 18:25
  • \$\begingroup\$ Yeah, I did put this as my original #2... but then I figured, that could very well depend on the design. For example, a grenade wouldn't immediately know if it hit a person. Personally, I think this question is pretty much worthless in itself -- You would need to tune it to what you are trying to accomplish to get something out of it. As it stands now, all we can provide is a general idea of how it works. \$\endgroup\$ – jgallant Feb 4 '16 at 18:26
2
\$\begingroup\$

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.

\$\endgroup\$

Not the answer you're looking for? Browse other questions tagged or ask your own question.