3 ms·
Further notes here: https://www.reddit.com/r/gamedev/comments/cgvqr5/anyone_use_webrtc_for_a_multiplayer_browser_game/ https://www.reddit.com/r/gamedev/comment
by fao_ 4y ago
Further notes here:
https://www.reddit.com/r/gamedev/comments/cgvqr5/anyone_use_webrtc_for_a_multiplayer_browser_game/ https://www.reddit.com/r/gamedev/comments/cgvqr5/anyone_use_...
https://hacks.mozilla.org/2013/03/webrtc-data-channels-for-great-multiplayer/ https://hacks.mozilla.org/2013/03/webrtc-data-channels-for-g...
http://blog.brkho.com/2017/03/15/dive-into-client-server-web-games-webrtc/ http://blog.brkho.com/2017/03/15/dive-into-client-server-web...
- j1elo 4y agoNote that while still quite complex and difficult to grasp for newcomers, WebRTC is now much more stable and well implemented by web browsers. However bugs and interoperability issues have been rampant still in latest years, so I don't want to think about how the scene was in 2013... Regardless, in my above comment I was thinking of a lower level. Not WebRTC per-se, but the plain RTP protocol. Every RTP (UDP) packet has NTP timestamps included in the header. RTP endpoints (both client and server) have a well defined set of calculations user to synchronize packets based on their timestamps, and also infer network latency, jitter, even clock skew, that kind of things. RTP packet headers also have a sequence number. This is used to detect out of order, or missing packets. Then the packets can be reordered, or (if it makes sense) a retransmission request be sent back to the sender. I.e. a lot of the problems that were being described in the original article, seem to be already handled by RTP. So I was thinking of how realistic it would be to use multiplayer game data, instead of video frames as the RTP payload, to leverage all these network-related mechanisms of the protocol.