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

5

7

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.

Investment answered 19/10, 2012 at 12:7 Comment(0)
P
5

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.

Pinafore answered 26/10, 2012 at 17:52 Comment(0)
O
3

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.)

Olathe answered 25/10, 2012 at 17:48 Comment(0)
R
2

I have done something very similar...

All players send data to the server at their own rate (hopefully about 30 frames-per-second) The server collects the data from each player, and sets the new state (player mouse position). The server has a timer running at 30 frames-per-second -- sends a single message to all players with all players mouse positions. It makes the payload larger, but only sends 30 packets per second -- no problem for node or modern browsers.

Good luck with your game!

Dan

PS -- Remember, you have to design for speed!

Regeneracy answered 28/10, 2012 at 3:7 Comment(0)
M
1

Are the avatars really going to follow the mouse or are they going to move to locations on a map that are clicked? If the latter then you only need to transmit click locations to the server and the server only needs to broadcast avatar waypoints and travel speed to the clients.

This still has limitations in terms of how many objects and players need to be managed but the server can collect a 1/10 a second or a 1/4 of a second worth of actions for multiple avatars and objects and share them out as a bundle thereby reducing the network, server, and client load.

Miraculous answered 21/10, 2012 at 7:57 Comment(1)
Thanks for the answer, but to clarify, I didn't mean to ask about how to make this more efficient. I wanted to know how much load this type of app will exactly have--whether the spec is feasible or not. After that I can think about making it more efficient. But for now I would like to know even a ballpark figure of how much load this type of app will create.Investment
S
1

Consider it this way.

If you really want to build a massive multiplayer game with real-time updates, then according to the stats here, websockets if your best bet. (socket.io is a convenient library that provides fallbacks, but it should be configured to use websockets primarily.)

Richard made some solid estimates. However, there are two additional things you need to consider:

  • maximum number of open connections (google for ulimit)
  • parallelization (node.js runs on a single thread, and this will perhaps never change in the future; when broadcasting your changes, will an approx. O(n) performance be acceptable for your game?)
Severe answered 29/10, 2012 at 3:43 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.