Notice: Undefined index: order_next_posts in /nas/content/live/gadgetmag/wp-content/plugins/smart-scroll-posts/smart-scroll-posts.php on line 194

Notice: Undefined index: post_link_target in /nas/content/live/gadgetmag/wp-content/plugins/smart-scroll-posts/smart-scroll-posts.php on line 195

Notice: Undefined index: posts_featured_size in /nas/content/live/gadgetmag/wp-content/plugins/smart-scroll-posts/smart-scroll-posts.php on line 196

Behind the scenes of Racer: A unique retro digtial slot car experience

Active Theory and Google Creative Lab team up to create a unique, innovative multiplayer, multidevice retro digital slot car experience



Surely racing games are pretty standard fodder. A collection of cars race around a track and the first one to the finish line is the winner. A simple analogy and one that doesn’t stray far too much from the truth, but the devil is in the detail.

Active Theory, a creative digital production studio based in Venice, California, is keen on detail and they decided it was time to challenge the concept. Motion is all part of the racing process and creating a great user experience via a well-conceived interface is what the Racer project was all about.

The technology needed to achieve a great UX needed to be pushed as far as possible. They were building a project that was new, innovative and quite possibly unique, “the first project of its kind (that [they] know of)” was on the cards. So, exactly what was the project all about? Racer involves syncing live gameplay across multiple device screens via the web. Who came up with
the concept? Google Creative Lab in New York.

The concept is in essence still the same principle as the traditional racing game, but placing it across multiple devices and avoiding the ‘real’ recreation of vehicles and tracks made it different. Racer harks back to retro in terms of the visuals and concentrates on the thrill that racing against an opponent brings.


The beauty of innovation is that it shouldn’t stop at the obvious, something Racer doesn’t do. There are multiple instances of the same codebase: a physical installation by way of a giant racer table, a flight case version for Google Creative Sandbox on the beach in Cannes, a desktop viewer mode and the mobile game itself. Each of these deployments are a great example of scaling project code for a campaign that extends across multiple uses.

Because of these kind of deployments and innovations, Active Theory were often asked, “How much is it?” or “Where can I download that app?” when they presented the game. They were amazed by the question and explained that Racer was not an app, it was a website.

First contact between project collaborators can make you agitated and excited at the same time. Thanks to Active’s tight collaboration with Google, there was nothing to worry about and Racer turned out to be both aesthetically beautiful and technically, very innovative. But, what were the team’s first impressions of the project?


“Our first take on the idea was ‘wow, this is going to be tough, can it really be done via a website?’ We knew you could do this type of cross device syncing and communication within an app but to prove you could get synchronised gameplay on a five car racetrack without loading an application, we needed to run a lot of tests.

“This was our first opportunity to work on a Chrome experiment with Creative Lab so it was both exciting and daunting. When we first started talking about the project, Active Theory was relatively new in the industry. It felt like Racer was our chance to create something unique. We knew [that] we might not get another opportunity like this so we had to make it amazing.
“Our first meeting with Creative Lab was at a bar in Austin, Texas. We were there for the SXSW Interactive Festival and preliminary sketches we saw were [on] the back of a napkin type of thing. The next day the Creative Lab team showed us a prototype that demonstrated the basic concept and gameplay. We knew we’d have to create our own prototype to see if we could get it really smooth.

“There were a few big challenges, one [was] getting the cars to animate smoothly across devices and another in having gameplay constantly synced between up to five devices. Creative Lab asked us if we thought it was possible and of course we said yes. [So then we] rushed straight back to our hotel to start work.

“Three days later we reconvened in another bar in Austin with our first build. The gameplay was not working perfectly, but it was an okay prototype. We felt like we had found a solution for the main risks in the project. The Creative Lab team were happy with what they saw and we launched into the project!”


Google Creative Lab took the Racer concept and went through the initial stages before bringing Active Theory into the fold: “Google Creative Lab’s first idea was a sketch, this turned into drawings, wireframes, concept deck and finally forked into parallel prototyping and design mocks. Active Theory came onboard after Creative Lab had built the first prototype.
“You often hear about concepts morphing and changing throughout early scoping and [sometimes] even into production but we [gathered that] this was a consistent idea throughout.”

Alongside the concept Google also handled the initial design duties, but Active Theory had a role to play before digging into the build as the team explain: “Google’s Creative Lab designed the main screens with flat HSL (hue, saturation and lightness) rainbow colours giving it a simple and stylish retro feel. These basic colours on a dark background were perfect for development, as the track and car could be drawn with simple vector graphics – great for animation and performance on mobile devices.
“After we received the initial look and feel, we iterated on a few subtle design tweaks with their team and then launched straight into the build. We treat the design phase more like a look and feel which matches to an agreed site structure. Our build process for Racer was less ‘big design upfront’ and more agile. It had to be like this as it had to mitigate the risk in technology, meet the locked-in timeframe and make sure performance was maximised.

“The iterative building approach lets the team to collaborate regularly and constantly improve. There were weekly project reviews – around ten total – where we would deliver working project code and call for feedback on specific parts of the game. This approach definitely improved the gameplay enormously by extracting as much quality feedback as possible out of the entire project team.

“Much of our work is in animation [so] we’ve developed custom built tools that enables us to build quickly and animate smoothly. This framework really helps us to blend the traditional design and development phases. The process is to think more about the project as a motion-driven experience rather than [as] coding a set of frames.”

Active Theory had a far bigger role at the development stage than they did at the design stage. Getting the build perfectly poised for all platforms across many devices was an undoubted challenge as the team reveals: “At Active Theory we built the prototype and the table version using node.js. This was then ported to Go for the live mobile version so that it could be hosted on Google’s App Engine. The installation/table version of the game still runs on the original Node.js backend.

“The biggest challenges were dealing with the latency and knowing how long it takes for messages to be received from the Compute Engine relay. The tricky part was that the device’s clocks are never completely in sync. To get around this, we needed to find the difference in time between the device and the server.

“We send a message with the current device time-stamp. The server will then reply with the original time-stamp along with the time-stamp of the server. We use the response to calculate the actual time difference. “Doing this once is not enough as the round trip to the server is not always symmetrical, meaning it may take longer for the response to get to the server than it does for the server to return it. To get around this, we poll the server multiple times, taking the median result. This gets us within 10ms of the actual difference between device and server.

With no traditional handover ceremony as part of the process, how did Active Theory stay involved with project? “The site has always been hosted on App Engine so there wasn’t really a need to handover the code. We worked tightly with all stakeholders [so] that the handover and documentation became part of the production process. Browsers are updated frequently so there’s always an element of unknown about ongoing maintenance. We do offer maintenance to our clients but that would generally be needed for a more modular project build, something where content is updated frequently over a long period of time. All our work goes through double QA. Our clients have their own QA process, and so do we. With the multitude of devices and browser combinations out there, testing is critical for quality.

“We follow continuous integration, we’re using and testing our work on various devices on a daily basis. Towards the end of the timeline we’ll have our third-party QA team establish test cases and systematically run through the entire application several times over.

“There was only one change in the week after go-live and that was to a line of copy – it has been very stable. In the one and a half years it’s been live, there have only been a couple of small updates required and these were due to changes in browser technology.”