The batch idea is interesting. I'm using RakNet and used to sending messages where the first byte is the message ID and the remainder data is the data for that message type. Batching things up with this way wouldn't really be byte oriented but message oriented. However RakNet is doing the sending behind the scenes is something I don't have to worry about really, which is nice. I can focus on sending messages and data that the messages require.
I think to start with I'll just send the new positions from the server right when the server gets it (if the position changed from last time) to all the other clients around said client. I'll make a separate process every second or so that refreshes the clients around each client since that doesn't really need to be done on each send in a slow pace casual game like this. I don't personally have any threads, but RakNet does to do the networking as it's async. All the decisions to send and read the data from RakNet is done on my 1 main thread.
I think this will create a steady, but unpredictable, stream of data leaving the server. That's for sure better than the predictable bottleneck of sending all data on a given interval, but not as ideal as predictable with a cap. I have to wonder if predictable with a cap sent each time leads to other issues of falling way behind and then having to deal with that. Not that you can't deal with it, but it's just another thing to deal with. I think for now I'll just send out instantly the positions when they have changed.
For other reasons I want the client to always send their position 4 times a second no matter if they moved or not. It's complicated to explain but has to do with the streaming map data sent to the client and a small situation that can happen that is corrected by getting constant position updates. 4 times a second is nothing considering a good number of action games can do 20+ a second.