En un juego de cartas, la parte difícil no es repartir una mano bonita. Es conseguir que todos vean la misma partida y entiendan por qué una jugada gana. Con Daker Online lo aprendimos a fondo, porque cada carta tiene dos valores.
Daker nació como una baraja física de su creador, y en OverFuture desarrollamos su versión para el móvil. Aquí contamos qué supuso desarrollar un juego de cartas móvil, con las reglas, el multijugador, los bots y la demo para navegador.
Qué es el juego lo cuenta la landing de Daker Online, con un banco de pruebas del motor que puedes usar. El resumen del proyecto está en su ficha.
Una baraja física que tenía que funcionar en el móvil.
La baraja de Daker tiene 28 cartas y se juega con 27. Cada carta lleva dos de los seis valores del póker de dados (A, K, Q, J, Rojo y Negro), y en cada jugada solo se usa uno. Hay 21 parejas de valores distintas y seis cartas dobles.
La primera versión para móvil llegó en enero de 2024, como contamos en su presentación. En agosto de ese año estrenó el multijugador online, con la interfaz rehecha desde cero y una clasificación. Aproximadamente un año después del lanzamiento llegó el modo 5 con descarte, una idea que estaba ahí desde el principio. Daker no ofrece apuestas con dinero real ni premios en dinero.
Modelar las cartas como datos.
Cada carta necesita un identificador, sus valores y un estado propio. La ilustración es solo su representación. Esta separación permite probar miles de manos sin abrir la escena, y en Daker era imprescindible, porque una misma carta admite dos lecturas.
El núcleo de un juego así tiene cuatro piezas. Un estado único de la partida, las acciones válidas para el turno actual, un evaluador determinista de jugadas y los eventos visuales que salen del resultado. Las reglas, los turnos y las excepciones se modelan antes de animar la mesa.
Un motor que recorre 105 jugadas.
En Daker Original cada jugador tiene tres cartas y hay tres comunes en la mesa. La jugada se forma con las tres propias y dos comunes, eligiendo un valor de cada carta. Con las seis cartas a la vista salen 1.736 combinaciones antes de quitar las repetidas.
Sin repetidas quedan entre 24 y 222 jugadas posibles, según la mano. Lo medimos con una simulación de 20.000 manos que usa el mismo algoritmo del juego. El motor recorre de arriba abajo la tabla de 105 jugadas ordenadas y se queda con la primera que coincide.
La simulación también respondió una pregunta de diseño. En el 63 % de las manos, poder elegir el valor de cada carta sube la jugada respecto a usar solo el valor superior. En ninguna de esas manos la empeora.
Resolver la mano una sola vez.
El evaluador recibe las cartas y devuelve siempre el mismo resultado para la misma combinación. Mantenerlo separado de las animaciones evita que una reconexión, un toque repetido o un efecto visual resuelvan la mano dos veces.
El reparto del bote pide el mismo cuidado. Los botes secundarios aparecen cuando alguien va con todo y no cubre la apuesta de los demás. Tienen su propia calculadora, que contrastamos con calculadoras públicas, y el código guarda un caso de prueba para no perder ese trabajo.
Una mesa que otro jugador puede heredar.
El multijugador usa Photon PUN 2. En cada mesa, un jugador hace de Master Client y conduce la partida. Reparte, juega por los bots y cierra la mano, y el resto recibe cada cambio por mensajes remotos (RPC).
La app puede bloquear una acción imposible para dar una respuesta inmediata, pero quien conduce la partida tiene que comprobarla otra vez. Así una conexión lenta o una pantalla que conserva un turno anterior no altera el estado real de la mesa.
El riesgo de ese reparto es evidente. Si el Master Client pierde la conexión, la mesa se queda sin quien la dirija. Por eso preparamos la reconexión desde el principio, y no al final.
Cuando cae el Master Client, el siguiente recupera la última mesa y repite la última jugada con tiempos nuevos. Quien se desconecta tiene 25 segundos para volver a su sala, y el juego lo reintenta cada segundo. Si una mesa deja de dar señales, un vigilante avisa al jugador y lo saca diez segundos después.
Quien vuelve no necesita reproducir cada evento perdido. Necesita una fotografía coherente del turno, con las cartas visibles, el bote, el jugador activo y lo que todavía puede hacer.
Bots que ceden la silla.
Una mesa vacía no invita a jugar. Si faltan jugadores, se sientan hasta cinco bots, y una persona que llega puede ocupar la silla de un bot. En los duelos con amigos no hay bots.
Juegan con la misma tabla de jugadas que el cliente y una parte de azar, para que no sean previsibles. Quien prefiere mirar tiene un modo espectador.
Explicar la regla con el resultado.
Resaltar la combinación ganadora y explicar el desempate hace que el resultado se sienta justo. En una modalidad con cartas de doble valor, ese pequeño resumen evita que una regla nueva parezca un fallo del juego.
Lo mismo vale para todo lo que rodea la mesa. Las fichas diarias, los retos y la tienda solo funcionan si el jugador entiende de dónde sale cada cosa.
La clasificación sigue la misma idea. Se entiende cuando el jugador ve en todo momento de qué periodo es, en qué posición está y qué se mide.
Una demo para navegador que pesa la mitad.
En octubre de 2026 publicamos una demo jugable en dakeronline.com/playdemo, hecha con WebGL. El reto era el peso, porque la primera build comprimida ocupaba 115,5 MB.
La dejamos en 85,4 MB para escritorio y 54,5 MB para móvil. Lo bajamos paso a paso, midiendo cada cambio. Hay dos builds, una con texturas ASTC para los navegadores que las admiten y otra con DXT para el resto.
La demo se activa con un solo interruptor y no hace ninguna petición a los servidores de producción. La probamos en Chrome, Edge y Firefox.
La tecnología que hay debajo.
Daker Online está hecho en Unity 6 y C#, con Photon PUN 2 para las mesas, un servidor Laravel para las cuentas y Firebase para las notificaciones. Los detalles de cada pieza están en la landing.
Si vas a encargar el desarrollo de un juego de cartas móvil, pide que el motor de reglas se pueda probar sin la interfaz, con miles de manos simuladas. Y pregunta qué pasa si quien conduce la partida pierde la conexión. Son las dos preguntas que más problemas ahorran.
Lo que aprendimos.
Una regla nueva se gana la confianza del jugador con un motor que da siempre el mismo resultado para la misma mano y una pantalla que explica por qué. Lo primero se demuestra con pruebas y lo segundo, con diseño.
También aprendimos que el multijugador se diseña pensando en el fallo. En el móvil, perder la conexión es parte del uso normal, y la partida tiene que seguir.
Si necesitas un juego de cartas, de mesa o multijugador para móvil, lo desarrollamos a medida desde Zaragoza, en nuestro servicio de desarrollo de videojuegos.
