tags:

views:

109

answers:

3

Hey guys,

Suppose you were forced to use TCP sockets over UDP sockets (ie: something that Silverlight insists on). Would it be possible to create a multiplayer game that involves sending real time positional updates to up to say eight players so that each player could accurately see every other player in real time, even though UDP would be the better protocol to use? Given the option, would you wish to go as far as to select a different technology (ie: Java), simply to gain UDP support?

Thanks, Nick

A: 

As long as a few milliseconds aren't important i see no reason to use UDP.

Marcus Johansson
A: 

It depends on how fast of real-time you are looking at. For example, if you try to make a space battle, and everyone is close, but moving at a high speed, then you may find that the milliseconds difference makes a difference, but, if you are doing something like an auto racing game then it won't make any difference, so TCP is fine.

So, try it, get some numbers and decide if it is acceptable.

The bigger problem will be the difference in bandwidth, so, if one person is playing over a really slow connection, and everyone else are on very fast connections, then that slower player will be a problem. You may need to scale the updates to the slowest connection, and you may find that TCP/UDP issues are not enough of a concern, as the difference in connection speeds are a far bigger problem.

So, test with various connection speeds, with differing numbers of users, each with their own connection speeds, and see if, as one user, the game is still enjoyable.

UPDATE

It is not bandwidth that will be the concern, but the latency, as was pointed out in a comment. I had picked the wrong term, as several people might be able to respond quickly and be closer to real-time, but one user may be much slower, perhaps on a congested network, slow computer, or whatever, but they may only send updates every 1000ms, whereas everyone else is doing it every 100ms.

James Black
As far as the amount of data to transfer is not large, it is not connection speed in bits per seconds per-se that is important, but connection latency: the *ping*.
Didier Trosset
@Didier Trosset - Thank you for the correction, I will make the change. Latency was my concern, I picked the wrong term.
James Black
A: 

To receive UDP packets, you must have a public IP address.

To receive UDP packets, you need to be able to listen on a port. Not all frameworks in all environments can do this, often for security reasons and such.

As you describe Silverlight as a target platform, we can anticipate that this won't always be the case for your players.

Use TCP.

As an alternative to Silverlight, you might look at Haxe (or Flash).

(From the comments, there is mention of STUN and stuff; that's an interesting if difficult angle to pursue.)

Will
How does TCP work without a public IP address? I need to have a public IP address to do any internet at all.
Ishtar
@Ishtar, no, the client (e.g. the silverlight applet in the browser) makes an *outgoing* TCP connection to your server. Only your server needs a public IP address.
Will
http://www.youtube.com/watch?v=LGnJw9rtjas
Will
@Will - I still need a public IP address for the IP protocol to work. My router might forward it to my private IP address, but my router, and thus me too, need a public IP address. There is little difference in TCP and UDP for that matter. In fact TCP's handshake would be harder then using UDP.
Ishtar
Ishtar, for TCP to work, you need one end to have an accessible IP address (i.e. server); for UDP, *both* ends need accessible IP addresses. WWW - your browser - work on this principle.
Will
@Ishtar, I think I understand what you are getting it. NAT and other proxies allow many clients to be behind a single IP address. Oh I see you're not the original poster, you really ought to read up on the internet. Good luck having UDP packets received by something running in your browser.
Will
I was under the impression that NAT can handle UDP? As long as you've got a server involved, rather than all peers chatting to eachother, of course. And there's also the possibility of using STUN...
snemarch
@snemarch, yeah there's often configuration in your home broadband router to allow some UDP forwarding e.g. for well-known game networks. Its not something a smalltime game can rely upon all the users configuring, I'd say.
Will
@Will - I think you mean something different with public IP address. It's not that hard to make an applet send and receive UDP packets to/from a server. It depends on your firewall and your router doing NAT, not on a public IP address(?).
Ishtar
@Will: I'm not talking about manual portforwarding, I'm talking about NAT. Even if I'm behind a router with no forwarding, I should be able to get replies once I've sent an UDP package to a server. It requires that the server isn't behind NAT, or has proper portforwarding.
snemarch