I've been doing a lot of research on how to implement a game server to support a web based game in the vibe of surviv.io, or zombsroyaleio. There are so many ressources out there, but apparently surviv.io is built with NodeJS using Websockets. That implies also that they are built on TCP protocol.

They might not look like big titles but they surely look very steady (from my point of view) and I feel like they do deal with classic Fast Paced multiplayer concepts such as Client-side prediction, interpolation, and potentially lag compensation. 

During my research, there seems to be that constant debate on UDP over TCP. To sum it all up, it seems that TCP is not appropriate for fast twitching games, however I do believe they fall into that category.

How can they get away with TCP? Is this debate actually now outdated now we have better internet connections?

The .io games are not really 'fast twitching' games. The in-game 'characters' move in relatively slow and predictable ways and the game is very suited to rendering other players slightly 'in arrears' with interpolation to smooth them out. The amount of bandwidth needed is relatively low and the data is being sent regularly, so TCP is likely to be just fine unless everyone is playing over a wireless connection.

UDP is still very important for super-fast games where latency truly matters, but these games don't fall into that category. They might perform better with UDP, but they don't require it.

This debate will pretty much never die.  Even with the current environment of high speed internet and low pings, there is still enough of a difference which folks can argue around forever.  Personally I see it as a matter of degree's anymore.  "Technically" UDP is the better technology for games and it avoids a number of the downsides of TCP but the differences at the end of the day are fairly small at this point and getting smaller.

The primary issue which folks bring up most often is that because TCP is lossless it will sometimes block IO when a packet is dropped which can increase the effective latency considerably.  Such issues can cause hickups in the gameplay and if they are bad enough make a game unplayable.  UDP can avoid these problems because most implementations send a steady stream of packets with updated information and missing one packet doesn't hold up later packets which contain more recent data such that the missed packet can safely be ignored.  There are a number of reasons that this is becoming less of an issue, at least for games.

The primary reason that this is becoming 'less' of an issue, though by no means gone, is that the internet in general has changed quite a bit over time.  Packet loss is actually not particularly common anymore and actually less likely with TCP due to optimizations to the routers which try there best to prevent dropped packets on TCP specifically.  Historically I used to measure between 1 and 5 % packet loss from most ISP's depending on time of day, anymore it is at worst around 2% unless they are having actual issues.  Also, many routers have a reliability system where rather than waiting on the client or server to resend a packet the router which dropped the packet will automatically re-request it from the closest link.  Often such corrections are sub millisecond and barely notable.  Finally, even if all the routers are ancient and there is high loss rate, the normal pings between client and server are considerably lower such that the corrections happen in 10-20 ms versus what we used to deal with around 100+ ms.

Now, as Kylotan says, super fast games can always benefit from going UDP.  I might argue just how much but that is still a fairly reasonable fact.  But, for the reasons I point out above (and lots of other reasons), it is becoming less of an issue and may not matter for most games moving forward.

A game like Slyther.io will lag and then catch up when the TCP connection has lag, so you can easily tell how laggy it is.

However, a better way of hiding latency is to run the game loop and simulation at a fixed rate, NO MATTER WHAT, and then de-marshal, receive, and handle messages asynchronously as you receive them. (Although "handle a message" might mean "apply a state at some step number in the past" which may require re-simulating.)

In general, as long as the input-simulate-render loop runs smoothly on the local machine, a game will feel pretty smooth, and you can hide all kinds of bad latency spikes without players noticing, because 99 times out of 100, that latency spike was while you were running a transport distance between point A and point B and it totally didn't matter for gameplay anyway.

If your game is Overwatch, then you'd still be crazy to use TCP, though. Meanwhile, if your game is StarCraft or World of Warcraft, you'd be crazy NOT to use TCP.

Thank you all very much for your answers. Great breakdown on the current state of TCP vs UDP, and that yes my first guess about current state of internet speed was right.

It's true, I think I need to revise my definition of Fast Paced Multiplayer. When I look at surviv.io (and trust me I played that one a lot!) I do feel that movements are very tight and precise and shots are very much on point. It does feel like a minimal PUBG where shots are crucial. Compared to slither.io which is way way more forgiving in terms of movement, and lags.

But you might be right in the sense that big FPS title might be moving at a higher pace in general and that is maybe where the difference lies.

What I appreciate with surviv.io is that it's a great example of what can be done nowadays on the web in terms of let's call it "semi-fast twitch" multiplayer shooter.

I do feel that movements are very tight and precise and shots are very much on point.

That can be almost entirely delivered on the client side, though!

31 minutes ago, hplus0603 said:

 

 

That can be almost entirely delivered on the client side, though!

Are you suggesting a non fully authoritative server, but more logic on the client side? So more cheating allowed?

I've actually looked deeply in their code on the client, and I couldn't exactly find any clues that lead to that. But maybe I'm wrong.

The model of "run the simulation smoothly, and pay attention to network data whenever you asynchronously receive it" model doesn't necessarily need to allow cheating, but it does need to mask lag, and show entities in modes they might not actually have been in. How you choose to resolve that when player/players interact, may open you up to cheating.

I tried the game, and I immediately died from lag, so I guess they don't ?