Multiplayer JS Games Mini Course

I started a new video mini-course "Multiplayer JS Games". So far there are 4 lessons (more than an hour of video) released on a YouTube channel. The course shows how to create a multiplayer game from a scratch and learn EcmaScript-2015 syntax in practice. Check it out!

Lesson 1: Client-server handshake

Learn how to set up project and build a socket-io / io.js 'Hello World' application.


Lesson 2: Starting game

Once two players are connected to the server they can start to play. Let's start the game!


Lesson 3: Making turns

We'll learn how to capture the turns and how to loop through the rounds of a game.


Lesson 4: Win conditions

(not published yet)The game is all about winning or losing. Let's implement the end-game check and tell the results to the players

Lesson 5: Tidying up

(not yet released) Let's make our code a bit friendlier and UI a bit nicer.

Lesson 6: Handling disconnects

(not yet released) If your opponent disconnects you wouldn't want to wait for his turn forever. Implement disconnect handling.

Lesson 7: Logging in

(not yet released) All users are guests, wouldn't it be nice to give them the real names? We're introducing authentication through HTML form in this lesson.

Lesson 8: Leaving localhost

(not yet released) The game is ready for sharing with friends, but that will be hard to do on localhost. In this video we'll show how to deploy your game to AWS.

Lesson 9: Facebook

(not yet released) Learn how to deploy your game to Facebook!

Lesson 10: Mobile devices

(not yet released) Learn how to use PhoneGap (aka Apache Cordova) to deploy your game to iOS and Android.

Starting YouTube Channel

Last few months I was experimenting a lot with video tutorials and webinars. Started as a hobby, ended up as a mini-studio. I tried various formats and recorded two Udemy courses on JavaScript and Grunt.js, and that's just a start.

Today I've started a separate YouTube stream to share my tutorials. This time it is my favorite subject - Game Development with JavaScript. Unlike the book, the tutorial series puts a strong focus on multiplayer. With the development of Node.js and NoSQL databases that allow to scale your platform so easily - multiplayer game dev becomes so much easier!

Subscribe if you like it!

Video posting has a huge potential, with its limitations of course. For example, I still don't like to read the code from streaming video. Everybody reads at his own pace: for some the code might be obvious and others will need to spend more time getting through the lines.

I found that the best kind of remote learning (because nothing can beat working together at the same desk and sharing the same white board) will be videos + github + small e-book guides if you have to refresh the knowledge.

Right now we are preparing for a big 25-hours course on multiplayer game dev that will combine all our experience in web graphics and animation, networking, design of distributed systems, cloud deployments and of course building game mechanics.

What's new in Socket.IO 1.0

I first stumbled upon Socket.IO when I was writing my book. The chapter was devoted to making a multiplayer version of a standalone HTML5 game. I built up a solid plan: describing transports, implementing ajax-longpoll, some notes about WebSockets (it was 2012, so WebSockets were not yet production-ready especially for mobile devices), and finally writing some logic on top of it. Then I saw Socket.IO and... why would I spend fifty pages writing about transports if I could spend five writing about Socket.IO instead?

This tool was simply great. The API was clean and intuitive and coding client-server calls felt natural. Of course it had its own problems. I remember spending an evening to debug it with my Samsung Galaxy v1 that was randomly breaking connections, but it worked at the end.

Then I forgot about it for some time. Couple of months ago I was conducting a "Node.js Bootcamp" training and Socket.IO was a part of my program. During the presentation one of my students told: "Socket.IO is dead, Guillermo is not updating it, just look at github page". And indeed, there was not to much activity in the github project.

Luckily, this was in no way the end of life for Socket.IO but rather the preparation for a major rebirth. Socket.IO 1.0 has landed just few weeks ago to show everyone that "the event emitter of the web" is alive and well.

This post is about the changes in Socket.IO 1.0 compared to the older versions. It covers both the changes in the architecture, npm module ecosystem as well as changes in API.

What's Socket.IO

Socket.IO is a JavaScript library that implements a real time communication between a browser and a server. It abstracts-out the details of underlying transport and provides some higher level abstractions like broadcasts, namespaces and rooms. Socket.IO is both a client and server library. The server by default is Node.js, however other third party ports are available. For example, you can run a Socket.IO server in Java and connect to it from the native ObjectiveC client.

The basic code for both client and a server is very straightforward and based on the idea of emitted events. You emit events on one side of the wire and get them on the other. As simple as that.


var socket = io();
  socket.emit('greeting', 'Hello, my name is Billy');
  socket.on('message', function(msg) {


io.on('connection', function(socket){
  socket.on('greeting', function(text) {
      socket.emit('message', 'glad to see you');

This code (omitting some trivial setup) is enough to start communication between a client and a server. The client initiates a connection and sends a greeting to the server. Server gets the greeting and replies with "glad to see you".

Note. If you did not write any Socket.IO apps before, a great place to start is the official tutorial that shows how to create a simple chat application -

New Modules

Before 1.0 Socket.IO was distributed as solid npm package that implemented every bit of functionality inside.

In Socket.IO 1.0 the code broke up into several small reusable modules less dependent on each other. The most notable shift is the extraction of low-level transport details into a separate project called Engine.IO. Now Socket.IO's job is to provide only higher-level facilities: multiplexing, reconnection, rooms, broadcasting, etc. All the heavy-lifting related to transports is done by Engine.IO.

This change is purely internal. If you are writing your code against Socket.IO you will not see the difference, as Engine.IO is not exposed "as is" to the client code. It is and important and very well-thought architectural change as it makes the overall project more maintainable. Besides, now there's a clear borders of components' responsibilities: Socket.IO is doing logic, Engine.IO is doing communication.

Socket.IO modules Ecosystem

Socket.IO and Engine.IO both are broken into core ( and, clients ( and and parsers ( and

The official part of the ecosystem looks like in the diagram below. The bold lines show actual NPM dependencies while thin black lines show logical relations. I omitted the repeating parts in the names of the projects, so -client in is and in it is

This section describes modules behind each of ecosystems. We start from smaller and more independent modules and then move to higher-level abstractions.

  • - a transport engine. Abstracts-out the details of exchanging messages between a client and a server. It defines Socket - a class that hides the details of transports used by a client at a given time. This module low-level. For example there's no notion of types of events or rooms: only strings and binary arrays that travel between a client and a server. High level details are left for Socket.IO. You can use Engine.IO as a standalone server however in most cases it is better to use Socket.IO. This module uses to encode and decode messages.

  • - a client implementation for that can run both in browser and Node.js. Uses to encode/decode messages.

  • - an implementation of protocol. Includes both encode and parse functions. Engine.IO uses a simple protocol to exchange binary or utf-8 messages. If there's no binary support on the platform, message is passed as Base64 string. The only meta-data sent along with the message is message type: ping, pong, data, etc. Parser can also work with batches: encode or decode multiple messages as one packet.

  • - that's what this post is all about. The high-level event transmitter that implements re-connects, rooms, broadcasts, multiplexing and other advanced features. It relies on for low-level transport, for protocol handling, for client-side code and for tracking rooms and namespaces.

  • - having somewhat misleading name, an Adaptor is a registry of users, rooms and namespaces. It has only 4 methods:

    • add(): for adding a socket to a room
    • del(): to delete a socket from a room
    • delAll() - to delete a socket from all rooms
    • broadcast() - to send a message to all sockets in a room this class is a base for extensions. builds a redis-based Adaptor that allows to distribute Socket.IO application between multiple nodes.
  • - a client for Socket.IO. You can use it from both browser and Node.js. Uses to encode and decode messages

  • - a parser and encoder of Socket.IO protocol, a reference implementation of It is not an extension of protocol. It runs on top of just like REST is a protocol on top of HTTP and not an extension of HTTP. Socket.IO protocol describes the transformation from/to Engine.IO transportable entity plus Socket.IO specific fields like packet type or namespace for multiplexing.

  • - a description of Socket.IO protocol (not the implementation, this repository has only a readme.MD in it). This protocol is higher-level than the protocol of Engine.IO. For example, it supports sending different types of data: strings, JSON objects or binary data. Besides it supports matching requests and responses and marking messages for rooms.

  • - a Redis-based implementation of an Adapter. With the help of this module you can set up a cluster of Socket.IO instances that will use Redis for communication between nodes.

  • - a Socket.IO-independent Node.js client that can send messages to redis-powered cluster

New Transport strategy

Before 1.0 Socket.IO was acting optimistic and first tried to establish the WebSocket connection. If that failed, Socket.IO downgraded to XHR. This approach could cause long delays if the environment was blocking WebSockets. Sometimes a client had to time out to know that WebSocket is not available.

Engine.IO implements a pessimistic but more user-friendly strategy. It starts from XHR longpoll and upgrades to WebSockets afterwards. Since XHR is available everywhere and less likely to cause problems, you get an immediate connection to the server and start to send and receive messages while is upgrading your connection. Over the last years this strategy has proven to bring better user experience most of the times.


Socket.IO introduced several big changes to the architecture and API: middleware, finer-grained logging and client API changes.

Let's start with middleware as it is the most notable change. Just like in Express.js you can now register a function that is executed once the socket is created:

io.use(function(socket, next){

This function can also perform more sophisticated logic like handling authorization, auto-joining some rooms or adding extra listeners for statistics. If you have some code in your Socket.IO application that does not implement core logic but rather handles an auxiliary aspect (authorization, logging, statistics, filters), it is a good candidate for becoming a middleware.

The other change is logging strategy. Socket.IO used to be quite verbose and it was lacking low-level control of individual components console output. Starting from version 1.0 Socket.IO is debug ( Now it is a pleasure to configure logging. Just set a DEBUG environment variable and you get an output only from the components that you need. For example, this is the way to print only what a Socket object is having to say:


There are more changes related to API, but since they are well listed in the official documentation, I will just leave a reference to the migration page:


Summarizing the changes, Socket.IO 1.0 became cleaner, smarter and easier to extend than its 0.9x predecessors.


Below are some links to github repositories that I referred in this post.


Please add your comments on github, or twitter @juriy.

Don't forget to follow, this will surely encourage more great posts!