You're going to hang the state of networked browser gaming on this random person's netcode implementation? Go to r/GameDev and you can find some redditor Unity projects built on UDP that are even worse, but you aren't going to say "wow, UDP sux".

Check out something like https://krunker.io/ which gives me a surprisingly good FPS experience despite my distance from the server.

Browser gaming does take some thought though, to be sure. UDP via WebRTC is relatively new and isn't trivial. And I know some games get around TCP head of queue blocking by opening up 2+ WebSockets.

HaxBall [1] and WebLiero [2] are two other games with pretty decent WebRTC P2P netcode by the same author.

[1] https://www.haxball.com [2] https://www.webliero.com

That was impressive, on mobile and I was able to just hop in and start playing. Not something I’d play, but just impressed that I was able to so easily

This is not random. Prediction and compression is all GoldSrc original, from leaked sources. WebRTC/WebSocket is HumbleNet.

Krunker is fantastic. I have wasted many hours in that game :)

Amazing experience there with kunker. So snappy. Thanks for sharing.

Do you have any more information on getting around head-of-queue blocking by opening up multiple websocket connections instead of just one? Seems like an interesting solution.

damn krunker is really not bad at all

How good is krunker? Don't have a mouse but maybe I could get one.

It's quite fun and has a surprisingly deep movement system. The userbase is very young so if you have any FPS experience you will shred through the average player.

Expect to get annihilated by someone who knows the movement system though. You'll know someone's using it when you see it, since they'll be moving at 999 units per second and circle strafing you to death.

I remember playing CS around 2000 on a 333-MHz Pentium II with an ATI Rage graphics card, and it was a much smoother experience in every way.

On a similar note, I think people were _way_ too early to celebrate the death of Flash (security issues aside of course). Developers were making content in 2000 which their contemporaries 20 years later don't come anywhere close to in terms of performance, design, or responsiveness.

Flash had more than just security issues. There were definite limits on complexity.

A great example is the original Binding of Isaac; written in flash, but near the end everything was so precarious that backups had to be made before certain publishing stages because sometimes it would corrupt the files it was trying to build (Due to the complexity.)

If bugs in flash forced people to use source control for complex projects then I would call that a feature.

Well ignoring those issues, is there a html/websocket "framework" which works like flash did?

AFAIK, "zero code" systems still haven't reached the level of hypercard (the spiritual predecessor to flash) when it comes to being able to define event->action with a mouse, much less expanding them to the full capabilities of flash.

That style of content just disappeared or turned into video only as far as I can tell.

I dunno. I implemented my games'[1] netcode on top of WebRTC and it runs just as well as proper UDP stuff. If you configure it be unreliable and pack everything into small binary commands then it behaves exactly like you'd want for a fast-paced multiplayer game. Obviously most web games use websockets for networking but it is certainly possible (albeit much more difficult) to have very fast netcode in a browser game.

[1] https://redka.games/mages

It's been awhile since I took a crack at WebRTC. Do you still need to go through all the peer negotiation even when you are just trying to get to a known server?

Yes, you still have to go through the negotiation. I put together a tutorial for a minimal Node.js Server + Browser Clients example a while back:

https://www.marksort.com/udp-like-networking-in-the-browser/

Bleh! I was really hoping they would have smoothed that out by now. I just want a damn UDP socket to my server!

I guess it's easier to piggyback on the security model of the P2P handshake than work out a separate model for client-server communication.

I built a pair of libraries for a nodejs<->browser DataChannel, it was a nightmare at the time though, and I'm sure totally obsolete by now.

Given how long it took for us to get %*@!$ data channels, I guess we'll get a simpler way to connect to a regular server in... 2030? (I watched WebRTC very closely from the Ericsson prototype was released... for awhile I was contemplating trying to pass data in the audio or video streams -_-)

What do you mean by "small binary commands"?

Instead of cramming ecoded json into the data channels, like you'd with websockets, you can build binary buffers with all the data that has to be communicated between server and client. For example movement commands like up/down/left/right alongside some flags like isJumping can be packed into a singe uInt8

Yup, delta compression and potential visibility sets are also a huge win as well.

The best thing is to design your gameplay to be "predictive", that's how we had ~300 player games like Subspace over 28.8/56k way back in the day.

Use websocket in binary mode, pack operations into tiny messages.

actually binary websockets won't do in this case since the underlying protocol is still TCP with automatic retransmission mechanism which kills performance for very fast-paced games. You have to use WebRTC in that case

So there's no reason to use binary commands when using something like socket.io?

not much but shaving off some bytes is good in itself

Then again, the netcode of the original HL1 engine was extremely good for its time.

This appears to strictly use WebSocket, and not touch WebRTC at all.

It is no surprise that a TCP text-based protocol sucks for realtime gaming purposes.