I'm making a multiplayer synchronisation for my game and I have a goal to make players be able to play on 3G. It's a platformer shooter. I'm currently planning to send a partial update(players pos + velocity) and a full snapshot every few seconds right now. I heard 3G has some latency issues. What should I know about it before making? Should I avoid TCP and use UDP only or no?
I'm hoping someone with more experience could tell something useful.
And by the way, should I even be aiming to support 3G? Is it still widely used? Didn't HSPA/HSDPA took it over?
HSDPA isn't THAT much lower latency than "regular 3G" -- depending on where in the world you are, somewhat.
In addition to latency problems for mobile connections, you also have intermittency problems (packets may stop flowing and then come back, sometimes in a storm -- especially when on a train or bus.)
You also have volume problems -- games that send and receive lots of data may cost players a lot of money in metered data charges.
I'm assuming you already know about the other challenges of mobile development (battery drain, overheating, latency of finger detection, etc.)
So, that being said, I'd recommend using UDP. I'd recommend making the send rate low (5-10 packets per second) and get as much smarts as you can into those packets. It's totally OK to send input/command/info data for many simulation steps in a single packet. Make sure there's a single network packet that contains all the updates/messages regarding all the other players, rather than trying to split that into multiple packets. As long as that's solved, the actual size of the packet isn't as important -- 500 bytes or 1000 bytes will not have different latency (although of course 500 bytes will cost the player half as much as 1000 bytes :-)
Finally, the round-trip-time may be as much as 500 milliseconds. You may want to tune your game and/or design the control scheme to work around that.
There's really not much point sending more than 2 packets/second when latency is up around the 500ms mark.
Well, yes, there is, because you can avoid some latency by pipelining the updates.
The point is more one of relative gains: When the transmission latency is 200 milliseconds, the additional difference between 10 packets a second (100 ms additional latency) and 40 packets per second (25 ms additional latency) is quite small, but the 4x packet rate (and data plan consumption) hurts!
Do I really have to use UDP only and implement reliability myself? Kryonet uses separate ports for UDP and TCP. So if TCP packet gets lost, then congestion won't affect UDP packets and they won't get stuck while waiting. So could I just send unimportant packets through UDP and important packets through TCP?
Kryonet uses separate ports for UDP and TCP. So if TCP packet gets lost, then congestion won't affect UDP packets and they won't get stuck while waiting. So could I just send unimportant packets through UDP and important packets through TCP?
They are both traveling over the same underlying wireless network, so dropped packets are going to affect both pretty much equally.
The advantage of UDP is that dropped packets don't cause the connection to back up (provided you don't in fact need the previous packets). To benefit from this, you'd want to send state updates over UDP (since you only need the most recent state), and any transactional commands over TCP (since those must arrive, and must arrive in order).
UDP ports and TCP ports are independent. Even if you have traffic to TCP port 1234 drop packets, that won't affect traffic to UDP port 1234 (and vice versa.)
You *can* use both UDP and TCP. It can totally work. In general, once you get down to optimization and building networking specialized for your game, you'll find that you actually want slightly different semantics than TCP (for example, ordering may not be as important as exactly-once delivery.) Exactly how much this matters to you, only you can decide.
