El blog · Trabajos reales
Cómo se programa un juego de dados donde nadie puede hacer trampas (ni nosotros)
12 de agosto de 2026 · 3 min de lectura · Por RB, que dirige una agencia que automatiza procesos de negocio con IA.
La Capitana es un juego de dados para móvil estilo Generala, con temática de capitana pirata, free-to-play y sin apuestas ni dinero real. Y tiene una regla de oro que lo condiciona todo: los valores de los dados salen de la lógica del juego. La animación solo los enseña. Ni los jugadores… ni nosotros podemos tocar el resultado.
El problema
En cualquier juego con azar hay una pregunta incómoda: ¿quién decide el resultado? Si lo decide lo que ves en pantalla —la animación, el efecto, el «momento»—, entonces el resultado es manipulable: por el jugador con trampas, o por el propio juego para engancharte. Y cuando los jugadores lo sospechan, la confianza muere.
La Capitana se diseñó al revés: primero la integridad del azar, después lo bonito.
Qué se diseñó
- Azar autoritativo: los dados salen de un generador aleatorio puro, con semilla, dentro del dominio del juego. Es determinista y auditable: con la misma semilla, mismo resultado.
- Los visuales no deciden nada: la animación de los dados es solo una representación de un resultado que ya existe. Separación total entre «qué sale» y «cómo se ve».
- Skins solo cosméticas: seis barajas (pirata clásica, oro del capitán, kraken…) que cambian el aspecto, nunca las probabilidades. Cero pay-to-win: pagar solo te pone más guapo.
- Economía virtual completa: monedas, gemas, cofres con probabilidades publicadas, compras integradas y anuncios recompensados.
- Añadir contenido sin romper nada: una baraja nueva son assets más una entrada en el catálogo. El dominio no se toca.
Cómo está montado
- Flutter + Flame: un solo código para el juego y el motor de juego.
- Clean Architecture estricta: el dominio es Dart puro, sin dependencias de Flutter. Seis funcionalidades separadas: juego, economía, héroes, skins, tienda y progreso.
- BLoC para el estado: la interfaz reacciona a estados, no a variables sueltas.
- Testeable por diseño: como el azar vive en el dominio puro, se puede probar sin pantallas ni animaciones.
El resultado (honesto)
El juego está completo y funciona. No está publicado en las tiendas: es un proyecto de I+D y portfolio, hecho porque queríamos hacerlo bien —«un poco del juego», como pedimos al empezar—.
Y precisamente por eso es valioso: demuestra cómo se construye azar con integridad, algo que la mayoría de juegos móviles no pueden decir.
La lección
En software con azar, la confianza es una decisión de arquitectura, no un eslogan. Si el resultado lo decide lo que se ve en pantalla, alguien acabará manipulándolo. Sepáralo, hazlo auditable, y podrás mirar a tus jugadores a la cara.
¿Haces un juego con azar? Cinco señales de que tu arquitectura flojea
- El resultado «sale» en la animación, no antes.
- No puedes reproducir una partida a partir de una semilla.
- Añadir un skin nuevo te obliga a tocar la lógica.
- Hay objetos de pago que mejoran las probabilidades.
- Tus jugadores ya sospechan que «el juego decide cuándo pierdes».
Si marcas tres o más, tu azar es decoración. Y la decoración se manipula.
¿Te suena? En la portada tienes 3 casos completos gratis del libro.
Preguntas que me harías en persona
¿Por qué separar los dados de la animación?
Porque si la animación decide el resultado, el resultado es manipulable. Separándolos, el azar vive en la lógica —auditable y con semilla— y la animación solo lo representa.
¿Qué significa que el dominio sea Dart puro?
Que las reglas del juego no dependen de Flutter ni de pantallas: son código limpio que se puede probar, auditar y reutilizar sin arrancar la app.
¿Cómo evitas el pay-to-win?
Las skins son solo cosméticas: cambian el aspecto de los dados, nunca las probabilidades. Pagar te pone más guapo, no te hace ganar.
¿Va a salir en Play Store y App Store?
De momento no hay fecha: es un proyecto de I+D y portfolio, completo y funcional. Si se publica, lo contaré aquí.