10 Player(instanced) 3D Game, would TCP Suffice?

Networking & Multiplayer
#1

I’ve been doing a lot of research on TCP/UDP/RUDP lately and most of it is because my friend who is a Unity freak is near-completion of this MoBA(Multiplayer online Battle Arena) single-player prototype and has asked me to work on the server-side of the networking while he writes the Client-API. I told him that I was up to the challenge, mostly for a learning experience, but helping him out was definitely on my mind. I’m fairly familiar with standard IO TCP Networking, however the problem with that is the Standard IO is blocking, so I would have to study on some NIO Libraries, (Looking at you, Netty). However, some-people have stated that I would be better off using UDP/RUDP.

The problem I’ve found during my studies with UDP/RUDP is the way that messages will occur. Considering we’re going to be working on an authoritative server approach, it’s fairly important that things like movement/item activation arrive. In the order that you activate them. For instance, if a player uses an healing item, then an ability that takes 1.5 seconds to cast. If the ability is casted before the item is consumed for some reason (Typically because of UDP Packets not being ordered) it could cause death, and players screaming “Glitches, Fix them.” – This would lead me to stare at the TCP Connections; However then I would be dealing with Latency problems from my studies. However anything under 200 Latency should be fine for this type of game, and we’re not really expecting people from across the world to play without the expectation of a little lag.

So this brings me down to the question… For this particular application:

  • Handles all users connected - Users not in game don’t transfer any data besides for chat, if being used.
  • Players in a game (Instanced, each game will have its own game-thread) will be moving around constantly in a 2D Environment (3D world using 2 axis’)
  • Ordered arrival of packets is required
  • Losing Data is a Critical problem.

The only reason I’m really asking this question is because of the use of Reliable UDP which crosses out the “Losing data” issue, from my understanding, which makes this a question worth asking.

Sorry, no pictures of the game yet :wink:

#2

If the packets have to arrive in correct order, you should really use TCP, even if its slower then UDP. If you have some data which sometimes can get lost while the game is still playable, you can use 2 connections (UDP and TCP) to handle both, important and unimportant Data (Unimportant may be position-data if you would send them multiple times a second).

If you try to use UDP and still want to get all the data in correct order you will find you implementing a new stack on top of UDP which WILL BE slower then TCP if youre not an professional programmer with excellent networking experiences.

So long answer short: Go with TCP and if its kinda slow try to think about which data you really need and which is just stuff you could calculate yourself on each client.

#3

10 players? Battlefield 1942 could support 64 players, and I recall games with something between 16 to 32 players not being that rare.

I’m not sure why the average playercount has gone down as sharply as it has in later years, but my guess is that the main bottleneck is in the amount of data.

#4

Well, the thing is the (10 players) is instanced. So there could be 72 people connected, and only 40 of them are “In a game” the other 32 would just be idle connections, possibly using chat if nothing else. I’m fairly familiar with TCP becuase I’ve done custom frameworks for Runescape emulators in the past that could hold the 2,000 player cap that Runescape has with ease. The thing with the RSEmulator is though, the movement was so basic. All you had to do was send to the server the tile you wanted to go to, and the server would say yes/no or “well, not there, but here” and then tell the client where to walk. It was nearly impossible to desynch from the client because you walked a steady speed going through tiles per tick, meaning it could all be calculated.

I mean yeah, if you altered your client to move around different than the server did, then obviously you wont be updating correctly.

— All in all, I’m not expecting this project to much over 7-800 players (And that’s being ridiculously generous). However; I want it to feel like it’s done right.

Is there an easy way to make a UDP Socket belong to a TCP Socket? Or perhaps I’m underthinking it. I could create a session class that would hold the players connection to the game. Then from there I can connect UDP. The only thing is knowing which TCP client the UDP packet came from… Could’t you just spoof packets and make other people do whatever you wanted with this?

““From there I can connect UDP”” — Sorry, I just woke up. LOL

#5

@derail on:
It didn’t go down. There’s still quite a few games where 12+ players play together and in Battlefield games 64 players is still supported (and quite often those 64 slot servers are full).
In Guild Wars 2 WvW there are lots of ~50v50 player battles, same in WoW a few years ago (not sure about now, haven’t played in a while).
There are Minecraft servers out there with 100+ slots and some of them really does have 100+ active online players.
I guess it was rather the style of the games that changed, they require more teamwork and strategy which is really hard to do when you try to command 31 people in your team. :slight_smile:
@derail off

#6

If you have client side prediction, you’ll be able to get away with the latency spikes inherent to TCP’s packet retransmission method.

If you’re doing lockstep without prediction, you’ll need UDP. Instead of retransmission, have redundancy through duplication; every packet sent by the client contains everything that occurred since the last ack.