I'm currently developing a HTML5 Canvas Multiplayer Game using NodeJS and Socket.IO. My current setup using a logic loop on the NodeJS Server-end and sending update information to all Clients in this loop 60x a second. For obvious reasons, this isn't feasible, and even with one player, it doesn't work as I'd like it to.

I'm not a networking genius nor am I an experienced Game Dev, but is there any way for Node and my Client(s) to "share" variables so that I'd have no need to send packets like this? Or any way in which I could improve my current situation?

Current workflow:

  1. Client sends keypress action to the Server via a packet
  2. Server adds it to a queue and in the Logic loop will calculate movement and update the server-side Player Entity accordingly
  3. Game loop also sends these updates to all other Players in the same Socket.IO Room at 60x a second
  4. Client takes their finger off the movement key(s) and sends this action to the server
  5. Logic loop removes the movement from the queue

Thanks in advance, please let me know if there is anymore information you'd need

  • 4
    \$\begingroup\$ Send states less often and interpolate between them. developer.valvesoftware.com/wiki/Source_Multiplayer_Networking There are ways to "share" variables but they are slower and not used for stuff like this. \$\endgroup\$
    – Kikaimaru
    Oct 14, 2013 at 8:13
  • \$\begingroup\$ @Kikaimaru Thank you, I will look in to this. Though - my method lags easily with two players, wouldn't halving the sent states still only support up to 4 players? Thanks again \$\endgroup\$
    – oyed
    Oct 14, 2013 at 9:23
  • \$\begingroup\$ Sending states is pretty common in FPS games, so I guess there may be reason they have maximum of 16-32 players. What kind of game are you making? Because for example MMORPG work totally diferrent because they dont really care where exactly player is. \$\endgroup\$
    – Kikaimaru
    Oct 14, 2013 at 9:36
  • \$\begingroup\$ @Kikaimaru It is an MMORPG, and I started with physics and movement being calculated client-side which was much more efficient and worked slightly better, but it also meant that Players could just use the JavaScript Console to cheat their position, Items, etc. \$\endgroup\$
    – oyed
    Oct 14, 2013 at 9:52
  • 2
    \$\begingroup\$ WoW computes all movement client side and then just do checks on server if user isnt too far, or isnt in terrain. You can also just start moving player localy on client and send message to server, server will still check if your movement is valid, but only informs you if its not. This will eliminate seeing your character lagging, but other players can still lag. Depending on type of movement, you can send where the player wants to go and move him there on client, if you have movement like in FPS, you have to make something similar to my first comment. \$\endgroup\$
    – Kikaimaru
    Oct 14, 2013 at 10:14

1 Answer 1


Well, what I did in my project was that I have .ts (or .js) sources that are common for both server and client. Considering typescript, a bit of hack was needed to make it work. If you would be interested, I can provide you full explanation.

Now 60x per second is too much, you should be ok with like 2x per second. Also, you would have to implement client-side interpolation to get rid of ,,laggy movement". If you want, you can add me and I could help you with that (as this forum would not get spammed).

A note: use serialization to send network data. Do not send manually arrays. In past, I did and I had to rewrite project because, with growing complexity, it became unfeasible

have a nice day


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .