Construyendo un Leaderboard Universal de Juegos Sin Inicio de Sesión
Tenemos más de 25 juegos de navegador y cada uno necesita un leaderboard. Aquí está cómo construimos un framework que se conecta a cualquier juego, recuerda quién eres sin obligarte a crear una cuenta, y evolucionó porque los niños nos dijeron que no era justo.
El Problema: 25 Juegos, Un Sistema de Leaderboard
Cuando tienes un arcade con uno o dos juegos, construir un leaderboard es un proyecto de fin de semana. Escribes un backend, almacenas algunas puntuaciones, muestras una tabla. Pero Vibe Arcade no tiene dos juegos. Tenemos más de veinticinco, y añadimos más regularmente a través de nuestra pipeline nocturna de construcción. Si cada juego nuevo requiriera su propia implementación de leaderboard a medida — su propia lógica de envío de puntuaciones, su propio widget de visualización, su propia conexión al backend — pasaríamos más tiempo en leaderboards que en los propios juegos.
Necesitábamos un framework. Un patrón estandarizado que cualquier juego pudiera implementar, que nuestra pipeline de construcción asistida por IA pudiera conectar a juegos nuevos automáticamente, y que un humano pudiera revisar y aprobar sin necesitar entender las entrañas de cada juego desde cero. El leaderboard no podía ser una idea de último momento atornillada a cada juego de forma diferente. Tenía que ser un sistema de primera clase y repetible.
Filosofía de Diseño: Sin Inicio de Sesión, Baja Fricción
Antes de escribir cualquier código, tomamos una decisión deliberada de UX que dio forma a toda la arquitectura: sin inicio de sesión. Sin creación de cuenta. Sin verificación de email. Sin flujo OAuth. Juegas un juego, consigues una puntuación alta, escribes tu nombre, estás en la tabla.
Esto importa por quién juega Vibe Arcade. Nuestra audiencia es joven. Los niños no tienen direcciones de email para verificar. No quieren crear contraseñas. Están aquí para jugar un juego que encontraron a través de un resultado de búsqueda o un enlace que les envió un amigo, y en el momento en que pones un muro de registro entre ellos y un leaderboard, los has perdido. El leaderboard existe para hacer el juego más divertido, no para ser un embudo de conversión.
Pero "sin inicio de sesión" no significa "sin memoria." El sistema recuerda quién eres para facilitar publicar tu nombre la próxima vez. Si jugaste a Neon Snake ayer y escribiste "Alex" como tu nombre, el sistema rellena previamente ese nombre cuando termines una ronda de Space Destroyers hoy. Puedes cambiarlo en cualquier momento. No hay cuenta, ni perfil, ni datos que tengas que gestionar. Solo un nombre que te sigue por el arcade para que no tengas que reescribirlo cada sesión. Es algo pequeño, pero es el tipo de cosa pequeña que marca la diferencia entre un leaderboard que la gente realmente usa y uno que ignoran.
El Enfoque de Framework
La IA construyó el leaderboard inicial para nuestros primeros juegos, y funcionó. Pero a medida que añadíamos más juegos, surgió un patrón: cada integración de leaderboard se veía aproximadamente igual. El juego necesitaba reportar una puntuación. La puntuación necesitaba ser validada en el servidor antes de llegar al leaderboard. El leaderboard necesitaba mostrarse de forma consistente. El jugador necesitaba introducir un nombre. El nombre necesitaba persistir entre sesiones.
En lugar de reimplementar esto para cada juego, lo extrajimos en un framework. Un patrón de integración estandarizado que cada juego sigue. El juego llama al leaderboard con una puntuación, un identificador de juego y cualquier contexto específico del modo. El framework maneja todo lo demás — envío, validación, visualización, persistencia del nombre. Cada implementación de leaderboard de juego es lo suficientemente similar como para que nuestra pipeline nocturna sepa cómo conectarla a juegos nuevos automáticamente.
Aquí es donde la colaboración humano-IA es más clara. La IA puede replicar el patrón del framework para cada juego nuevo porque el patrón está bien definido y es consistente. Pero un humano revisa la implementación para cada juego nuevo, y la pipeline ejecuta comprobaciones automatizadas para asegurarse de que la integración es correcta. El framework hace predecible el trabajo de la IA y revisable el del humano. Ese es el objetivo de diseño: no automatización total, sino automatización confiable con supervisión significativa.
Versión Uno: Puntuaciones Altas Simples
La primera versión del leaderboard era exactamente lo que esperarías. Juegas un juego. Consigues una puntuación. Si es lo suficientemente alta, va a la tabla. La tabla muestra las puntuaciones más altas, ordenadas de mayor a menor. Simple, correcto y suficiente para la primera ola de juegos.
Las puntuaciones se validan en el servidor antes de llegar al leaderboard. Tenemos limitación de tasa y medidas antiabuso en marcha. No vamos a detallar los detalles de cómo funcionan — esa es seguridad operacional que preferimos no publicar — pero la versión corta es que nos tomamos la integridad de las puntuaciones en serio. Un leaderboard que es trivialmente fácil de hacer trampa es peor que ningún leaderboard, porque destruye la motivación de los jugadores legítimos.
La versión uno funcionó bien para juegos como Neon Snake y Space Destroyers, donde "puntuación alta" es la única métrica que importa. Juegas, acumulas puntos, gana el número más grande. Por un tiempo, eso era todo lo que necesitábamos.
"No Es Justo"
El momento que cambió la arquitectura vino de las personas que más juegan nuestros juegos: los niños.
A medida que añadíamos juegos con múltiples modos de dificultad y variantes, el leaderboard permanecía plano — una tabla por juego, todas las puntuaciones mezcladas. No le dimos mucha importancia. Una puntuación es una puntuación, ¿verdad?
Nos equivocábamos. La retroalimentación empezó a llegar, y era contundente al estilo que solo los niños pueden ser. "No es justo." Un jugador que sobrevivió tres minutos en modo difícil no quiere que su puntuación esté por debajo de alguien que acumuló un número enorme en modo fácil. Un jugador que completó una carrera de velocidad en un modo de desafío cronometrado no quiere competir contra alguien jugando el modo clásico sin tiempo. La injusticia era obvia para las personas jugando los juegos, aunque no fuera obvia para nosotros cuando diseñamos el sistema.
"No es justo si mi puntuación en modo difícil compite contra alguien jugando en modo fácil."
Esa sola pieza de retroalimentación — repetida en diferentes palabras por diferentes jugadores jóvenes a través de diferentes juegos — provocó un cambio arquitectónico real. Necesitábamos leaderboards por modo. No solo una tabla por juego, sino una tabla por juego por modo. El modo difícil tiene su propio leaderboard. El modo fácil tiene el suyo. Los desafíos cronometrados tienen el suyo. Cada modo es su propio contexto competitivo, y los jugadores solo compiten contra otros que jugaron igual que ellos.
La implementación no fue trivial. El framework necesitaba aceptar contexto de modo junto con la puntuación. La visualización necesitaba permitir que los jugadores cambiaran entre tablas específicas de modo. El backend necesitaba particionar las puntuaciones limpiamente. Pero como habíamos construido un framework en lugar de veinticinco implementaciones a medida, el cambio ocurrió en un solo lugar y se propagó a cada juego. Esa es exactamente la recompensa que esperas cuando inviertes en un framework temprano.
Soportando Diferentes Métricas
Los leaderboards por modo no fueron la única evolución. A medida que crecía la biblioteca de juegos, descubrimos que "la puntuación más alta gana" no es la única métrica competitiva que importa.
Algunos juegos están basados en tiempo. En un modo de carrera de velocidad, la mejor puntuación es el tiempo más bajo. El leaderboard necesita ordenar de forma ascendente en lugar de descendente, y la visualización necesita formatear el valor como tiempo en lugar de un total de puntos. Otros juegos pueden rastrear porcentaje de completado, número de movimientos u otras métricas donde "más" no siempre significa "mejor."
El framework ahora soporta diferentes tipos de métrica. Cada juego declara qué tipo de puntuación produce — puntos (más alto es mejor), tiempo (más bajo es mejor), o potencialmente otros tipos a medida que añadimos juegos con nuevas dimensiones competitivas. El framework maneja la lógica de ordenamiento, formato y visualización basándose en esa declaración. El juego no necesita saber cómo funcionan los leaderboards internamente. Solo dice "aquí hay una puntuación, aquí está qué tipo de puntuación es" y el framework hace el resto.
Esto suena sencillo en retrospectiva, pero lo pasamos por alto inicialmente. La primera versión asumía que cada puntuación era un número donde más grande significaba mejor, porque los primeros juegos que construimos funcionaban así. Tomó construir un juego con un desafío basado en tiempo revelar la suposición incrustada en el sistema.
Lo Que Aprendimos
El leaderboard universal es uno de los ejemplos más claros en Vibe Arcade de arquitectura que fue moldeada por sus usuarios en lugar de diseñada por adelantado. No nos sentamos a planear leaderboards por modo o soporte multi-métrica. Construimos lo más simple que funcionaba, lo lanzamos y luego escuchamos.
Los oyentes, en este caso, eran principalmente niños. No leen tu documentación. No presentan reportes de bugs estructurados. Dicen "no es justo" y lo dicen en serio. Y casi siempre tienen razón. Un niño de diez años que se siente engañado por un leaderboard de modo mixto está articulando un defecto de diseño real, incluso si no puede nombrarlo.
La otra lección es sobre frameworks en un flujo de trabajo asistido por IA. Cuando la IA construye un juego nuevo, sigue el patrón de integración del leaderboard. Cuando necesitamos cambiar cómo funcionan los leaderboards, el cambio ocurre a nivel del framework y cada juego se beneficia. La IA implementó los cambios. La retroalimentación vino de humanos. La arquitectura evolucionó a través de la colaboración entre ambos.
No empezamos con la arquitectura correcta. Empezamos con una suficiente y dejamos que el uso real — niños reales, jugando juegos reales, diciendo cosas reales sobre la justicia — nos dijera a dónde tenía que ir. Si hubiéramos diseñado el sistema "perfecto" desde el principio, habríamos pasado semanas construyendo funciones que nadie necesitaba aún y probablemente nos habríamos perdido las cosas que realmente importaban. Los usuarios lo sabían. Solo teníamos que escuchar.
Lectura relacionada: ¿Qué Es Vibe Coding? · Cómo Construimos Neon Snake · Cómo Construimos Space Destroyers · Herramientas de Vibe Coding: De Chatbots a IDEs con IA