Are WebSockets suitable for real-time multiplayer games?

Question

I'm interested in building a small real-time multiplayer game, using HTML5/JavaScript for the client and probably Java for the server software.

I looked into WebSockets a bit, but it appears I had misconceptions on what WebSockets actually are. I had initially thought of WebSockets as just JavaScript's way of handling TCP sockets, just as they are used in Java and other languages, but it appears there is a whole handshaking process that must take place, and each transmission includes much HTTP overhead (and in that case, the benefits over Ajax do not seem as exciting as at a first glance)?

On a related topic, are there any better alternatives to WebSockets for this purpose (real-time multiplayer games in JavaScript)?

Answer 1

WebSockets are the best solution for realtime multiplayer games running in a web browser. As pointed out in the comments there is an initial handshake where the HTTP connection is upgraded but once the connection is established WebSockets offer the lowest latency connection mechanism for bi-directional communication between a server and a client.

I'd recommend you watch this: https://www.youtube.com/watch?v=_t28OPQlZK4&feature=youtu.be

Have a look at:

• http://browserquest.mozilla.org/ code available here: https://github.com/mozilla/BrowserQuest
• https://chrome.com/supersyncsports/

The only raw TCP solution would be to use a plugin which supports some kind of TCPClient object. I'd recommend you try out WebSockets.

You can find a number of options here. Just search for WebSockets within the page.

Also take a look at WebRTC. Depending on the purpose of your game and whether you need your server to manage game state, you could use this technology for peer-to-peer communication. You may still need a solution to handle putting players into groups - in that case WebSockets is the fastest/best solution.

Answer 2

Basically, you have 3 options at the time of this writing:

WebSockets

WebSockets is a lightweight messaging protocol that utilizes TCP, rather than a Javascript implementation of TCP sockets, as you've noted. However, beyond the initial handshake, there are no HTTP headers being passed to and fro beyond that point. Once the connection is established, data passes freely, with minimal overhead.

Long-polling

Long-polling, in a nutshell, involves the client polling the server for new information periodically with HTTP requests. This is extremely expensive in terms of CPU and bandwidth, as you're sending a hefty new HTTP header each time. This is essentially your only option when it comes to older browsers, and libraries such as Socket.io use long-polling as a fallback in these cases.

WebRTC

In addition to what has been mentioned already, WebRTC allows for communication via UDP. UDP has long been used in multiplayer games in non web-based environments because of its low overhead (relative to TCP), low latency, and non-blocking nature.

TCP "guarantees" that each packet will arrive (save for catastrophic network failure), and that they will always arrive in the order that they were sent. This is great for critical information such as registering scores, hits, chat, and so on.

UDP, on the other hand, has no such guarantees. Packets can arrive in any order, or not at all. This is actually useful when it comes to less critical data that is sent at a high frequency, and needs to arrive as quickly as possible, such as player positions or inputs. The reason being that TCP streams are blocked if a single packet gets delayed during transport, resulting in large gaps in game state updates. With UDP, you can simply ignore packets that arrive late (or not at all), and carry on with the very next one you receive, creating a smoother experience for the player.

At the time of this writing, WebSockets are probably your best bet, though WebRTC adoption is expanding quickly, and may actually be preferable by the time you're done with your game, so that's something to consider.

Answer 3

I'm not sure if WebSockets are still the best tool for networking a real-time multiplayer these days (2017). WebRTC is a newer technology which offers the potential of much higher performance. And these days, WebRTC is also easier to work with thanks to the following libraries:

• node-webrtc simplifies server-side networking
• webrtc-native which also provides a server-side library, and could be faster as its name suggests
• electron-webrtc provides an implementation which is a good match if you want to package your game using electron

Alternatively, if you want to be spared the actual details of networking implementation, and you're looking for a library which provides a higher-level multiplayer interface, take a look at Lance.gg. (disclaimer: I am one of the contributors).

Answer 4

Multiplayer games requires the server to send periodic snapshots of the world state to the client. In the context of a browser HTML/js application you have little choices: polling, websocket or write your own plugin to extend browser capabilities.

The HTTP polling such as BOSH or Bayeux are sophisticated but introduces network overhead and latency. The websocket was designed to overcome their limitation and is definitely more responsive.

Libraries, such as cometd or socket io, provide an abstraction of the transport and solve the browser compatibility issues for you. On top of that, it allows to switch between the underlying transports and compare their performance without effort.

I coded multiplayer arcade game with socket.io and usual measure 2ms latency with a websocket and around 30ms with xhr-polling on lan. It's enough for a multiplayer games.

I suggest you to have a look to nodejs and socket.io in order to be able to share code between the client and the server, you also car borrow some multiplayer code at [3].

Answer 5

If you are planing to use JavaScript for your game (as you are) then WebSocket is the best choice for you. And if you want to support older version of Internet Explorer then think of Signal R system Microsoft developed. They are using WebSocket under the hood, but they also have a few fall back options...so protocol will use the best available solution available.

http://signalr.net/