blog|Behind the Scenes

Behind the build: 2025's BFCM globe in a pinball machine 🌎🕹️

Real-time merchant sales rendered on our globe, Easter eggs galore, and a pinball machine because... why not?

Published on
Shopify 2025 BFCM Live Globe

Every year on the Black Friday Cyber Monday (BFCM) weekend, we handle bigger spikes in traffic and sales than ever before. We prepare long and hard for this massive feat of engineering, but the real magic is in the merchants behind the numbers.

Each order means an entrepreneur has made a sale. Maybe it's their very first. Maybe it's their 10,000th. Regardless, on top of maintaining our platform performance, we like to showcase the meaning behind each order. We do this with our live globe, where you can watch commerce happening in real-time around the world.

For 2025, our globe was... a pinball machine. Well, technically the globe was within a pinball machine. If that sounds ridiculous, it was, and it was amazing. It's the perfect example of our unserious exploration in action.

Senior Engineer Daniel Beauchamp says he clocked 400 hours on the pinball machine before it went live, so he had a thing or two to say about how he and his team built it:

It’s a three.js app built with react-three-fiber. Our favorite stack.

When a merchant makes a sale, it shows up seconds later on this globe. Every arc is a real order. We use server-sent events to stream the data in.

Every pinball table needs a good dot matrix display. We wrote a shader that would playback 128x32 pixel sprite sheets. Making these animations was too much fun.

We wanted a game that celebrates merchant moments in realtime. So every time a milestone is reached, like hitting 10K, 100K, 1M orders, the board reacts. When our merchants win, you win.

There’s also an amazing first sale multiball:

The physics are all done in 2D for performance reasons. While 3D is more realistic, it’s not worth the extra cpu cycles.

We used the js version of rapier2D, and raycast to the floor to handle ramps and elevation. It brought our physics step from 2ms down to 0.2ms.

The scene is full of things to interact with. There’s a desktop monitor that you can use to see realtime Shopify infrastructure stats and also discover fun Easter eggs.

And of course the pinball table works in AR, thanks to the amazing @react-three/xr library. Only 100 lines of code or so to wire it up. People can load it up in their fav headset to play it in their space!

In addition to playing pinball, you can poke around and do highly important things like add pineapple to pizza, make a rubber duck quack, and find secret codes hidden throughout the scene.

Some real-time engineering stats were displayed on the computer monitor:

And who can resist clicking on a folder that says "Behind the scenes"?

The team's README: "No one will read this blog."

Me, writing it anyway: 🫡

Moving on... Here's some content that was hidden away in those files.

Design notes

This section was written by Staff Product Designer Brennan Letkeman.

Boring philosophy stuff

Before this project I didn't actually know much about pinball. Like, obviously I knew what it was and had played them in some arcades and things, but over the course of designing this table we really went down the rabbit hole into a deep and charming world of people who really, really love the game.

As a designer, it's cool to sit with subcultures and try to learn what makes them tick. This is often to an aesthetic end - what sorts of things do you see often and how can you reproduce them - but those are just the outputs of the crowd; the real juicy part is the what and why and how did they end up with those outputs, what are their ethos and personalities and goals that arrived at those outputs.

Pinball, to me now, is this expression of fun through precision in the face of chaos. When you first play you're just trying to keep the ball alive long enough to not lose your quarters, but as you build up those basic skills you start to unlock more advanced ball control and realize that each table has a specific flow. Then you start realizing that different tables from different eras, companies and specific designers have different vibes - you start to have opinions and preferences for this machine or that one. You have a play style. You like and dislike certain elements.

To steal a term from the video gamers, pinball is often a game of executing _frame perfect_ shots. Some tables are more or less generous with this, but at the far end of the skill curve are shots that you can only make if you hit the flipper exactly millisecond perfect, and sometimes multiple times in a row. It's a game of random physics happening, sure, but it's also a game of being in explicit command of the timing. That alternating back and forth from control to chance is, I think, one of the most unique parts of pinball as a genre, and what gets that flow state going.

What we wanted

One thing we all agreed on is we liked long flowing rallies over the more staccato bouncing of certain games. We didn't like ball locks, which interrupted the rhythm. We liked big ramps and the chance for a third flipper shot where you go all the way around the top and then - if you time it just right - the perfect place for the third flipper to get the otherwise inaccessible target.

But we also had an entirely virtual world to play with, so then it’s like: what else can we do with this?

The Underground Era

So one of our first big twists is that the board originally went “underground” and there was a full second board that was hidden “inside” the machine cabinet.

I was thinking we’d theme it appropriately, with the wires and gears and mechanisms lining the walls of the play space, dramatic spotlights lighting the middle, and some sort of WarioWare style minigame system where every time you ended up down there, we’d randomize from a collection of simple single-verb skills shot activities.

The first ones, just to have something to work with and hack on, were a soccer goal with a goalie that moved left and right, and a basketball hoop in the style of 1995’s Shaq Attack.

It was boring.

There were a few problems:

Having a full size table worth of play space to make a mini game’s worth of content was weird and felt wrong. You can contain it and lower the play area and make nice decorations around but then you have to ask why you’re bothering at all.

But also, we have to support mobile and VR which are platforms where it’s far worse or impossible to move the camera around arbitrarily.

So we went down that path for a week or two and ultimately cut it.

The modular minigame

By that point, though, we liked the idea and had a list of a half dozen little minigames we were excited about, so we needed them to go somewhere.

In some of my early sketches, I originally drew a carousel under the globe, and that was a throwaway idea for a second: the concept was that since we had the big globe there (and we always had the globe there, for obvious reasons) we could have a big turret that spun around it and contained a variety of targets to shoot.

What we learned is that it is actually pretty decent to just have a rotating cast of these single action goals. What we also learned is that having them all work at the same time and with a fixed position is tricky.

For example, the first sale tower is really tall - how would we make that rotate under the ramps and rails?

But if it came up through the floor…

And so the modular minigame was born.

It was convenient for many reasons, but a free bonus is that they were extremely easy to swap out, which is much easier than committing to permanent parts of your board during development. Permanency has implications for the model, but also light baking and materials and programming the logic for each thing together and so on. Modularity is lovely.

The other thing it gets us is unbinding the relative location of each mini - the milestone can interrupt minigame #1 and then when you finish that you can go to minigame #3 and then first sale happens and it goes back to #3, you beat that and go to #4 or #5 and so on.

Ramps are hard

Originally I had designed these intricate ramps that split into and out of each other, which is a real thing different tables do, but it was extremely tricky to program with our 2D physics engine because there was no real true gravity -- there was nothing to bring the balls downward (into the table).

I’m sure there would have been ways to overcome this in the programming, but the truth was it didn’t feel like it added much to the game.

The biggest change we made (and you’ll see this as a core shift in the renders and sketches) is adding the main central lane back into the pop bumper zone.

It changed the whole feel.

Originally that middle area was a few ramp entrances and some walls. We thought this was a pretty normal arrangement of elements from real tables, but for some reason it felt really claustrophobic and frustrating. Because that’s a natural place for your flipper shots to most often end up, and because it just sort of stopped you immediately, even with targets and things to hit the overwhelming feeling of that play wasn’t flow but rejection.

Opening it up into another path that took you up and away from the flippers was fresh air for this table.

The other ramps moved around, but they’re sort of just ramps either way. I like that we ended up with an easier one and a more difficult one naturally.

Pinball as she is played

The rest is pretty much just standard pinball.

We thought a lot in the beginning about being weird with it - sideways gravity, a left-right tilt system, the table rotates and the walls are the new floor, the underground part as mentioned above, etc etc.

But in the end, sometimes you just gotta make a normal thing really well.

I’m glad, now having spent hundreds of hours crafting (and as many play-testing it), that we went with a normal table.

It lets you obsess over the important bits instead of just trying to barely figure out the novelty bits.

Engineering notes

Senior Engineer Diego Macario Bello and Distinguished Engineer Daniel Beauchamp shared some engineering insights in another "behind the scenes" folder. Here's what they wrote:

On the surface pinball is a very simple game, but when you dig deeper you find an incredible number of systems that need to work together to create a fun experience. You have things like:

  • A physics simulation that needs to resolve high speed collisions with a myriad of objects like flippers, pop bumpers, slingshots, kickers, spinner targets, etc.
  • A light system that needs to control dozens of lights (in our case 86) to play fun animations and communicate things like missions, bonuses, special events, etc.
  • A sound system that needs to play both mechanical and electronic sounds to create an engaging experience.
  • A dot matrix display (DMD) that needs to render dozens of different animations.

The fact that pinball machines are built in real life feels like nothing short of a miracle after overcoming all the obstacles required to simulate one with software.

Physics

When we first started working on this project we were using the Rapier 3D physics engine. We thought using a 3D engine would make it easy to handle things like ramps. You just create a collider for the ramp and allow the physics engine to roll the ball up and down the ramp.

As our scene grew more complex, we found that our pinball machine stopped feeling good on older mobile devices. The math required to do a 3D physics simulation was too much for those devices, specially when events like multiball were triggered.

At that point we made the hard decision to pivot to the Rapier 2D physics engine. We had to refactor a lot of code, but we knew it would be worth it in the end.

You might find this surprising. How does our ball go up and down ramps and get thrown by Shoppy if we are using a 2D physics engine?

To make that work we had to create a system of sensors that activate and deactivate colliders as the ball moves around. When the ball touches the entrance of a ramp, for example, all the colliders on the table get disabled except for the colliders of the ramp. When the ball touches the exit of a ramp we do the opposite. It's all a carefully orchestrated dance.

It was painful to pivot to 2D, but everything got better after that. Even with 6 balls on the table with continuous collision detection (CCD) enabled on them, our physics step is on average 0.2 milliseconds long, which leaves plenty of room for rendering fun things like confetti!

Rendering

On the rendering side, this entire website is powered by Three.js and React-Three-Fiber (R3F). Three.js is an incredible render engine, and the composability added to it by R3F makes it easy to build any system you can dream up.

Most of the materials in our scene are MeshBasicMaterials because our lighting was baked in Blender. This is great for performance!

State management

For state management we use zustand, which is probably one of the best open source projects out there right now.

Pinball lighting

One of the most important parts of bringing the table to life was adding dynamic lighting. A dance of flashing and pulsing lights is synonymous with pinball. But our table has a total of 85 lights, which would be impossible to represent with forward-rendering and point lights. We had to figure out a way to animate and display table lighting.

To do this we had two textures for the floor; one with the base color, and one with only the emissive lights. Then we generated a separate texture that masked out each emissive light. The "R" channel encoded the light id:

This meant that for every pixel in our mask we could find out what light it belonged to.

We could use that light index to conditionally turn on and off that light in the emissive map:

lightValues is a uniform float array with all our current light values in it. We came up with an animation system that let us play out different lighting effects and drive that lightValues array.


Dot Matrix Display

The Dot Matrix Display, or DMD, had an extremely important job. Not only did it have to show your pinball score, but it had to show the live sales stats. We made a simple system that could load in individual spritesheets and then merge them into one gigantic spritesheet.

Each frame the CPU would figure out what part of the spritesheet it should render, and upload the texture offsets to the GPU. The frame size was 128x32, just like an old school DMD. It was a shader that was then driving selecting the right part of the image and rendering it, along with applying a dot effect to create the iconic matrix display look.

Our post-processing stack with bloom really took the effect to the next level by giving it that warm glow.

Mini games

One thing we are pretty proud of is the mini game system that's in our pinball machine. There's five different mini games and two special mini games that are triggered by live data.

When a user completes a mini game, it gets lowered into the ground and a new one rises. This is fast and fun, but there are lots of edge cases that we had to consider while building this. For example:

  • What if there's a ball in the mini game area when you complete a mini game? We need to wait until it exits the area before doing the swap.
  • Now what if you have 6 balls in play? Then we need to check that none of them are in the mini game area before doing the swap.

The ramifications are insane. Note how when a swap starts, we quickly raise a metal fence in front of the mini game area. That's for preventing you from messing around in there when a swap is happening!

Personal notes

Everyone on this team played Space Cadet pinball growing up in the 90s. A lot of us played it in the computer room of our elementary schools, but not one of us imagined that we would one day try to build a game like Space Cadet.

Building a pinball machine is both deeply humbling and deeply rewarding. It seemed so easy in the beginning.

We hope you enjoy playing it as much as we enjoyed building it.

Data notes

A couple of data insights from Principal Data Engineer Joir-dan Gumbs, Senior Staff Data Engineer Trish Gillett, and Staff Data Engineer Dimitri Yacoub:

What you're seeing on the BFCM Globe is commerce at planetary scale, powered by stream processing data pipelines built to handle Shopify's biggest weekend of the year.

Every arc represents a real order, drawing an as-the-crow-flies path from shop to buyer. Under the hood, Apache FlinkSQL pipelines process a firehose of events to define arcs and compute sales and buyer metrics, and Grafana powers our infrastructure stats.

The data is sent over the browser using Server Sent Events. You can open up your network tab and see the data coming in for our nerd infrastructure stats, sales metrics, and arcs.

Live on Sphere

If you haven't noticed by now, we're pretty big on our globe. So for the third year in a row, we put it on the biggest LED screen in the world: the Exosphere in Las Vegas.

Fun fact: All of these shots of Sphere were captured by drone and helicopter only four hours before this video went live. The footage was driven to our makeshift edit bay in a Wynn hotel room, edited at the speed of light, and then published same-day. Just one of the many fun challenges our team conquered this BFCM.

That's a wrap for 2025's live globe build recap. Time to start dreaming up 2026...

If you’re interested in joining us on our mission to make commerce better for everyone, check out our careers page.

SE
by
Published on
Share article
Work from anywhere
with Shopify

See our open roles and learn more about our digital by design culture.

See open roles