Crashout: Un Juego de Carreras Multijugador Hecho para Eventos en Vivo

La mayoría de los juegos multijugador asumen una audiencia cautiva y técnica: una app ya instalada, una conexión estable, jugadores que ya conocen los controles. Nada de eso se cumple en una fiesta corporativa, una activación de marca o una salida con amigos. El onboarding tiene que funcionar para un invitado que nunca vio el juego, con cualquier celular que tenga a mano, sobre el wifi que el lugar ofrezca.

Además, una sola persona tiene que poder manejar el evento de punta a punta —arrancar una carrera, resetearla, arrancar la siguiente— desde una tablet, sin acercarse nunca a la TV. Y cada pantalla en la sala, desde la pantalla grande hasta el celular de cada jugador, tiene que coincidir exactamente en qué está pasando en cada momento, o todo se desarma en vivo frente a la gente.

Elegimos el onboarding más simple posible: un código QR en la pantalla grande, una pestaña del navegador en el propio celular del jugador, sin app, sin cuenta. Escanear, escribir un nombre, elegir un auto, arrancar a manejar. Esa única decisión determinó casi todo lo demás del producto.

La otra decisión clave fue hacer que el servidor sea la única fuente de verdad para todo el juego. Ningún cliente —ni la pantalla grande, ni el celular de un jugador, ni el controller del anfitrión— puede decidir por su cuenta qué pasó en la carrera. Solo renderizan lo que el servidor les dice. Eso es lo que permite que una sala llena de celulares de desconocidos, sobre un wifi impredecible, coincidan todos en la misma carrera.

El backend es un servidor en Go construido sobre el router HTTP de la librería estándar y una librería liviana de WebSocket, sin ningún framework web de por medio. Cada evento tiene su propia sala, y cada sala es dueña de su propia goroutine de simulación y su propio canal de entrada: las salas nunca comparten estado ni se bloquean entre sí, lo que mantiene simple razonar sobre un juego con decenas de eventos simultáneos.

La simulación corre a un tick interno de 60Hz, pero solo transmite un snapshot a los clientes 20 veces por segundo, y el cliente interpola entre snapshots para lograr movimiento fluido. Esa proporción no es arbitraria: originalmente corríamos el tick y el snapshot en una relación 30/20, que producía un patrón de transmisión irregular de 33/33/67 milisegundos y se notaba como un tartamudeo visible en la pantalla grande. Pasar a una relación 60/20, un múltiplo exacto, da una cadencia perfectamente uniforme de 50 milisegundos y lo solucionó. Es un buen ejemplo del tipo de detalle que solo se nota cuando estás viendo una carrera correr en una TV real.

Tres pantallas se conectan a ese mismo servidor: la pantalla grande renderiza la carrera y el QR del lobby en canvas, la página de joystick convierte el celular de un jugador en dirección y bocina, y el controller le da al anfitrión inicio, reset y configuración. Un cuarto modo, una carrera demo de un solo dispositivo, reutiliza exactamente el mismo protocolo: solo abre dos conexiones WebSocket desde un celular en vez de inventar un nuevo rol de cliente.

Todo eso corre repartido entre dos proveedores. El frontend está en Vercel — cada una de las tres pantallas es simplemente una ruta de la misma app Next.js, que llega al backend por orígenes WebSocket y REST absolutos, fijados en tiempo de build. El backend es deliberadamente aburrido: una sola instancia EC2 en us-east-2, provisionada con Terraform. Sin contenedores, sin orquestador, sin balanceador de carga.

Caddy va adelante, terminando TLS para cada conexión WebSocket con certificados que él mismo emite y renueva contra Let's Encrypt — los puertos internos del backend nunca son accesibles desde afuera. Todo lo que tiene que sobrevivir a un proceso vive en PostgreSQL en una máquina aparte, con conexión por SSL y migraciones que corren al arrancar. Los deploys son lo único que hace GitHub Actions: lint, typecheck, tests y build corren localmente antes de cualquier push.

Como Crashout corre en eventos en vivo, un deploy nunca puede interrumpir una carrera en curso. Corremos producción detrás de slots de deploy blue/green en la misma máquina, y una señal de apagado le indica al slot viejo que drene —termine las carreras que estén corriendo, rechace las nuevas— durante hasta tres horas en vez de cortar las conexiones de inmediato. Los clientes anclan sus reconexiones al slot en el que arrancaron, y un token de reanudación le permite a un jugador cuyo celular se cae en medio de una carrera volver a exactamente el auto que estaba manejando.

Más allá del loop de carrera principal, el producto creció hasta ser una herramienta completa de operación de eventos:

Crashout lleva alrededor de cinco meses y medio de desarrollo continuo y activo, y lo construimos con el estándar de software de producción, no el de un prototipo de juego para fiestas: