Proyecto full stack colaborativo · Sistemas de juego realtime
DuckyArena
Batallas 3v3 de Duckies en tiempo real donde la estrategia oculta por líneas y las respuestas técnicas deciden una partida autoritativa al mejor de tres.
Seis jugadores autenticados entran en una sala privada, forman los equipos BLUE y RED, eligen Duckies distintos, ocupan en secreto tres líneas y revelan tres enfrentamientos 1v1 simultáneos. La corrección, el tiempo de respuesta y las Signature Abilities alimentan un motor de combate determinista; el primer equipo que gana dos líneas se lleva la partida.
ReactViteNode.jsExpressSocket.IOPostgreSQLDockerGitHub Actions
Resumen
DuckyArena es un juego web competitivo 3v3 en tiempo real construido sobre una base académica colaborativa y llevado posteriormente a través de un proceso estructurado de profesionalización.
El slice actual conecta una interfaz React dirigida por snapshots con Express, Socket.IO y PostgreSQL. Cubre el flujo completo de sala privada para seis jugadores, desde la selección de Duckie y el despliegue oculto en TOP, MID y BOTTOM hasta combate, resultados persistidos y estadísticas de perfil.
Reto y solución
La base académica contenía piezas full stack útiles, pero todavía no comunicaba una experiencia de juego única y fiable. El reto fue conectar identidad autenticada, decisiones pregame ocultas, tres combates concurrentes y resultados duraderos sin convertir al cliente en autoridad de gameplay.
La profesionalización estableció un ciclo de partida autoritativo en servidor, separó las responsabilidades persistentes de REST del gameplay en vivo mediante Socket.IO y proyectó en cada snapshot solo la información autorizada para cada jugador. Después, una capa visual enfocada dio coherencia de farm arena al flujo sin cambiar las reglas.
Flujo de juego
BLUE y RED tienen tres jugadores autenticados cada uno. Cada equipo asigna exactamente un jugador a TOP, MID y BOTTOM; las asignaciones rivales permanecen ocultas hasta que todas las líneas están bloqueadas y el servidor revela los tres duelos independientes. El primer equipo que gana dos líneas vence, y una tercera línea sin resolver queda CANCELLED.
- Autenticarse
- Crear o entrar en una sala privada
- Reunir seis jugadores
- Elegir un Duckie
- Bloquear una línea en secreto
- Revelar tres enfrentamientos
- Resolver el combate realtime
- Persistir resultado y estadísticas de perfil
Autoridad del servidor y arquitectura realtime
React renderiza proyecciones de catálogo, sala, partida y perfil y envía intenciones del jugador. Express atiende identidad, perfil y catálogo duraderos; Socket.IO gestiona el ciclo autenticado de la partida en vivo. El backend mantiene la autoridad de todos los resultados de gameplay.
React + ViteRenderiza snapshots por jugador y envía intenciones.Express RESTAtiende identidad, perfil y catálogo duraderos.Socket.IOCoordina salas autenticadas, pregame y combate en vivo.Módulos de dominioResuelven combate determinista y estado autoritativo.PostgreSQLPersiste identidad, resultados terminados y estadísticas.
- La identidad autenticada del jugador es independiente de los socket IDs.
- Las proyecciones por jugador preservan información rival antes del reveal.
- Tres combates aislados se resuelven en una partida al mejor de tres.
- Salas activas, temporizadores y combate viven en un proceso Node.js.
Mi contribución · Profesionalización
Partiendo de una base académica colaborativa, llevé la implementación actual a través de un proceso estructurado de profesionalización que abarcó:
Backend realtime y dominio
Estabilicé identidad autenticada en Socket.IO, ciclos de sala privada y pregame, proyecciones de información oculta, orquestación de tres líneas y combate determinista autoritativo en servidor.
Datos y persistencia
Integré identidad bcrypt/JWT con PostgreSQL y persistencia transaccional e idempotente para una partida y sus seis participantes, además de estadísticas agregadas autenticadas por perfil.
Frontend e integración de gameplay
Conecté el flujo React desde autenticación y sala hasta selección, reveal, combate, resultado y perfil, usando snapshots del servidor como fuente de verdad.
Calidad y reproducibilidad
Consolidé cobertura de regresión, GitHub Actions, inicialización y migraciones PostgreSQL, servicios Dockerizados, health checks y un smoke test del stack.
Visual y game feel
Definí el sistema visual y la capa de presentación para cuatro Duckies, estrategia oculta, reveal, duelo y resultados manteniendo congeladas las reglas de gameplay y backend.
Decisiones de ingeniería
Autoridad del servidor
Decisión: Los clientes envían intenciones; el backend valida y resuelve resultados.
Trade-off: El backend asume más complejidad y debe seguir disponible durante la partida.
Separación REST y Socket.IO
Decisión: REST sirve datos duraderos; Socket.IO sirve la partida en vivo.
Trade-off: Autenticación y errores deben mantenerse alineados en ambos límites.
Identidad más allá del socket
Decisión: Los sockets se vinculan a perfiles autenticados; no se convierten en jugadores.
Trade-off: Membresía y reconexión necesitan reconciliación explícita.
Proyecciones por jugador
Decisión: Los snapshots contienen solo la información que cada jugador puede conocer.
Trade-off: El código de proyección y los tests de secreto añaden complejidad.
Combate determinista
Decisión: Inputs canónicos y reglas explícitas resuelven respuestas, tiempos, habilidades y muerte súbita.
Trade-off: El feedback visual debe seguir snapshots autoritativos, no predecir efectos.
Estado vivo y resultados duraderos
Decisión: El combate activo vive en un proceso; los resultados terminados persisten en PostgreSQL.
Trade-off: Un reinicio pierde partidas activas y el estado vivo no escala horizontalmente.
Profesionalización visual y game feel
El producto funcional comunicaba inicialmente su mecánica de preguntas con más fuerza que su estructura competitiva. La presentación incorporó cuatro identidades coherentes de Duckie, Character Select inspirado en juegos de lucha, una farm arena ilustrada con tres líneas, reveal autoritativo, HUD centrado en el duelo y una pantalla final clara al mejor de tres.
Los assets describen el mundo. React describe el estado actual. El backend decide la verdad. El feedback visual amplifica eventos autoritativos, pero nunca cambia daño, tiempos, cooldowns, secreto ni resolución.
Calidad y evidencia
El slice terminado está respaldado por comprobaciones automatizadas de backend, frontend, base de datos y entrega, además de un flujo real de seis jugadores verificado manualmente.
- 64 tests backend que cubren autenticación, pregame, secreto, combate, habilidades, resolución de tres líneas, reconexión, persistencia y estadísticas.
- Lint backend, lint frontend y comprobación del build de producción.
- Jobs de GitHub Actions para backend, frontend, integración PostgreSQL y reproducibilidad Docker.
- Inicialización limpia de PostgreSQL y verificación explícita de migraciones históricas.
- Health checks de Docker Compose y smoke test automatizado del stack.
- Cinco capturas de una partida autoritativa verificada con seis jugadores reales autenticados.
- El E2E de navegador no está automatizado; el flujo visual se verificó mediante comprobaciones dirigidas con cliente real y harness.
Resultados y límites
Resultados
- Conecté los componentes académicos en un slice de producto coherente de extremo a extremo.
- Establecí límites explícitos de autoridad y secreto para interacciones multijugador realtime.
- Hice duraderos los resultados terminados y consultables las estadísticas tras reinicios de Node.js.
- Convertí el setup local y las validaciones críticas en flujos reproducibles de Docker y CI.
Límites arquitectónicos
- Las partidas requieren exactamente seis jugadores en salas privadas.
- El estado vivo activo existe en un único proceso Node.js.
- Un reinicio del proceso pierde las partidas activas.
- La capa realtime no soporta escalado horizontal.
- No hay deployment público disponible.
