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.