You may have seen our recent demo of Racer at Google I/O, and wondered how it
was made. So today we wanted to share some of the web technologies that made this Chrome Experiment “street-legal” in a
couple of months. Racer was built to show what’s possible on today’s mobile devices using an
entirely in-browser experience. The goal was to create a touch-enabled experience that plays
out across multiple screens (and speakers). Because it was built for the web, it doesn’t
matter if you have a phone or a tablet running Android or iOS, everyone can jump right in and
play.
Racer required two things: speedy pings and a consistent experience across screens. We
delivered our minimal 2D vector drawings to each device’s HTML5 Canvas using the Paper.js vector library. Paper.js can handle the path
math for our custom race track shapes without getting lapped. To eke out all the frame rate
possible on such a large array of devices we rendered the cars as image sprites on a DOM layer
above the Canvas, while positioning and rotating them using CSS3’s transform:
matrix().
Racer’s sound experience is shared across multiple devices using the Web Audio
API (available in latest iOS and Android M28
beta). Each device plays one slice of Giorgio Moroder’s symphony of
sound—requiring five devices at once to hear his full composition. A constant ping
from the server helps synchronize all device speakers allowing them to bump to one solid beat.
Not only is the soundtrack divided across devices, it also reacts to each driver’s movements
in real time—the accelerating, coasting, careening, and colliding rebalances the presence of
every instrument.
To sync your phones or tablets, we use WebSockets,
which enables rapid two-way communication between devices via a central server. WebSocket
technology is just the start of what multi-device apps of the future might use. We’re looking
forward to when WebRTC data
channels—the next generation of speedy Web communication—is supported in the stable
channel of Chrome for mobile. Then we’ll be able to deliver experiences like Racer with even
lower ping times and without bouncing messages via a central server. Racer’s backend was built
on the Google Cloud Platform using the
same structure and web tools as another recent Chrome Experiment, Roll
It.
To get an even more detailed peek under the hood, we just published two new case studies on
our HTML5 Rocks site. Our friends at Plan8 wrote
one about the
sound engineering and Active
Theory wrote one about the front-end
build. You can also join the team at Active Theory for a Google Developers Live
event this Thursday, June 13, 2013 at 3pm GMT for an in depth discussion.
Pete LePage is a Developer Advocate on the Google Chrome team and helps developers
create great web applications and mobile web experiences.
By Pete LePage, Chromium
team