Jump to content
  • Advertisement
Hashbrown

Can I make Websocket multiplayer games for any genre?

Recommended Posts

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?

Edited by Hashbrown

Share this post


Link to post
Share on other sites
Advertisement
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.

Share this post


Link to post
Share on other sites
4 hours ago, Hodgman said:

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.

Thanks for the answer Hodgman! I'll take a look at the link.

Share this post


Link to post
Share on other sites

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.

Edited by jack_1313

Share this post


Link to post
Share on other sites
6 hours ago, jack_1313 said:

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.

Thank you very much for sharing your experience Jack, this is exactly what I wanted to know. I actually did check out the link to the game and it's definitely playing very smoothly, no hick ups at all.
 

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'd like to take your offer and observe the networking in action, I'll PM you right now and when is a good time.

 

Thanks again Jack!

Share this post


Link to post
Share on other sites
On 2/17/2019 at 12:04 AM, Hashbrown said:

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?

The big issue with TCP (and therefore also WebSocket) is retransmit time when there are network errors.

When data is flowing and there are no network hiccups, which on most networks is the situation most of the time, the data will flow smoothly.

When there are network hiccups, which can happen with network congestion, or with electrical noise, or with other issues, the problem is how data gets retransmitted.

Since these are a stream-based socket they cannot advance until that data is transmitted.  The data flow will stop until the missing data has arrived.  

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. 

Contrast with UDP, where you can continue with missing data, and you can incorporate techniques to automatically retransmit data with every message until acknowledged, or not retransmit non-critical data, or to do other behavior including implement your own RTO similar to what TCP does.

 

Exactly how big the issue is depends on the details.  Can your game design and implementation cope with a 3-second stall?  Does it saturate the network, increasing the likelihood of stalls?  Will your players be on networks that are more prone to communications issues?

 

Share this post


Link to post
Share on other sites
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.

Edited by jack_1313

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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" 🙂

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!