I'm developing a network game with node.js and I have the choice between these three options:

1) Send each point individually (very user responsive)

2) Send an update every 25 points or so (decent compromise)

3) Wait until the user is done with his path and send it in its entirety (clients don't see until entire path is complete)

Now I know node.js is very good for quickly sending data back and forth rapidly and even sending a point at a time on my local connection is instant with no lag at all but I'm thinking down the line. What if there were thousands of people playing? Would it deny service based on how many packets were going through or is node.js with socket.io good enough to handle even such loads? What do most people do when they encounter this situation?

  • \$\begingroup\$ Plan your software so that you can adjust later, and profile and see if there could be some improvements done. \$\endgroup\$ – Vaillancourt Sep 10 '15 at 19:41

None of the options you listed is really a good choice.

Nagling is turned off by default so each packet you send will be an individual packet. A good rule in game networking is to find a send rate and don't go over that. That is perform your own nagling of packets. Essentially don't send 30 individual packets one after another for individual points. (You'd be eating header overhead and routing overhead).

It's not clear how your "points" system works or the rate at which points are created. Depending on your game you might be fine just updating at a fixed 100 Hz. So queue up your points and then in your update loop build your packet with the points data and send it along with other data to the player.

| improve this answer | |

First off, you have to decide what performance characteristics are most important from a user experience point of view and then understand the technical issues involved in delivering that experience at scale/load.

So, the operative question for your game may be something like: "At what delay does the experience for others start to deteriorate?". Some games would be basically ruined if the delay in update of other's moves was 1 second and other games could easily tolerate 5-10 seconds as it entirely depends upon the game and what the networked data you are transmitting means to the experience of the receiving player.

So, in your specific game, you need to figure out what the goal is. Do you need to deliver updates to other players within 300ms, will the experience still work just fine at 2 seconds or is the info being sent periphery to the experience and even 10 seconds is OK?

Then, whatever time delay you find still acceptable for a decent experience, you can build your client so that it collects points for about 2/3 that time minus whatever the usual transmission time is and then sends what it has when that timer fires. This will give you batching for the most efficient transmission at larger scale, but should deliver most packets in a fast enough time to deliver the user experience you want.

A more advanced implementation would gauge the activity level and deliver a faster experience (shorter batching time period) when load is light and allow the batching time period to go update when the activity level is high. This assumes that batching more updates into a single packet is the more efficient way to deliver things from a network point of view and client/server processing point of view so you want to move that direction when load is high and move more to the low lag side of things when load is low.

Let the desired experience drive your design goals, then figure out what technology solutions are needed to deliver that desired experience at load and design a self regulating backoff for very high loads.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.