Android game UDP / TCP?

Question

I see that this question has been asked before but the context around the questions are usually vague. I'm looking to build an Android multiplayer real-time game where there is global state that needs to be shared amongst all the clients. Thus, I have a tendency to believe that UDP might not suffice. TCP gives reliability but with the inherent overhead. However, since this is the first time I have tackled such a problem, I'm looking for some feedback from other peoples experiences.

Therefore, (generally) in the context of a multiplayer real-time game on an android smart phone, is the overhead associated with TCP acceptable enough such that the user experience is not affected to such an adverse extent? Also it's worth mentioning that the TCP connection would have to be a persistent connection. Also, would UDP coupled with some reliable custom developed mechanisms be a better approach? Any input would really help me out & would be greatly appreciated.

many thanks indeed

Answer 1

You can see my game (still being developed) - https://market.android.com/details?id=com.reality.weapons.ak47

It uses TCP/IP. You can get feeling about latencies by shooting and observing notification messages in "Battle log".

So far I fairly satisfied. In urban areas with good GSM coverage, round trip

"fire->travel to server->calculation of results->result travel back->show notfication"

usually takes less then 200 ms.

Sometimes it could be 2 sec. But in 99% it is less than 500 ms.

Answer 2

I'm facing the same problem. From the literature review I been doing I suggest you read this article:

"Experiences from Implementing a Mobile Multiplayer Real-Time Game for Wireless Networks with High Latency" - http://www.hindawi.com/journals/ijcgt/2009/530367/

Answer 3

This is not really an android question, though the protocol and other mechanisms you choose will have an effect on the device (e.g. battery life).

What protocol to choose mainly depends on your requirements (average packet size, packets per second on average, whether lost packets are an issue, how much data you will send at once, is jitter an issue, etc). I can give a few pointers though.

Here's a very good article on the Quake3 networking implementation:

http://trac.bookofhook.com/bookofhook/trac.cgi/wiki/Quake3Networking

Simple but effective, I really like it and can only recommend this one.

Here's also a good thread on the topic:

http://www.gamedev.net/topic/319003-mmorpg-and-the-ol-udp-vs-tcp/

Some games use UDP (especially FPS and RTS types), some TCP, and some of them a certain combination of them (e.g. UDP to send game data, TCP for chat and other stuff). Either one can work. You should also keep in mind that users might like to work over 2G, 3G or WiFi networks, and even WiFi networks can be laggy and over capacity. I'd suggest to implement a quick prototype and test it in various network environments.

Answer 4

The best answer is probably "try it and see".

I'm of the opinion that TCP overhead isn't really that big of a deal for most applications. Header size is on the order of 10 bytes larger, and ack messages have to be sent back and forth for each message.

The real killer for a real-time game is going to be latency. UDP is fire-and-forget. That means each message just lags by the transit time between the two nodes. Since TCP requires an ack, a message isn't really considered "sent" until the other side is heard back from.

Generally, the issue between them boils down to error detection. If a message gets lost in the interwebs somehow, how would you like it handled? If every message is fairly vital, then if you use UDP you'd just end up having to implement your own TCP-like protocol on top of it. You might as well use TCP and let the network hardware help you. However, if old messages after the time it takes for several retries (each at network latency) are going to be garbage anyway with new updates coming in, then TCP is a waste of bandwith for you.