Online Multiplayer Game Basics [closed]

Question

I'm currently working on a c# online multiplayer game in real-time. The aim is to have client/server based connection using the UDP protocol. So far I've used UDP for players' movements and TCP for events (a player shooting, a player losing life) because I need to be sure such data will arrive to all players connected to the server. I know that UDP is said 'unreliable' and some packets may be lost. But I've read everywhere to never mix TCP and UDP because it can affect the connection.

The main question is how should I organize my network?

UDP is connectionless, how should I save who's is who? Should I save ip adresses of the clients in a list?

Should I use TCP for important events or use UDP? If I need to use UDP, how can I make sure that data will not be lost?

By using both TCP and UDP, I need to save for each player their IP in a list (for UDP) and the TcpClient which is connected in another list (for the UDP). How could I change that to be more effective?

Answer 1

Connections have improved a lot since early game development. In the past the speed advantages of UDP made it a very desirable protocol, even balanced out the reliability issues. However as networks have improved the reasons to shy away from TCP have dissipated.

I would advise picking one of the two protocols and going with it. But mostly because it will simply your network layer and make it easier to debug network issues. When I have to pick between TCP and UDP I make the decision more on how I want my networking logic to flow.

With a UDP based system you do need to do a bit more bookkeeping yourself, but not really enough for it to factor into the decision. A UDP game flows more like independent cells that all happen to share the same world. You don't want a lot of reactive logic (after he does this, i do that), if something is dropped or forgotten the game will keep going smoothly.

TCP will give you much more control. Depending on the API and can involve a bit more setup but its worth the effort. TCP lets you work with a networked partner much like you would work with another thread on the same CPU. There is an overhead with everything that you do but it sounds like you already have it working so might as well stick with it.

I generally tend towards UDP myself because its ingrained I think. Also whenever dealing with networking you have to plan for the un-expected, the lost or delayed packet, and UDP helps drive that message home. If you break that rule you will notice right away with UDP, might not with TCP.