What the Web can Learn from Video Game Networking
summary
Practical rules for real-time web: serialize game state with MessagePack or custom binary to cut payloads from ~37,000 bps down to about 1,200 bits/sec for a two‑player Pong, use server gzip/br compression and the 14 KB TCP initial window trick, colocate DB and Redis cache in the same region and front servers with anycast CDN, and recover from latency by sending fewer updates (send ~12 fps and interpolate on client rather than 60 fps). Thorium Nova demonstrates these patterns.
AI-written summary · about
chapters (16)
- 0:00Introduction
- 1:20Latency and bandwidth basics
- 2:45Human speech bandwidth fun fact
- 3:25Protocol hierarchy and OSI model
- 7:21TCP vs UDP limitations
- 9:07TCP optimization tricks
- 10:12Real-time game demo setup
- 13:38MessagePack compression demo
- 15:42Minification and compression
- 16:25Binary serialization benefits
- 17:07Server proximity and latency
- 19:35Database and cloud routing
- 20:57Caching and CDN strategies
- 21:59Handling distant users
- 23:25Interpolation and frame smoothing
- 24:49Summary and resources
related talks
45mOnline Games, But How Come They Don't Lag?
42mOnline Games — How Do They Not Lag?
47mReliving the History of Multiplayer Games
53mMultiplayer Pac-Man with RSocket
38mMultiplayer WebVR
36mSimulating Network Conditions with JavaScript
37mGetting Close with the Web
40mMultiplayer Gaming Architecture and Design