How expensive to build a realtime massive multiplayer game using node.js/socket.io?

Question

Hi I am trying to build a realtime multiplayer game using node.js and socket.io.

Now, implementing itself in terms of coding won't be so much of a problem, but coming from a traditional http request-response web programming model, I have no idea how expensive this would be in terms of traffic and server load. Basically during a game, a player's browser should track realtime mouse input events and keep broadcasting them to all other players in the same game.

Here's an example, let's say my avatar follows around my mouse pointer on the screen, and it should be broadcasted to rest of the players on the screen in realtime. I would do something like:

// client side
$(document).on("mousemove", function(event){
    io.emit("coordinate", {x: event.pageX, y: event.pageY});
});

and on the server:

// server side
io.sockets.on("connection", function(socket){
    ...
    socket.on("coordinate", function(coordinate){
        socket.get("username", function(err, username){
            socket.broadcast.emit("move", {username: username, coordinate:coordinate});
        });
    });
    ...
});

I think this should work, but this requires the browser emitting several events per second to the server, which subsequently should broadcast them to rest of the players in the same game, and I am worried about the implication of this. One thing though is that the size of each fragment of data being transmitted is not that large (basically it's just an x and y coordinate). If this is too expensive, no matter how great this game is, I don't think I can ship it. Could anyone enlighten me? Thank you.

[EDIT] To clarify, I am not asking about how to make this architecture more efficient. I just want to know if this type of system is realistic enough in terms of system load (and maintenance cost) For ordinary web services I can just estimate the cost by looking at page view numbers but websocket is an entirely new field I am not aware of, so I wanted to ask.

Answer 1

Caveat: all the numbers below are estimated and there are overheads in a good few places but should give you somewhere to start.

If all you're doing is pushing data back and forth between connections then it seems unlikely the server will be your bottleneck. I think you'll hit your first wall with bandwidth (at the player end and/or the data centre end).

Assuming each user is pushing mouse data an average of 25 times per second that means that each one will be downloading players x 25 per second. Assuming each mouse movement message is 100 bytes and there are 20 players that means you're (naively) downloading ~50kb per second, which is quite high but achievable. I say naively because there will be overheads, but with a decent connection it feels achievable.

The download bandwidth is linear with the number of players, so at 100 players it'd be more like 250kb/s at the client end and 22Mb/s at the server end.

If you need more players you'll need to find optimisations, e.g. trimming the messages, data compression, limiting the mouse sampling speed, etc.

Answer 2

The one million dollar question is: I just want to know if this type of system is realistic enough in terms of system load (and maintenance cost). I think this is very relative. Relative to coding, hardware, quantity of users.

The suggestion of Leon is good, only track the mouse click and dont track the mouse move. In this kind of game, every strategy to reduce the requests/responses are welcome.

Answering your question, i said again, it is relative, your startegy (using node.js and websockets) sounds good, and it could work for 1.000 user sumultaneosly, but could not work for 1.000.000, however,the same code, with a better hardware, could work for 1.000, 1.000.000, 1.000.000.000 users, it is a infrastructure question. I think the premisse is be carefully in your code to mantain the system lightwheigt, because if you know your code is good, the problem will be the hardware, bandwith, etc (and you could take care about this later.)