20 minutes ago, Hashbrown said:

I'm guessing the answer to this question depends on the game. As far I've read so far (and I might be wrong): Websockets behave similar to TCP. Which means some packets are held back and sent later in specific situations.

UDP on the other hand sends all packets without holding any, at the expense of losing some of them. I've also noticed that most developers seem to recommend using UDP at all cost, and that UDP is not available for web.

If my understanding is correct, what kind of games can I reliably make with Websockets? Is the performance of websockets too bad for fps, rts, or real-time rpg games?

There was a discussion recently on making TCP-websockets behave a little more UDP-like. If you're doing a networking model that works well with unreliable streams (e.g. shooters), then this might be worth a look:

People have developed fast paced shooters on Websockets, despite TCP not being ideal.
RTS games often use lock-step networking models that work well on TCP.

Hi Hashbrown.

Regarding FPSs:

I’m the one who started the previous thread linked in Hodgman’s post. Since that thread, I’ve quietly done steady work on the game. It's not a FPS, but the mechanics and networking code are similar.

We did a small WebSocket multiplayer test last week and it went really well. That was five players in Jordan connecting to a VPS in France. You can get an idea of just how “fast paced” the game is here. The server is off at the moment, but you can still see how responsive the movement is, the use of inertia, projectile speed, etc. - it's less twitched-based than some shooters. As mentioned in the thread, I’m round-robining over five WebSocket connections. It’s working well so far, but I plucked that number right out of a hat - I haven't tested other configurations to make any kind of comparison, and I haven't tested with a large number of players. (If you want to observe the networking in action, PM me and I'll figure out a time to have the server on.)

In light of all that, my preliminary observation is that WebSockets could work OK for a FPS. But I think the networking code needs to be extra good (naturally), and there are definitely some allowances I have made because of the less-than-ideal TCP/browser environment. For example, my clients have more authority over their position than is typical in a multiplayer shooter. This mitigates the effect of interruptions in the flow of updates from the client to the server but makes it harder to prevent cheating (a particularly big problem because users can use the browser itself to easily access and change some parts of the game's code).

You should also have a look at multiplayer shooters (2D or 3D) among the ".io" games. That should give you a good idea of what's already been done. In my opinion, most have a sluggish feel. Most don't seem to do any kind of client prediction, but I suspect that has more to do with the way these games are programmed than with limitations imposed by the WebSocket platform itself.

Regarding RTSs and RPGs, these seem like ideal applications for WebSockets.

3 hours ago, Hashbrown said:

I actually did check out the link to the game and it's definitely playing very smoothly, no hick ups at all.

It certainly should be smooth because you weren't connected to any server!  In other words, there was no networking occurring. Furthermore, client-side prediction means that even when connected, your own movement should seem totally smooth unless there are significant hiccups in the connection prompting the sever to force a re-sync of the player's position. The real test, then, is whether other players' movements seems smooth (especially because although they are interpolated on the server, they are extrapolated on the client). Unfortunately, until I add bots, there will be no way to see that without other players connected. My intent behind including the link was (besides the shameless plug) to show you a kind of movement mechanics that can work OK via less-than-ideal WebSockets (albeit five per player), at least according to my limited, small-scale testing. Inertia and acceleration help mitigate latency; that's how SubSpace was able support servers of 50 players on dial-up connections with RTTs of 200-400ms twenty years ago. But if you want players to instantaneously change their velocity (i.e. your gameplay centers on reflexes), then you probably need optimal networking conditions.

I'm breaking a lot of rules (e.g. using TCP and using a virtual private server), so it'll be interesting to see just how well this game does or doesn't function on a larger scale. Certainly, I'm assuming that players will have reasonably stable connections to a sever in their general region (so no mobile players?).

Quote

I read in your post that you were planning on letting browser clients connect via websockets but native desktop via UDP. Would that mean desktop clients will always have an advantage in terms of latency over browser clients?

I'm not quite sure how much, if at all, round-trip-time will be affected. The development of the UDP client is behind the development of the WebSocket client, so currently it's very hard to test them together. I fully expect UDP players to have less issues with lag between them and the server (because of no head-of-line blocking and because of faster re-transmission of lost packets), but it remains to be seen whether this will translate to any real advantage in-game because they are also, to some extent, at the mercy of the other players' connections.

As I mentioned in the other thread, the game does support UDP-only servers because if it became popular, I can envisage a demand for them. Whoever runs a sever can select what types of connections to allow.

The obvious advantage will be had by a player hosting a non-dedicated server, who will be the only one seeing the true positions of other players. I'm not too worried about this as it could be an incentive for players to go to the trouble of hosting their own games.

Of course, for a true UDP experience in the browser, there's always WebRTC. I experimented with it before beginning with WebSockets, but I thought there were some obstacles that are relatively insurmountable for a lowly hobbyist, namely NAT-traversal and the need to run your own TURN servers, the difficulty of integrating WebRTC with C++, and the general lack of support, documentation, and communal experience. WebRTC seems like completely uncharted territory - I'm not aware of any game currently supporting it, but I'm sure other people know more than I do.

Another thought to add: There is a fairly serious FPS around at the moment that uses or was using TCP. It's called Ironsight. I haven't followed it, but I saw that people were complaining about the TCP and that the developers made an (unsuccessful?) effort to switch to UDP. It's probably be worth looking into if your interested in exploring the feasibility of TCP in shooter.

There are no hard and fast "rules" so you can't really be "breaking the rules" ?

However, there are hard-won "best practices" that, 99 times out of 100, end up giving the best experience to players.

You don't have to follow the best practices -- it entirely depends on what your most important goals are. Turn based game on UDP? Fighting game on TCP? RPG on top of video streaming? Whatever works best for YOUR GAME should be what you use. Your game has gameplay, and simulation, and graphics, but also a target platform, operating cost, and community/player base, which are just as important.

It does help to understand what the failure modes are for the different kinds of transport, so that you can define your simulation/gameplay to work well under the particular specifics of your chosen implementation. Tp me, that's what this thread is about: "If I want to do an FPS on TCP, what should I think about?" It's not about saying "all FPS-es on TCP are doomed from the start" ?

On 2/19/2019 at 3:36 AM, frob said:

The retransmission timeout (also called RTO) is initially 3 seconds, then 6 seconds, then 12 seconds. That is, if you don't hear an acknowledgement after 3 seconds the data is retransmitted, then again after 6 more seconds (about 9 seconds total), then again after 12 seconds (about 21 total) then wait about 12 more seconds (about 33 seconds total) before declaring the connection dead. 

Are you sure that is the case for WebSockets? I haven't found any sources to confirm it, and it doesn't quite line up with my own experiments/observations.