Oct 6, 2017 · 8 min read

What a ride making this project was! We were totally blown away here at Jam3 with the amazing response that our Dunkirk WebVR experience received. With such a complex project we thought we’d break it all down and share some of the challenges we faced and the thinking behind some of our decisions.


At Jam3, we’ve worked extensively with VR and WebVR, but a multi-user, fully co-operative WebVR game was something we had yet to conquer. Technically, neither had anyone else. That’s OK. Solving seemingly impossible challenges is our calling card. It’s what we love to do.

We couldn’t ask for a better narrative to launch our first co-operative VR effort than the real-life Dunkirk mission that rescued 400,000 stranded British soldiers during WWII. According to our initial estimates, the project would require four months of solid teamwork. We had 10 weeks. #FOL.

Pushing the limits with creative technology usually involves overcoming a host of compatibility issues and processor limitations. In this case, we had to build a smooth multiplayer VR experience but optimized for a mobile browser. Using WebGL as opposed to a native app meant the game could not use all the processing power phones had to offer, as we were constrained by the browser sandbox.

From a gameplay perspective, we initially envisioned both our players in the same room, having fun shouting instructions to help one another escape enemy fire. That idea quickly fell by the wayside because the client wanted two random players to be able to connect from anywhere in the world. Admittedly, it’s an awesome feature, but it was one more curveball and an added a layer of unforeseen complexity.

On the interaction front, we would need to rely solely on a single button and the user’s gaze. Taking our cues from Google’s design principles, we figured out a system that used gaze as the primary interaction and gameplay driver.

All in, the challenge was an amazing opportunity that played on the three things we love most (and do best): design, technology and storytelling.


We needed a script. One that would not just drive gameplay, but respect the historical record, and furthermore satisfy both Christopher Nolan’s vision and Google’s expectations. NBD right? To make things even more fun, we weren’t allowed to read a single page of Nolan’s screenplay — Hollywood secrecy can sometimes truly be next level.

We were left staring at a blank page. Our only references? An early trailer and movie poster. The latter’s haunting monochrome quality proved to be a great starting point for the visual direction our game would eventually follow.

We were given three central themes to drive home with audiences: Scale, Suspense, and Stakes. We needed to create expansive environments (scale) where death could strike at any moment (suspense) and where failure would change the course of the war (stakes).


Our story begins on the beach with three soldiers — an Officer (Player 1), his Captain (Player 2) and a Medic (Non Player Character) — all under attack from enemy planes. To make the game equally immersive for Player 1 and 2, we needed to craft a storyline that could provide both players with their own unique roles, gameplay challenges and individual perspectives — even though they were collaborating on the same battlefield. It was quite the narrative challenge! But we live for these kind of story puzzles.

Our solution was both smart and dramatic — Player 2 would be injured from the get go and Player 1 would have to carry a wounded partner over their shoulder while finding a safe path to the rescue ships.

This special bond between wounded and rescuer demands intense collaboration. Its also a narrative decision that would give our players two different POVs with two complementary tasks. Player 1 needs to move forward while injured Player 2 (facing backwards) scans the sky for enemy planes. If Player 2 can hold their gaze on a bomber for two seconds, it would trigger an audio and visual cue that helps Player 1 dodge enemy fire. Things like “Incoming, on your right!” and “LEFT! LEFT! LEFT!”.

Success depended on both players directing their gazes efficiently until they reach a rescue ship.


We wanted ACT II to have different gameplay and visuals so that the experience wasn’t repetitive. So we transported players to an entirely new scene with a new set of interactions. The sea was a natural choice as water was the central mode of escape in Dunkirk. Our new characters would be inspired by the heroic civilians who risked their lives steering their small boats back and forth the English Channel to rescue thousands and thousands of soldiers.

Designing our interaction based on a classic Marco Polo gameplay provided us with a familiar and uncomplicated way to create maximum drama. It also meant less gameplay instructions.

Player 1 is now a Civilian Fisherman in a small boat while Player 2 is a soldier that’s made it off the beaches and is treading water, struggling to stay alive. Two Non Player Characters on the boat help drive the game forward for both players by translating gaze interactions into helpful voice commands.

It’s pitch black except for a searchlight that Player 1 controls with their gaze. In turn, Player 2 must use their gaze to locate the searchlight. This action triggers Non Player Character dialogue that instructs Player 1 where to look to find Player 2. In this high stakes version of Marco Polo, the mission ends unsuccessfully if Player 2 idles for more than five seconds.

Now that we were satisfied with our story and it all looked promising on paper, the real question was, would the game actually work?


Our tight deadline dictated we move quickly. While we were writing the script, storyboards and style frames started to take shape. After two weeks, most of our 2D imagery was finalized.

We drew our design insights from the movie assets, incorporating the same boat and truck shown in the film trailer. The poster inspired us to create our own shadowy figures and eerie landscapes. Not only was this minimalist aesthetic practical; it was also perfect for the subject matter.

There’s a substantial time gap before 2D visuals start to take shape in 3D. This lag makes for some interesting internal and external approval rounds — what you see and discuss may not be what you ultimately get. Considering the developer is wading in mostly uncharted waters, they operate more as a designer in this scenario. We started the project with four developers and kept adding to the unit, until it numbered a small army of ten.

Five weeks into the project, we were provided with the first assurance that the beach scene in ACT I would work! What a relief… but there was no time to enjoy the moment.

The entire process was so reliant on phone GPU, we had to develop the game in stages, pushing the GPU until it broke. Then we rebuilt the game. And broke it again. Lather. Rinse. Repeat. In some cases, it took several days to get the game up and running again.

Our 360 sound design, an important part of the gameplay environment, also imposed a heavy strain on the GPU. We loaded over 140 different tracks — the roar of courage battling an endless barrage of destruction.


Since gameplay was gaze-driven, we had to design a set of consistent and easy to grasp methods of nonverbal interaction.

In ACT I, the players need to move towards the beach. The interaction is set up so moving forward is the only possible direction.


If Player 2’s gaze drops for more than 2–3 seconds, it triggers a warning from the Medic. If Player 2 cannot quickly refocus their gaze, they will experience only the sound of their own breathing until it slows to nothingness.


ACT II requires both players to find each other. Player 2’s gaze aims to follow Player 1’s searchlight. The gaze then triggers specific sounds based on their distance from one another. If Player 2 moves further away, a Non Player Character on the boat will shout out an appropriate warning. The clarity of directions depends on the distance between the players: vague at 1500M, clearer at 1000M and clearest at 500M — the point where both players can start to see each other.

ACT 2 — Distance between the players


Creating a game tied to a landmark summer blockbuster proved to be an incredibly demanding and rewarding experience. The project was intense, complex and often ambiguous. We had no way of knowing what was possible until we literally broke our system.

As we lurched forward from one challenge to another, the synchronicity between team members never missed a beat. Even when we frantically expanded our squad during the final push, our minds all seemed to merge as one. When one person stumbled, someone else would step up. Nobody was left behind. It truly was a team victory. Our level of resiliency and cooperation was easily the most gratifying part of the challenge.

Fittingly, Dunkirk WebVR has quickly garnered lots of love from the industry — already receiving seven awards, including three Site of the Months (from Awwwards, FWA, and CSS Design).

This project reaffirmed that we work with some of the most talented thinkers, doers and dreamers in the business. We’re currently knee deep in some other very cool things, and we look forward to sharing more details of our exploits in the future.


Written by


Jam3 is a design and experience agency that partners with forward-thinking brands from around the world. To learn more, visit us at

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade