Construyendo GAME: Un Motor de Gamificación Adaptativa Open Source, Solo, en Un Año
La historia de cómo diseñé GAME, una plataforma de gamificación basada en plugins que pasó de ser una idea inicial a un despliegue real.
La mayoría de los sistemas de gamificación están fuertemente ligados a una única aplicación. Su lógica de recompensas suele estar incrustada directamente en el código de negocio, lo que dificulta reutilizarla, adaptarla y, aún más, compararla entre distintos contextos. Eso siempre me molestó.
Quería algo diferente: un motor modular donde las estrategias de incentivos pudieran tratarse como componentes enchufables en lugar de funcionalidades codificadas directamente.
Durante un año, mientras hacía mi doctorado, construí ese sistema. Se convirtió en GAME: un motor de gamificación adaptativa open source que luego fue desplegado en un experimento real de ciencia ciudadana en Santiago de Chile.
Esta no es una historia de éxito pulida con un arco perfecto. Es la versión más honesta: la de decisiones arquitectónicas discutibles, funcionalidades incompletas, errores en producción y la clásica brecha entre “funciona en mi máquina” y “personas reales lo están usando.”
Si alguna vez has pensado en construir una plataforma desde cero, o si te interesa entender cómo funciona realmente la gamificación adaptativa por dentro, esta es la historia.
El problema que no debería existir
Lo que me llevó a construir GAME fue una frustración simple: los motores de gamificación sí existen, pero la mayoría son cerrados o están diseñados para un único caso de uso.
Muchas plataformas están construidas para contextos específicos, como fitness, aprendizaje de idiomas, engagement de empleados o programas de fidelización. Y en muchos de esos sistemas, la lógica de gamificación está profundamente mezclada con la aplicación. Puntos, insignias, rankings y reglas de recompensa están directamente conectados a la capa de negocio.
Eso funciona hasta que quieres reutilizar la misma estrategia en otro contexto.
En ese punto, normalmente no estás reconfigurando nada. Estás reescribiendo.
En el ámbito académico encontré algo similar. Muchos papers describen frameworks de gamificación adaptativa sofisticados, con diagramas elegantes y conceptos sólidos, pero la implementación es inexistente, incompleta o demasiado prototípica como para reutilizarla. En muchos casos, no puedes instalar el sistema, inspeccionarlo, hacer fork ni construir sobre él.
Quería algo más práctico: un motor de gamificación agnóstico al dominio. Un sistema que no dependiera de si se usa en ciencia ciudadana, e-commerce, educación u otro contexto. Un sistema donde la estrategia, es decir, la lógica que decide quién recibe recompensas, cuándo y cuánto, pudiera intercambiarse como un componente enchufable.
Esa fue la idea central detrás de GAME.
El punto de partida: ¿y si la gamificación funcionara como Blockly?
La idea empezó a tomar forma cuando estaba mirando Blockly, el sistema de programación visual basado en bloques de Google.
Lo interesante no era solo la interfaz visual, sino el principio subyacente: definir lógica como unidades modulares y componibles en lugar de incrustarla dentro de una aplicación.
Eso me hizo pensar: ¿y si las estrategias de gamificación funcionaran igual?
No necesariamente de forma visual, al menos no todavía, pero sí estructuralmente. ¿Y si una estrategia pudiera definirse como un módulo aislado, configurarse de forma independiente, conectarse a un motor y ejecutarse sin afectar el resto del sistema?
En ese modelo, el motor se encargaría de todo lo estructural: persistencia, almacenamiento de puntuaciones, monedas, estado del usuario y exposición vía API. La estrategia solo se centraría en la lógica de recompensa.
Ese fue el origen de GAME, el Goals And Motivation Engine.
El constructor visual de estrategias sigue en el roadmap. Pero la arquitectura fue diseñada desde el inicio pensando en esa dirección. La pregunta detrás de casi todas las decisiones fue la misma:
¿Puede alguien escribir una nueva estrategia de gamificación y conectarla al sistema sin tener que modificar el resto del código?
Arquitectura: por qué elegí un monolito
GAME es un monolito.
Lo digo directamente porque hoy en día la tendencia suele ser ir a microservicios por defecto. Yo no lo hice. Y, honestamente, para este proyecto fue la decisión correcta.
Era una sola persona construyendo una plataforma de investigación bajo presión de tiempo. Necesitaba avanzar rápido, mantener la complejidad bajo control y evitar pasar la mitad del tiempo gestionando comunicación entre servicios, orquestación y trazabilidad distribuida para un sistema que no lo necesitaba.
Un monolito bien estructurado con límites claros es mucho mejor que microservicios prematuros.
La estructura del proyecto es aproximadamente así:
app/
├── api/ # Endpoints HTTP (FastAPI)
├── core/ # Configuración, inyección de dependencias, base de datos
├── engine/ # Estrategias adaptativas (sistema de plugins)
├── repository/ # Capa de persistencia
├── services/ # Lógica de negocio
├── model/ # Modelos de dominio
└── util/ # Utilidades
La parte clave es engine/. Ahí viven las estrategias de gamificación.
Cada estrategia es un módulo de Python que implementa una interfaz definida. El motor las carga dinámicamente. En la práctica, puedes crear un archivo .py, definir la lógica de recompensa y dejar que GAME gestione el resto: persistencia, usuarios, historial y API.
El resto del stack es deliberadamente simple:
- Python 3.10+ con FastAPI
- SQLModel + SQLAlchemy
- PostgreSQL
- Keycloak para OAuth2 / OpenID Connect
- Docker / Docker Compose
- Kubernetes
- Poetry
Nada exótico. Todo orientado a reducir complejidad operativa.
El sistema de plugins: donde está la idea real
El sistema de plugins es lo más importante de GAME.
Si alguien quiere implementar una nueva estrategia, el proceso es simple:
Primero, crea un archivo en engine/.
Luego, la estrategia recibe inputs que dependen del caso de uso: acciones de usuario, contexto, coordenadas, datos externos, etc. GAME no impone un modelo único.
Después, la estrategia calcula una decisión de recompensa: puntos, monedas, ajustes dinámicos, etc.
Finalmente, GAME persiste los resultados, actualiza el estado del usuario y expone todo vía API.
Esa separación es el núcleo del sistema.
GAME no necesita conocer la lógica interna de la estrategia. Solo necesita que cumpla la interfaz.
La estrategia puede ser simple o compleja: desde puntos fijos por acción hasta modelos espaciales o incluso ML en el futuro.
El motor pone la estructura. La estrategia pone la inteligencia.
Eso es lo que significa “adaptativo” aquí.
Por qué elegí Python en lugar de Node
La razón principal es el ecosistema.
Python es mucho más fuerte para todo lo que tenga que ver con algoritmos, análisis de datos o machine learning. Aunque GAME aún no usa ML, la arquitectura está pensada para eso.
Prefiero no tener que dividir el sistema entre un backend en Node y otro en Python en el futuro.
También hay una razón práctica: pienso más rápido en Python.
Cuando trabajas solo, eso importa.
FastAPI encajó muy bien: rápido, limpio, async y con documentación automática. La integración con Pydantic y SQLModel simplificó mucho la coherencia entre API y modelos.
Lo que sabía que faltaba (y aun así lo publiqué)
GAME se lanzó con limitaciones claras:
Sin WebSockets. Todo es request-response. No hay comunicación en tiempo real.
Sin constructor visual. Crear estrategias requiere código. Sigue siendo una barrera.
Sin analítica integrada. Los datos están, pero el análisis es externo.
Aun así, decidí lanzar.
Un sistema útil con limitaciones es mejor que uno perfecto que no existe.
De localhost al mundo real
GAME se diseñó como motor general, pero terminó usándose en un experimento de ciencia ciudadana en Santiago, en la plataforma GREENCROWD.
Los usuarios reportaban microbasurales, y GAME gestionaba la capa de incentivos.
Implementé una estrategia adaptativa basada en proximidad: zonas con menos cobertura daban más recompensas, incentivando exploración.
El paso a producción implicó:
- despliegue con Docker
- integración con app móvil
- estrategia espacial
- monitoreo en tiempo real
Aquí Sentry fue clave.
Los errores reales aparecieron solo cuando los usuarios reales empezaron a usar el sistema.
Qué haría distinto
Definiría mejor las interfaces del plugin desde el inicio.
Y modelaría los datos con más anticipación.
Pero no cambiaría las decisiones principales.
Lo que la gente no ve
GAME tiene casi 100% de cobertura de tests.
Para un proyecto solo, es poco común.
Pero era necesario: si el sistema sustenta experimentos, no puedes confiar solo en intuición.
Qué viene ahora
GAME es open source:
https://github.com/fvergaracl/GAME
Aún falta mucho: tiempo real, visual builder, analítica, ML.
Pero la idea ya fue validada donde importa: en uso real.
Construí GAME porque creo que la gamificación debería ser abierta, modular y adaptable.
Y después de todo este proceso, sigo pensando lo mismo. Si estás interesado en gamificación adaptativa, o si quieres construir algo similar, te animo a revisar el código, hacer fork o contribuir.