Pages: 1 [2]
  Print  
Author Topic: Multiplayer Roguelike: UDP or TCP  (Read 3530 times)
Smok
Defender
*****
Posts: 64


View Profile
« Reply #15 on: October 02, 2010, 09:49:34 PM »

TCP gurantees that packet reaches destination (if it is possible - computer is online, and connection is up).

So there is no need to send stuff to the client unless something changes. Each time player/monster moves it sends it's position to players that were/are in sight.

That way you save a lot of brandwith.
Logged
Hypatian
Apprentice
*
Posts: 6


View Profile
« Reply #16 on: October 04, 2010, 09:45:07 AM »

Theoretically, using UDP allows you better control over how data gets sent in poor network conditions.  For example, think in terms of the player in an FPS sending information about their own location to the server. In that context, the server is only interested in the latest position and orientation. If a packet gets dropped, you don't want to resend that same information, because it's already old. Instead you want to send the new current information. Other protocols can be tailored for more complex scenarios, but it's still all predicated on the notion that old information is old, and new information is better.

In TCP, every piece if information you send will automatically be re-sent until it gets through. As a result you lose control over what to resend, and you may end up having the pipe clogged with old updates trying to get through. It's even possible that the process could never catch up, and that client would always be replacing very old information (don't think "lag" where things are a little slow and jumpy. Think everything is smooth, but just a little too slow and you keep falling further and further behind.)

However, in practice even very experienced network developers have a hard time implementing their own reliable transport on top of UDP. I will assert that nobody should even consider using UDP unless they have very special needs (primarily multicast), and have been writing network code for quite some time.

An additional factor to consider is that TCP will naturally travel through NAT devices (e.g. the home routers that practically everyone uses), but with UDP you'll need to look into things like UPnP to request a firewall mapping, or users will have to configure port forwarding manually. (This is because with TCP you make a connection and use it, but UDP has no connections. So you have to implement your own connection mechanism. The router understands TCP automatically.  It doesn't understand your protocol.)

Finally, it is perfectly possible to do a certain amount of flow control in TCP as well. Unless you're writing something incredibly latency sensitive, it's even easier to implement than it would be in UDP, simply because it's easier to write within the model of "everything you say will be received in the order you sent it or not at all".

Short story: Don't use UDP unless you want a real challenge, are absolutely sure you understand what you'll have to do, and are absolutely sure you have a need for it.

Unless, of course, you want your game's networking to be as bad as Demigod's was at launch.
« Last Edit: October 06, 2010, 12:14:27 AM by Hypatian » Logged
Smok
Defender
*****
Posts: 64


View Profile
« Reply #17 on: October 04, 2010, 12:20:27 PM »

Thanks!

That was the reply i needed. Im convinced to use TCP now, cause pushing packets behind NAT isn't really stuff I want to code myself.
Logged
Pages: 1 [2]
  Print  
 
Jump to: