Google Pac-Man 2010: el bug de sonido que asustó usuarios

Un doodle que se activaba solo y sonaba sin avisar

En 2010, el doodle de Pac–Man en la página principal de Google empezaba a jugarse solo a los 10 segundos de inactividad, con el sonido encendido. La decisión parecía inofensiva: nadie se queda mirando la homepage. Pero una extensión de Firefox llamada CoolPreviews abría google.com en segundo plano cada vez que el navegador arrancaba. El resultado fue gente que nunca había abierto Google escuchando, de golpe, la sirena de un Pac–Man invisible. En bucle.

La historia la cuenta el propio autor del código, que en ese momento era diseñador en el equipo de experiencia de usuario de Google y no ingeniero de software. Dieciséis años después, sigue siendo un caso de estudio sobre cómo una decisión de producto razonable se convierte en incidente cuando el contexto real de uso no es el que imaginaste.

¿Qué pasó exactamente con el doodle de Pac-Man de 2010?

Google quería algo especial para el 30 aniversario del juego, y el autor terminó a cargo del código por una circunstancia azarosa: su cubículo quedó justo al lado del equipo de doodles. Su título, según cuenta, era apenas adyacente a «ingeniero de software».

Recreó el juego en HTML y CSS, con apoyo de Flash para el sonido, siguiendo el precedente del doodle del iPod que Apple había puesto en sus propias páginas para otro aniversario. El equipo decidió no contactar a Namco demasiado pronto: la idea era impresionarlos con un doodle casi terminado. Mientras tanto, se apoyó en la investigación que fans habían publicado en internet sobre el funcionamiento interno del juego original.

Hubo restricciones deliberadas. El campo de juego tenía que parecerse al logo de Google. Agregó un modo Ms. Pac–Man como easter egg y convirtió el clásico botón «I’m Feeling Lucky» en «Insert Coin». También replicó a propósito bugs que existían en el Pac–Man original, y admitió al menos un bug propio que le explotó en la cara el día del lanzamiento.

El bug no estaba en su código, estaba en el contexto

CoolPreviews era una extensión muy popular en el Firefox de la época: permitía previsualizar páginas con solo pasar el cursor sobre un enlace. Arrancaba junto con el navegador y, sin que el usuario lo supiera, abría una web en segundo plano. Esa web era la página principal de Google. El autor no está seguro de si la decisión era para precalentar la caché o si era un placeholder olvidado.

Vale la pena reconstruir la escena tal como la describe. Alguien enciende su computadora un viernes por la mañana. No usa Google, quizá ni sabe qué navegador tiene, o qué es un navegador. La ventana está minimizada en la barra inferior. Está revisando su correo o abriendo su primera partida de Solitaire. Y de pronto, desde los parlantes, le llega la sirena de un Pac–Man invisible que se instaló en su equipo por la vía más extraña posible. En repetición.

Cuando el equipo sugirió como solución rápida «cierra la pestaña con Pac–Man», la respuesta fue invariablemente: «¿Qué Pac–Man?». Ese detalle es el corazón del problema. El usuario no podía cerrar algo que no sabía que existía.

Por qué el autoplay con sonido fue una decisión de producto, no un error de ingeniería

El proyecto iba bien y la dirección quiso que el doodle se sintiera más grande. De ahí salió la idea de que el juego arrancara solo tras 10 segundos de inactividad, para avisarle al visitante que había algo divertido donde no lo esperaba. El autor estaba cómodo con eso: no le preocupaba la distracción, porque la homepage no era una página donde alguien se quedara.

Sabían que, como consecuencia, Pac–Man también se reproduciría con sonido. En ese momento les pareció que probablemente estaría bien. Con perspectiva, no lo estuvo, pero falló de una forma que nadie anticipó. El propio autor reconoce hoy que esa decisión se parece incómodamente a lo que llamaríamos growth hacking, y ubica la historia en una era más ingenua de 2010.

El parche que se volvió estándar de la web

El lanzamiento se activó a las 9 de la mañana, hora de San Francisco. En pocas horas el mundo se volvió loco otra vez por Pac–Man: entrevistas de prensa, reportes de partidas en todo tipo de dispositivos, y Twitter cayéndose. También llegaron los reportes del tipo «sale un sonido realmente aterrador de mi computadora», pero por canales inesperados.

El autor publicó un parche en horas. La solución fue agregar un botón de silencio visible y exigir que el usuario interactuara primero con el juego —una tecla, un clic, multitouch o el botón Insert Coin— para que el sonido se activara. Como CoolPreviews no hacía nada de eso, el problema de la «computadora poseída» desapareció. Ese mismo enfoque es el que muchos navegadores aplican hoy por defecto.

La ironía final: nunca recibieron reportes de usuarios normales molestos por el autoplay. Muy poca gente se quedaba 10 segundos en la homepage sin hacer absolutamente nada. Lo más aterrador de ese día, dice el autor, fue tener que parchear en vivo la página más valiosa de internet, algo que en su estado de falta de sueño ni registró.

¿Qué significa esto para tu startup?

Este caso no es una anécdota de una empresa gigante: es el patrón que rompe productos pequeños todos los meses. Tu código corre en entornos que no controlás, y el usuario que recibe tu experiencia no es el que imaginaste en el documento de producto.

• Audita qué hace tu producto cuando se carga sin nadie delante. Pestañas en segundo plano, previsualizaciones de enlaces, prefetch, extensiones del navegador, crawlers y clientes de correo pueden abrir tu app sin un humano mirando. Si algo se dispara solo ahí, tenés un incidente esperando.
• Exige un gesto explícito del usuario para todo lo intrusivo. Audio, notificaciones, permisos del sistema, modales y capturas de datos deben activarse con una acción real, nunca por temporizador. Es la misma regla que el autor aplicó a las apuradas y que hoy es estándar en los navegadores.
• Diseña el canal de reporte antes del lanzamiento. El equipo esperaba los reclamos por sus canales habituales y llegaron por otro lado. Si tu único camino de feedback es un formulario que el usuario tiene que encontrar, vas a enterarte tarde.
• Ten un plan de despliegue en caliente probado. El autor pudo parchear en horas porque el proceso existía. Si tu equipo necesita un ciclo de release de días para corregir algo que está afectando a usuarios en producción, ese es el riesgo real.

Conclusión

El doodle de Pac–Man de 2010 fue un éxito enorme y, al mismo tiempo, un recordatorio de que el producto no termina donde termina tu código. Termina donde termina el entorno del usuario: su navegador, sus extensiones, sus hábitos y su nivel de conocimiento técnico.

La lección más útil para un founder no es «cuidado con el autoplay». Es que las decisiones que se sienten inofensivas porque «nadie va a estar ahí» son exactamente las que conviene revisar dos veces. El autor lo resume con honestidad: en el momento pareció que estaría bien, y no lo estuvo, pero falló de una manera que nadie había previsto. Ese es el tipo de riesgo que no se cubre con más tests, sino con preguntarse quién más va a ejecutar esto además del usuario que tenés en la cabeza.