El Impostor es un juego de deducción social en el que un grupo de jugadores debe descubrir quién es el impostor entre ellos. Esta versión es la digitalización de un juego popularizado en Argentina, principalmente en programas de streaming.
Mi motivación para crear este proyecto fue crear algo que me permitiera exigir al máximo el servidor con los recursos otorgados.
Un juego con muchas conexiones en tiempo real, con una base de datos y una IA, me pareció un desafío interesante para un servidor con pocos recursos.
Aproveché para innovar en el stack tecnológico con tecnologías que nunca había usado, o había usado poco o nunca había llevado a un proyecto en producción. Entre estas:
- ⚡ Bun: Elegí Bun como runtime nativo. Fue un salto al vacío para aprender algo nuevo y aprovechar su performance en WebSockets.
- 🔥 Hono: Usé Hono para el backend para agilizar el desarrollo para la api con Bun.
- 🧠 IA Dinámica: Integré Google Gemini para que el juego respire. Las palabras no son estáticas; la IA genera categorías y términos semánticamente cercanos para que cada partida sea un desafío nuevo.
- 📦 Turborepo: Usé Turborepo para gestionar el monorepo. Uno de los primeros desafios con los que me encontre fue la utilizacion de datos compartidos entre el frontend y el backend, para lo cual utilice Zod para validar los datos que se envian entre el frontend y el backend.
Más allá de los clásicos, introduje una mecánica para cambiar un poco de aire:
- 🕵️ Tradicional: 1 Impostor vs Agentes. El clásico juego de deducción.
- 🔍 Palabras Cercanas: Un infiltrado con una palabra similar pero distinta. Genera confusión y tensión.
- ⚡ Modo Caos (Original): Dos jugadores están vinculados (comparten la misma palabra) mientras el resto tienen palabras únicas relacionadas. Los vinculados deben encontrarse en el silencio, y los dispersos deben exponer a la pareja.
Este proyecto está desplegado 100% en CubePath utilizando un servidor gp.micro con Dokploy como orquestador. La arquitectura está diseñada para maximizar el uso de recursos limitados, configurando subdominios personalizados a través de Cloudflare para cada servicio bajo el dominio raíz brunoarias.dev.
| Servicio | Límite RAM | Build Type | Dominio / URL |
|---|---|---|---|
| Frontend (Web) | 256 MB |
Dockerfile |
impostor.brunoarias.dev |
| API Backend | 256 MB |
Dockerfile |
api.brunoarias.dev |
| Game Server | 512 MB |
Dockerfile |
ws.brunoarias.dev |
| PostgreSQL | 1 GB |
Managed |
Persistencia de Datos |
El sistema es un Monorepo orquestado para la eficiencia máxima:
- API Backend (
apps/api): Hono + PostgreSQL. Gestión de perfiles y orquestación de IA. - Game Server (
apps/game-server): Lógica en tiempo real usando Bun Nativo (WS) para una latencia casi nula. - Frontend Web (
apps/web): React 19 + Zustand en una interfaz "War Room" oscura, premium y responsiva. - Shared Core (
packages/shared): Contratos de Zod compartidos. El frontend y el backend hablan el mismo idioma sin errores.
- Instalar el motor:
bun install
- Encender la maquinaria:
Dato: Usa
bun run dev
bun run dev:hostpara abrir una terminal dividida en Kitty.
Tip
Cada aplicación dentro del monorepo tiene su propio archivo .env. Puedes guiarte por los archivos .env.example en cada carpeta para la configuración necesaria.
| Variable | Descripción |
|---|---|
DATABASE_URL |
URL de conexión a PostgreSQL. |
ALLOWED_ORIGINS |
Orígenes permitidos para CORS (separados por coma). |
INTERNAL_API_KEY |
Clave secreta compartida con el game-server para comunicación S2S. |
GEMINI_API_KEY |
API Key de Google Gemini AI. |
VITE_WS_URL |
URL interna para descubrimiento del servidor de juegos. |
LOG_LEVEL |
Nivel de verbosidad de logs (info, debug, error). |
| Variable | Descripción |
|---|---|
VITE_API_URL |
URL base de la API REST. |
VITE_WS_URL |
URL del servidor de WebSockets (wss://...). |
| Variable | Descripción |
|---|---|
INTERNAL_API_URL |
URL de la API para callbacks internos y lógica de juego. |
INTERNAL_API_KEY |
Debe coincidir con la clave configurada en la API. |
VITE_API_URL |
URL base de la API (usada en algunos contextos de cliente). |
LOG_LEVEL |
Nivel de logs del servidor de juegos. |
Este proyecto se construyó siguiendo un proceso riguroso de planificación y ejecución:
- Diseño de Juego: Todo el funcionamiento se planeó paso a paso, con ideas plasmadas en Game Design (Core, Flujo, Scoring).
- Prototipado UX/UI: Con las reglas claras, pasé al diseño de prototipos visuales para establecer la guía estética antes de tocar una línea de código.
- Arquitectura Técnica: Diseñé la comunicación entre el frontend y el backend, detallada en Technical Docs.
- Implementación: Con todo planeado, configuré las skills y ejecuté los planes de implementación: FRONTEND y BACKEND.
Note
La documentación en docs/ se enfoca en proporcionar la estructura necesaria para el desarrollo asistido por IA. He omitido borradores iniciales y notas desordenadas de la etapa de ideación que no aportaban valor directo al código final.
- Gemini CLI & Antigravity (Codificación asistida por IA).
- SVGViewer (Optimización de vectores).
- Iconify (Set de iconos para la interfaz).
- Inkscape (Diseño de assets vectoriales).
- Shots.so (Mockups y presentación visual).
Desarrollado con ❤️ para la Hackatón CubePath 2026.