Multiplayer game - How much data should be sent to the client and how big?

[Threedy]

I have am running a 3D multiplayer physics game where I currently send the input (4 keys, position: x,y,z and velocity x,y) to the clients (8 clients in total) 30 times a second.
 

Is this considered to be a bit too much? Also, I assume changing (1) to (2) would decrease the size of data that is sent?
 

(1) var keys = {l:true, r:true, u:true, d:true};

(2) var keys = {l:1, r:t1, u:1, d:1};

[rgk]

I wouldn't worry about it much but yeah you are sending less data with 1 then true. Have you noticed any lag so far?

[WombatTurkey]

30 times a second? 

Client prediction is needed here, that's insane man. 

[Threedy]

Haha thanks for the comment guys. I managed to bump it down to 10 ticks  

Anyway, the current bottleneck seems to be the physics engine itself (CannonJS).When I add 400 boxes, only floating in the air, I notice quite a bit of lag (only for 1 player in 1 game). I'm pretty bummed out. Perhaps it was a bit too ambitious, a 3D realtime multiplayer physics browser game.

[michaelcalkins]

I'm doing something similar in the browser with a 2d platformer and websockets.  

You're sending a perfect amount of data.  Too much data is when you send unnecessarily large datasets multiple times per second.  Just send the absolute minimum.

[WombatTurkey]

On 4/4/2016 at 1:30 PM, Threedy said:

Haha thanks for the comment guys. I managed to bump it down to 10 ticks  

Anyway, the current bottleneck seems to be the physics engine itself (CannonJS).When I add 400 boxes, only floating in the air, I notice quite a bit of lag (only for 1 player in 1 game). I'm pretty bummed out. Perhaps it was a bit too ambitious, a 3D realtime multiplayer physics browser game.

Hmm. Do you have an example of this? You can pm your link if you don't want it public.

Regarding the physics, if 400 is too much do a dynamic range visibility check. For example, on my game if there are 100 mobs loaded in the map, only show the ones that are visible within 700 pixels (screen's width/height). This helps tremendously. You could also setup web workers, but you would then need to send data over and back to update, so that might not be beneficial. Just do some trial and error stuff. 

400 boxes does seem like a lot, but how many should be in view on the player's screen?

[Fricken Hamster]

Another way to optimize data size is to send binary. Then you can take all the booleans and pack them in groups of 8 to make a uint8 using bitwise operations.

[WombatTurkey]

4 hours ago, Fricken Hamster said:

Another way to optimize data size is to send binary. Then you can take all the booleans and pack them in groups of 8 to make a uint8 using bitwise operations.

I think BSON would help with that too if they are doing a JSON-like transmission.  I have always been looking for benchmarks comparing Binary Websockets to Text.  

[kevdude]

On 4/5/2016 at 8:32 AM, michaelcalkins said:

I'm doing something similar in the browser with a 2d platformer and websockets.  

You're sending a perfect amount of data.  Too much data is when you send unnecessarily large datasets multiple times per second.  Just send the absolute minimum.

I agree, if you're using WebSockets, large data packets won't normally cause lag. It's when you send too many individual messages that servers lag.