1
\$\begingroup\$

I am writing a small multiplayer game in C++. But I am confused about how to send info about gun shots to achieve best performance. I am thinking of different ways to do that: Let's say we have a gun that can shoot 10 times per second (when left mouse button is held).

  • When user presses LMB game sends TCP packet telling that shooting has started. When user releases LMB game send TCP packet telling that shooting has stopped.
  • When LMB is held game send UDP packet every (1/10) sec telling about one shot.
  • When LMB is held game send TCP packet every (1/10) sec telling about one shot.

I think that the last one is the best because it allows to check hits on the server side, not on the client side (cause this way it can be easily hacked). But I am not sure if TCP can handle 10 packets per second. What do you suggest?

\$\endgroup\$
4
  • 2
    \$\begingroup\$ Just a couple things you may want to consider: What happens when you lose a shot packet with UDP? What happens if the client sends 100 shot packets all at the same time with either UDP or TCP? \$\endgroup\$
    – UnderscoreZero
    Commented Nov 22, 2013 at 18:14
  • 1
    \$\begingroup\$ I got it, udp won't work for shots. But why client should send 100 shot packets all at the same time with either UDP or TCP? Do you mean hacked client or what? \$\endgroup\$
    – iamnp
    Commented Nov 22, 2013 at 18:24
  • 3
    \$\begingroup\$ @iamnp: Of course UDP works for shots. You just have to handle the detection and retransmission of lost packets yourself. Networking for Game Programmers \$\endgroup\$
    – Sean Middleditch
    Commented Nov 22, 2013 at 18:41
  • 1
    \$\begingroup\$ Whether TCP or UDP, I don't think you want the client to say "user has fired a shot". The client should say "user has pressed the fire button" and "user has released the fire button". That way, the server can say "Sorry, your gun has no bullets... no shots for you!" Don't trust the client to call the shots. \$\endgroup\$
    – Incredulous Monk
    Commented Nov 27, 2013 at 6:40

3 Answers 3

Reset to default
2
\$\begingroup\$

UDP does not ensure that the package will arrive properly or that will arrive ordered, but is faster than TCP. TCP ensures the aforementioned features but is slower because of acks. Usually, action based games like FPS should use UDP because of the volume of data that must be sent/received over network. On the other hand, turn-based games should use TCP because the demands are more loose. Since your game is a shooter I would suggest you go for UDP at least for the shot data. But, you should profile if the ratio of lost packets is adequate and make aditional code to handle the packet loss. Some libraries implement reliable UPD which is an UDP that ensures the arrival of packages.

As a rule of thumb, use UDP for data which you don't mind to lose and TCP for data which is necessary to arrive at destiny.

\$\endgroup\$
1
\$\begingroup\$

I believe losing a message about a gun shot event cannot be tolerated since it has the potential of affecting the player's responses, unlike the position updates.

You can use TCP to let the client know about the 'shooting started' event. When the enemy player stops firing, send the 'shooting finished' event. None of the packages will be lost, therefore, the game will stay synchronized. However, you can implement your own reliable application layer protocol using UDP if the TCP performance seems low.

\$\endgroup\$
1
\$\begingroup\$

In a project I once was involved (not game related) they decided to send each UDP message twice to reduce losses with an event id so if both messages were received the receiver could ignore the second, sounds basic but it did the trick.

first define burst:

shotgun and sniper has a burst of one bullet

smg has a burst of 5 (?!)

for each bullet send a UDP, for each burst send a TCP. the UDP is only for show the TCP is for synchronization.

\$\endgroup\$

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .