McDONALD'S
Giant LED billboard + player phones — live-synced Pong at 60fps.
Firebase RTDB delivering paddle position updates at 16ms intervals.
McDBot AI activates if a second player doesn't join in time.
Fries, McFlurry, or Big Mac — selected before the match begins.
PONG.
ON A
BILLBOARD.
McDonald's Sweden ran a real-world campaign where passers-by could play Pong against each other on a massive outdoor LED billboard, controlled entirely from their phones. No app download. Scan the QR on the billboard, pick a prize, and play.
"The brief was deceptively simple: a giant screen, two phones, and a game of Pong. The engineering challenge was making a decades-old arcade game feel instantaneous at billboard scale."
The re-engineered version required a dual-transport architecture — separating high-frequency paddle position data from low-frequency session state to achieve the latency profile needed for a playable experience over mobile data connections in unpredictable outdoor environments.
THE BUILD
Production Next.js app · dual Firebase transport
A Next.js web app with two routes — /display for the billboard and /controller for phones. Game logic runs client-side on the display; player inputs stream from phones via Firebase RTDB.
In-Field
Activation Geometry.
Real-time synchronization across 50 meters. The phone behaves as a high-fidelity input node, streaming position data to the broadcast server at 60Hz.
ONE GAME.
TWO
SCREENS.
The billboard is a spectacle — enormous, public, unmissable. The phone is the controller — intimate, personal, in the player's hand. Each screen has a completely different job, and each required a completely different design approach.
THE BILLBOARD
The display screen renders the full Pong court with the Golden Arches as a semi-transparent net. A massive, clean red canvas — readability from 50m.
THE CONTROLLER
A pure red screen. Prize selector, initials entry, and a drag-to-control paddle zone. The phone's entire screen is a single vertical drag controller.
TWO PIPES.
ONE REASON.
A single Firebase transport couldn't serve both needs. Firestore is perfect for session data but too slow for a playable paddle. RTDB can sustain 60fps writes at under 50ms latency.
| Transport | Payload | Rate |
|---|---|---|
| RTDB | Paddle Y (float) | 16ms |
| Firestore | Game State | On Join |
YOUR
MEAL.