[JoeOfTexas]

I joined one of the Brains server and was curious what the experience was for 50~ players. The movement was a bit janky, as expected from websockets. I was also curious about the networking compression, because I'm doing something similar.

I'm not sure if just doing LZ-string compression is enough. 50 players use about 20KB/sec data. Comparing that to Warzone at 150 players uses only 48KB/sec data. Unless you have unlimited data, that could be costly in cloud bandwidth.

It was also curious that the compressed buffer of bytes look like this: 埒愑䣔橤㤰゙㟍稦獦ঙ惝䓇強栛䳌۬䌃̩佼

I wasn't sure if that is how LZ-string compression just ends up, but its a bit jarring.

In any case, there is lots of room for improvement on the networking side to reduce potential costs.

The whole project is very impressive, so great job!

[nightowl_games]

Movements pretty tight in our websockets:

https://gooberdash.winterpixel.io/

It's all about the client side prediction & roll back networking algorithm. Our game states end up being ~1kb at 30hz, which typically fits into a single packet, so websockets aren't terrible. An unreliable protocol would be better, of course.

[andai]

>client side prediction & roll back networking algorithm.

I need to look into this! I made a little networked 2D physics thing (just bouncing balls) and I was surprised how well it stays in sync, because of course both machines just simulate the same result.

I added some interactivity and simulated lag / packet loss, at that point I added an interpolation function so an entity could have a "target" and gradually slide there over a few frames. I've seen some other games do that as well.

I haven't gone very in depth on this, but VALVE has an excellent article on the subject, also covering input prediction and lag compensation:

https://developer.valvesoftware.com/wiki/Source_Multiplayer_...

[bcrosby95]

There's an awesome talk by someone in the overwatch team in youtube. It's about ECS but it has a big section on networking that had some useful tips.

Edit: here it is - https://www.youtube.com/watch?v=W3aieHjyNvw

[nightowl_games]

This one's good but pretty advanced. We haven't implemented a lot of these techniques in our games. This is a great starting point:

https://gafferongames.com/post/introduction_to_networked_phy...

[andai]

>The movement was a bit janky, as expected from websockets

Could you elaborate on this? I played a few "io games" and it seemed pretty smooth (except for the occasional laggy player).

On the other hand, I did a bit of testing with WebSockets a few months ago. If I understand correctly, there are significant downsides to using TCP for games (or any latency sensitive communications for that matter): TCP header being >2x bigger than UDP, additional control packets, and TCP delays transmission of new data while old (stale) data is retransmitted. So WebSockets have these same downsides, due to being hosted over TCP.

Despite all that (TCP supposedly guaranteeing delivery of WebSocket messages), I was able to produce packet loss. So you have the downsides, and as far as I can tell you don't really have the upside, since if you actually want guaranteed delivery you still need to build your own thing on top of it (which you could have just done on top of UDP in the first place, at least for messages that need it!)

(Take this with a grain of salt, aside from a bit of dabbling I have close to zero knowledge and experience with networking.)

[junar]

CJK characters occupy a vast portion of the printable Unicode characters. [1] Two of the largest blocks include

* U+3400 to U+4DBF

* U+4E00 to U+9FFF

Your string decodes to \u57d2\u6111\u48d4\u6a64\u3930\u3099\u37cd\u7a26\u7366\u0999\u60dd\u44c7\u5f37\u681b\u4ccc\u06ec\u4303\u0329\u4f7c

[1] https://en.wikipedia.org/wiki/CJK_Unified_Ideographs