Pac-Man’s Siren Call

The story of a most unusual bug on a most unusual day

Friday, May 21, 2010, might have been a usual Friday for most. For me, however, it could hardly have been more unusual.

This was the day I broke Twitter. The day I talked to my father for the last time. The day something I made was experienced by hundreds of millions of people. But this story is about none of those things. This story is about how I made some people feel like they were going crazy.

Back in 2010 I worked at Google, and I was roped in to research and code the Pac-Man doodle — the interactive 30th anniversary celebration of the classic arcade game we chose to put on Google’s homepage. I spent a few prior months writing all of the code from scratch (there was no emulation involved) and that Friday, at 9am Pacific Time, we were finally unveiling it to the world.

This was the first proper interactive doodle, and the first thing truly competing for attention with Google’s search box. So among the design decisions we needed to make was finding a good balance between promoting the doodle, and just allowing people to complete their search and move on with their lives.

After a lot of deliberation, we decided to do the following:

  • automatically start playing the doodle if visitors kept the homepage open for 10 seconds (of course, they could start playing earlier if they clicked on the doodle or the special Insert Coin button)
  • start the doodle with the sound on (otherwise many might not realize sound was even available and have less fun playing the game)
  • keep the Pac-Man doodle around for 48 hours instead of the usual 24 hours

Aggressive? Perhaps. But we had a freaking Pac-Man game on our homepage. We felt rather proud of it and we wanted people — unaccustomed yet to Google’s homepage being playable — to know about it and enjoy playing it.


Even before the launch, it already seemed like an unusual Friday. We had never done anything like this doodle before. A couple of people on the team and I pulled an all-nighter that included a photo session and preparing an internal tournament version of Pac-Man. Personally, I was petrified. I was a designer on the user experience team. Sure, my code went through all the proper reviews, but I still couldn’t believe it would be allowed — verbatim — on one of Google’s most valuable properties.

We toggled the switch at 9am. Within hours, the world went crazy for Pac-Man. Soon, I watched feedback arrive in torrents too huge for me to ever catch up with. I was suddenly asked to do press interviews. And when I said “I broke Twitter” above, it might have been a selfish oversimplification (I couldn’t have made any of it happen without the entire great team next to me), but I don’t think it was an exaggeration. Within an hour, after watching more and more Google Pac-Man tweets come in, Twitter started greeting us with this:

But amidst all the excitement — accentuated by sleep deprivation — we started getting reports of a weird problem. Namely, some people were hearing Pac-Man sounds… even though they weren’t playing our Pac-Man.

We initially brushed off these complaints — “tell them to just close the Google homepage” — but that didn’t help. After poking here and there and racking our brains, the culprit turned out to be more complicated… and infinitely more fascinating.


2010 was the best year for Firefox. And some people using that browser installed an extension called CoolPreviews, which allowed them to quickly preview pages by hovering over links.

The extension would start at the same time Firefox was opened. And it would immediately, in the background, invisibly and unbeknownst to the user, open a website. That website was Google’s homepage.

You probably already put together what happened. On that particular Friday, google.com had an auto-playable Pac-Man doodle with the sound on. If you used Firefox with CoolPreviews installed, the plugin would quietly open Google’s homepage in the background whenever you launched the browser, and 10 seconds later…

…game sounds would start playing out of nowhere.


Imagine this for a second. You sit down Friday morning and power up your computer. For you, there’s nothing unusual about this Friday. You open your browser. You might not know about CoolPreviews, or even the concept of plugins or extensions. You don’t have to use, or even know about Google. You might not know what browser you use — or what a browser is. As a matter of fact, you might not even be using your browser; perhaps it has been minimized and sits unobtrusively in the toolbar at the bottom of your screen. Perhaps you’re just checking your mail or warming up for today’s first round of Solitaire.

It doesn’t matter what you do. Ten seconds later, coming from your computer’s speakers — do you know how to change their volume? do you even know your computer has speakers? — you hear this.

It’s the siren of an invisible Pac-Man game having infiltrated your computer in the most unusual manner.

On repeat.


Maybe you’ve been in a situation where less tech-savvy friends or family members pester you with computer problems that have trivial solutions. “Are you sure the mouse is connected?” you might sneer. “Try turning CapsLock off. Jesus.”

Now imagine: what would you say if you got a message from one of them that Friday telling you their computer was making siren-like sounds for no reason?

You’d tell them they sounded crazy. They might have thought they themselves were crazy. And it was my code that made all of it happen.


I don’t remember how exactly we figured it all out. But within an hour, we coded in and immediately released a two-fold fix:

  • we added a visible sound on/off toggle that allowed people to mute or un-mute the game at will
Before and after. Note the sound icon in the lower-left corner.
  • we did not remove autoplay, but we changed the code to not make any sounds until the visitor interacted with the game in some way
/**
* Process a new Pac-Man direction requested by player
* using arrow keys or touch.
* @param {number} newDir New direction.
*/
PacManActor.prototype.processRequestedDirection = function(newDir) {
// Enable sound as long as the user hasn’t previously
// disabled it by clicking the sound icon.
if (!pacMan.userDisabledSound && !google.pacManSound) {
google.pacManSound = true;
pacMan.updateSoundIcon();
}

It is natural, whenever one encounters a bug, to try to answer four simple questions:

  1. What happened?
  2. How to fix it?
  3. How to prevent it from happening again?
  4. Who’s to blame?

This time around, the first three were easy: we figured it out, we patched it up, and we instituted our quick fix as a best practice for every future doodle.

As for the last one… “Who’s to blame?” is rarely a good question, but let’s entertain it here for a second:

  • It was our fault. We should have predicted this, right? But look at the nexus of all the coincidences: a specific browser, a specific unusual plugin, sound on, needing to wait 10 seconds for the issue to occur. How big of an imagination would it require to anticipate this?
  • Clearly, CoolPreviews had some shoddy programming practices! I’m actually not sure why they started by opening Google’s homepage in the background — was it just a random default? or a way to test the internet connection? But then again, Google’s homepage can withstand a lot of traffic, and, crucially, it’s never made any sounds before. It didn’t seem ridiculous to assume there would be no danger in opening it in the background.
  • It’s the user’s fault for installing CoolPreviews to begin with. If a plugin is causing a problem, it’s on them to uninstall it. But, how do you imagine anyone realizing a random preview extension could be responsible for making sounds on their computer?
  • Browser makers should not allow plugins to do crazy stuff like this. Quite possibly; these days, browsers don’t. But back then, the web was a bit more open… and after all, there was nothing in that bug that threatened your privacy, or the safety of your data.

The best answer to the question “who’s to blame?” I can think of is: the complexity of the web. The web’s been around for a while, many stakeholders were involved, the web’s open and forgiving, and some parts of it just sort of… happened.

Wanting to punish the web for its complexity is like Xerxes whipping the sea for swallowing his shitty bridge. Running away from the web towards native clients might be exchanging one set of problems for another. Wanting to reduce the web’s complexity is… actually, it’s something many smart people do as their jobs or in their free time.

Either way, bugs need to be fixed.

One way of fixing bugs is in advance, by building elaborate mechanisms to identify issues and prevent them from going live. Sometimes, of course, you have no choice and that is the only way. Anything to do with user data, privacy, safety, or financial information, is off limits — it needs to be meticulously tested and controlled, and there’s no wiggle room.

But then there’s stuff like this, what we’re talking about here. I’ve written about other strange bugs before on Medium, like the disappearing Polish S, and the 25-year-old System font rising from its pixellated grave… and now one Pac-Man game making strange noises on a small fraction of computers. Bugs that occur far away from your servers, in situations you cannot fully anticipate. Bugs of less severe consequences. You can try to prevent bugs like that from happening, but at some point it’s easier to assume they will happen, and redirect your efforts to building infrastructure to catch them and then to fix them as quickly as possible.

What I believe to be the real achievement in solving the Pac-Man bug was two tight loops: first, the communication between the support team and product people… and second, the prescient “hot push” infrastructure that allowed us to get our fix deployed within minutes, which is incredible at Google’s scale.

That Friday in 2010 was an unusual Friday for me, but I also know that my work made it an unusual day for many more people. Some were reminded of those times in the early ’80s when they played Pac-Man. Some got excited about the possibilities of HTML. Some just had a bit of fun playing the game, and then moved on.

One of my favorite reactions from that day was this one — the idea that for those 48 hours in 2010 we brought back the spirit of arcades I loved when I was little:

“I hear three simultaneous games of Pac-Man in this coffee shop. I kind of love you, Google.”

I hope you weren’t one of the people who encountered the bug I introduced that day. If you were, and my code freaked you out, I apologize. But I know for as long as I’m writing code, there will be bugs to deal with. Mine or others. Finding a balance between identifying, prioritizing, and squashing them before launch (which takes time) or after launch (which affects people) is going to continue to be one of the bigger challenges I face.

The other fun part is that, back in 2010, I also had to reintroduce a bug from the original Pac-Man code… but that’s a whole different article.

In the meantime, I would love to hear your bug story. What is the weirdest, most unexpected, flat out coolest bug you played a part in creating? It’s all too easy to think about these sorts of things as mistakes or failures best fixed and forgotten. But they also tell us something true about the world we have created, and the wonderful, crazy complexity of the technology that underpins it.

To share your story, write a response to this post and tag it ‘a bug’s life’.

Thank you to Ryan Germick and Kris Hom for their collaboration on the doodle. Interested in more secrets of Google Pac-Man? Watch a talk from Google I/O 2011. If you want to read a great story of how many random circumstances intersect to create an otherwise impossible to predict situation, pick up Stanisław Lem’s excellent novel The Chain of Chance.

The photos in the article were taking during the all-nighter before launch. Thank you to Dan Pupius and Jamie Talbot for their help on the article.