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.