A Year of Headaches: How not to build a realtime multiplayer game
summary
Built a realtime multiplayer Pong with Flutter/Flame and a Cloud Run backend hacked into a single authoritative game server plus a stateless frontline layer, aiming to support 6,400 theoretical clients. Determinism comes from running every simulation on durations since start and storing a history of paddle movements instead of cached ball positions; desyncs are fixed by making the server authoritative and replaying history to compute exact ball paths. Client-side optimistic input uses local time then snaps to server-corrected times to hide jumps.
AI-written summary · about
chapters (12)
- 0:00Introduction to the talk
- 1:08Why build a multiplayer Pong game
- 4:18Initial backend architecture
- 7:26The Pong game class explained
- 12:25First build failure and refactor
- 15:58Desyncing and debugging struggles
- 21:17Error correction and reset attempts
- 26:14Realizing server authority flaws
- 29:02Fixing determinism with history
- 31:54Solving UI easing challenges
- 35:25Final thoughts and lessons learned
- 36:55Q&A and live demo issues
related talks
49mTrusting your clients: live-coding a cross-platform multiplayer bingo app
37mVibing Flutter
50mBuild a multiplayer drawing experience with full-stack Dart
36mQuick Start to Game Development in Flutter
32mBuilding Real-Time Audio/Video Apps with Flutter and WebRTC
33mSurviving Network Failures: Building Resilient Offline-First…
33mApp Architecture: Faster, Better... Simpler
25mBringing a Legend to Life: Reimagining Rogue in Flutter