0
\$\begingroup\$

My RTS game abides by the lockstep system so keeping everyone up to date is import and guaranteeing the safe arrival of packets would make my life a lot easier. With that said, I still need decent speed so players won't have to wait too long before commands are registered, preferably under 300ms. Basically, my system is set up like this: 10 packets are sent out every second by the server which will be based upon for players' simulations. Every time a player makes a command, a packet is sent to the server as well so a player with 180 apm would send 3 packets a second. I plan to have 16 player games. Is it plausible to have a player-hosted server send out 10 packets and take in 3 using TCP and have the round trip times for most players be under 300ms?

I think the 10p/s out for each player seems kind of harsh so this could use UDP but is it at least possible for players to send their commands using TCP and get responses in reasonable times?

To sum up my concerns over using TCP, if a client has 200ms RTT using UDP, how much will his RTT be using TCP? In addition, how much more bandwidth will it use?

Improve this question
\$\endgroup\$

2 Answers 2

Reset to default
0
\$\begingroup\$

TCP guarantees delivery, and when there are problems that aspect will cause hangups as the whole thing stops to make sure everything got through. If it's going to be just a few dropped packets here and there, UDP will keep your speed up.

Here's a detailed explanation of why TCP should not be used: https://gafferongames.com/post/udp_vs_tcp/

It also links to information on how to use UDP properly. Here's small bit to get you started:

Firstly, TCP is a stream protocol, so you just write bytes to a stream, and TCP makes sure that they get across to the other side. Since IP is built on packets, and TCP is built on top of IP, TCP must therefore break your stream of data up into packets. So, some internal TCP code queues up the data you send, then when enough data is pending the queue, it sends a packet to the other machine.

This can be a problem for multiplayer games if you are sending very small packets. What can happen here is that TCP may decide it’s not going to send data until you have buffered up enough data to make a reasonably sized packet to send over the network.

Improve this answer
\$\endgroup\$
9
  • 1
    \$\begingroup\$ My main concern is how much the latency will be affected under normal circumstances. My game uses the lockstep system so players have to wait for all packets before simulating anyways. \$\endgroup\$
    – JPtheK9
    Feb 27, 2015 at 3:02
  • \$\begingroup\$ There's a reason RTSs use UDP. Don't try to reinvent the wheel; TCP is not good for latency-sensitive gaming. \$\endgroup\$
    – Almo ♦
    Feb 27, 2015 at 3:58
  • 2
    \$\begingroup\$ Actually, using UDP would kind of be like reinventing the wheel. With TCP, I could just send out a packet and forget about it. With UDP, there's no guarantee of packet arrival so I have to time a check based on previously measured ping to see if I need to resend the packet. Thanks for the input but do you have a reason? \$\endgroup\$
    – JPtheK9
    Feb 27, 2015 at 4:04
  • \$\begingroup\$ I've been in the game industry since 2000, and whenever I read about networking in games that are not latency-tolerant, they always say "use UDP, or you'll regret it". Using UDP is a hassle, but it's necessary in latency-intolerant apps. You're NOT reinventing the wheel with UDP because that's how it's been done since the early days. Descent II wasn't using TCP for its networking, and neither is Starcraft II. \$\endgroup\$
    – Almo ♦
    Feb 27, 2015 at 4:10
  • 1
    \$\begingroup\$ RTSs traditionally rely on lockstep, which does not tolerate "just a few dropped packets here and there" at all. \$\endgroup\$
    – Kromster
    Aug 6, 2018 at 17:26
0
\$\begingroup\$

If you have a lock-step game, that means that every packet MUST be delivered, intact and executed in order. Otherwise lockstep can not continue. This means that even if you go for UDP, you will still have to reinvent the wheel of TCP by yourself (guaranteed sequence, guaranteed delivery, etc.). I would not want to spend my time on this instead of coding the actual game.

Better go for TCP and keep your code simpler. Let the proven technology take care of deliveries. (and turn off packet batching, which is on by default in many implementations. E.g. in Overbyte that is achieved by setting [wsoTcpNoDelay] // Send packets ASAP (disables Nagle's algorithm))

As for mitigating lag - do the client-side confirmation of players commands immediately (so player has feedback) and do the actual command once other peers accept it - that lag won't be very noticeable.

P.S. Above said based on our own RTS experience with up to 12 players on a map, running up to 30 ticks/second.

Improve this answer
\$\endgroup\$

You must log in to answer this question.

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