BingoLive.online: cómo un proyecto lúdico se convirtió en laboratorio técnico

El origen del proyecto

Creé BingoLive cuando los juegos de casino online ganaban popularidad en Francia, impulsados en especial por el crecimiento de los directos de Twitch y de su público.

Mi idea era crear una alternativa gratuita, aunque imperfecta, para quienes quisieran disfrutar de algunas de esas mecánicas sin apostar dinero real.

El servicio no debía solicitar depósitos, vender créditos ni ofrecer premios canjeables. El único objetivo era conservar el aspecto lúdico del sorteo, los cartones y el directo.

Sin embargo, sabía que esa solución no podía presentarse como un método para superar una adicción. Un juego gratuito no sustituye la ayuda especializada cuando existe un problema real de adicción.

Mis objetivos técnicos

Cuando comencé este proyecto, principalmente quería aprender JavaScript a un nivel más avanzado y comprender cómo funcionan las plataformas de streaming.

Los streamers de la época transmitían principalmente su contenido en Twitch. Para adaptarme a los hábitos del público objetivo, quería retransmitir el sorteo en esa misma plataforma.

El proyecto superó rápidamente el alcance de un simple frontend y exigió varios componentes capaces de funcionar de forma coordinada.

La arquitectura inicial

La primera versión de BingoLive se basó en una arquitectura compuesta por varios componentes distintos.

El frontend mostraba los cartones, el último número sorteado, el historial de la partida y el chat. Las API proporcionaban al cliente el estado actual, mientras un orquestador en el servidor iniciaba las partidas, gestionaba los temporizadores y extraía los números.

El servidor seguía siendo la fuente única de verdad. El cliente nunca decidía el resultado del sorteo: recuperaba el estado a través de las API y actualizaba la interfaz.

Esta separación evitaba que cada navegador generase su propia versión de la partida y garantizaba un estado coherente para todos los usuarios.

La difusión en Twitch

Para el directo de Twitch, un Raspberry Pi mostraba el motor de sorteo a pantalla completa. La señal se codificaba en H.264 y se enviaba a Twitch mediante la cadena de streaming.

Roger Chaudet, de Spatiograph , diseñó la UI/UX y los recursos gráficos del sorteo, incluidas las bolas. Su trabajo dio al proyecto una identidad visual propia.

Twitch aportaba la experiencia visual y comunitaria, pero introducía latencia de forma inevitable. Por ello, el vídeo no podía ser la referencia técnica del estado de la partida.

Sincronización en tiempo real

Uno de los aspectos más interesantes del proyecto se refería a la sincronización entre el motor de sorteo, el directo de Twitch y los navegadores de los usuarios.

Con cada nuevo número, el orquestador actualizaba el estado del juego. Los clientes web recuperaban esta información mediante las API y mostraban de inmediato el último número sorteado.

Esta ayuda visual era fundamental, porque el directo de Twitch podía llegar con varios segundos de retraso. Así, el jugador podía seguir sus cartones con precisión aunque el vídeo no estuviera perfectamente sincronizado.

Este proyecto me permitió trabajar en varios problemas típicos de los sistemas distribuidos:

• gestión del estado actual;
• orden de eventos;
• reconexión de un cliente durante el juego;
• recuperación del historial de sorteos;
• gestión de latencia;
• coherencia entre varios clientes conectados.

La generación de cartones

Generar los cartones también requirió un algoritmo real. No quería simplemente colocar números aleatorios en una cuadrícula.

Los cartones debían respetar la estructura real del bingo: distribución de los números por columnas, un número determinado de casillas ocupadas por fila y ausencia de duplicados inconsistentes.

Los usuarios podían recibir varios cartones durante una partida. Por lo tanto, el sistema tenía que:

• generar cartones válidos;
• vincularlos al usuario correcto;
• mantener su estado durante todo el juego;
• comprobar automáticamente los números ya sorteados;
• detectar combinaciones ganadoras.

Todo el sistema se apoyaba en API que conectaban el frontend, el backend y el orquestador.

Inicio de sesión, chat y localización

El público objetivo incluía personas poco familiarizadas con la informática. Por lo tanto, integré un inicio de sesión simplificado mediante Facebook para evitar crear una nueva cuenta con una contraseña adicional que recordar.

El chat también fue un componente importante. El bingo es un juego social: sin interacción entre los jugadores, la experiencia rápidamente se parecería a un simple generador de números.

También implementé la detección del país y la localización de la interfaz. Para mantener una experiencia coherente, el chat debía adaptarse igualmente, ya fuera separando las salas por idioma o aplicando una lógica de traducción apropiada.

Esta parte me permitió trabajar en la internacionalización, la detección de idioma y región, el contenido traducido y los límites de la geolocalización automática.

Escalabilidad y balanceo de carga

En el apogeo de su actividad, BingoLive atrajo a unos 1.300 usuarios. Esta cifra no corresponde necesariamente a 1.300 conexiones simultáneas, pero fue suficiente para revelar los límites de la arquitectura inicial.

Tuve que trabajar en el equilibrio de carga del lado del servidor, la supervisión del servicio y la eliminación de varios puntos únicos de fallo.

Fue una de mis primeras experiencias prácticas de balanceo de carga en una aplicación en tiempo real.

Los datos recuperados a través de Google Analytics también mostraron una proporción significativa de usuarios de dispositivos móviles. Así que revisé la interfaz para que sea realmente responsiva y permita utilizar los cartones desde un teléfono móvil.

VPS, red local y OpenVPN

BingoLive utilizaba una arquitectura híbrida.

La interfaz, las API y el orquestador estaban alojados en mi VPS Ionos. La cadena de streaming, basada en un Raspberry Pi y codificación H.264, funcionaba en mi red local.

Por tanto, era necesario mantener una conexión permanente entre estas dos infraestructuras. No quería abrir varios puertos en mi red local ni exponer directamente los servicios internos a Internet.

Configuré un servidor OpenVPN para crear un túnel permanente entre mi infraestructura local y el VPS. De este modo, los diferentes componentes podrían comunicarse a través de una red privada común.

Esta elección me permitió trabajar de forma práctica en:

• rutas de red;
• túneles VPN persistentes;
• comunicación entre un VPS y una LAN;
• reconexión después de un corte;
• reducción de la superficie expuesta públicamente.

Una arquitectura que se ha vuelto demasiado compleja

Lo que empezó como un proyecto sencillo para aprender JavaScript terminó convirtiéndose en una arquitectura con frontend, backend, API, orquestador, VPN, Raspberry Pi, cadena de codificación H.264 y emisión en Twitch.

El sistema funcionaba, pero requería un cierto nivel de mantenimiento en cada arranque y en caso de incidencia.

Dejé que esta arquitectura funcionara durante unos seis meses antes de tener que reasignar el Raspberry Pi a otros proyectos.

Volver a poner en marcha toda la infraestructura solo para BingoLive acabó requiriendo demasiado tiempo, así que el proyecto quedó inactivo durante una temporada.

Relanzamiento gracias al vibe coding

Gracias al vibe coding, por fin encontré tiempo para retomar el proyecto y modernizar su arquitectura.

El primer cambio significativo fue el cese de la emisión a través de Twitch. La pantalla que anteriormente se mostraba en el Raspberry Pi y se enviaba a la plataforma ahora se muestra directamente en el navegador de cada cliente.

También aproveché para añadir varios minijuegos, incluida una versión gratuita de blackjack, pachinko y una ruleta inspirada en los juegos de casino.

Estos juegos utilizan exclusivamente puntos virtuales gratuitos. No admiten depósitos, retiradas ni premios con valor económico.

Los límites del proyecto

BingoLive puede ser una alternativa gratuita para las personas que quieran disfrutar de determinadas mecánicas de juego sin correr el riesgo de perder dinero.

Sin embargo, este tipo de servicio no debe presentarse como una solución médica o un método de deshabituación. Los sorteos aleatorios, las animaciones y los puntos pueden seguir reproduciendo determinadas sensaciones asociadas al juego.