In a card game, dealing a nice hand is the easy part. The hard part is making every player see the same game and understand why one hand wins. Daker Online taught us that the hard way, because every card has two values.
Daker began as a physical deck created by its author, and at OverFuture we built the version for mobile phones. This article covers what mobile card game development involved for us: the rules, the multiplayer tables, the bots and the browser demo.
What the game is and how it plays is on the Daker Online product page, which includes a test bench for the rules engine. The project summary is on its project page (in Spanish).
A physical deck that had to work on a phone.
The Daker deck has 28 cards, and 27 of them are used in play. Each card carries two of the six values of poker dice (A, K, Q, J, Red and Black), and only one of them counts in each hand. There are 21 different pairs of values and six double cards.
The first mobile version arrived in January 2024, as we explained when we announced it (in Spanish). That August it gained online multiplayer, with a rebuilt interface and a leaderboard. Roughly a year after launch came the five-card mode with a discard, an idea that had been there from the start. Daker offers no real-money betting and no cash prizes.
Cards as data, not as pictures.
Each card needs an identifier, its values and a state of its own. The artwork is only how it looks. That separation lets you test thousands of hands without opening the scene. In Daker it was essential, because the same card can be read two ways.
The core of a game like this has four parts. One single game state, the valid actions for the current turn, a deterministic hand evaluator and the visual events that follow from the result.
Rules, turns and exceptions are modelled before the table is animated.
An engine that walks 105 hands.
In Daker Original each player holds three cards and there are three shared cards on the table. A hand is made from your three cards and two shared ones, choosing one value from each card. With six cards in view, that gives 1,736 combinations before duplicates are removed.
Without duplicates, between 24 and 222 possible hands remain, depending on the cards. We measured it with a simulation of 20,000 hands that uses the game’s own algorithm. The engine walks down a ranked table of 105 hands and keeps the first one that matches.
The simulation also answered a design question. In 63% of hands, being able to choose each card’s value improves the result compared with using only the top value. In none of those hands does it make the result worse.
Settling each hand exactly once.
The evaluator receives the cards and always returns the same result for the same combination. Keeping it apart from the animations stops a reconnection, a double tap or a visual effect from settling a hand twice.
Splitting the pot needs the same care. Side pots appear when someone goes all in without covering the others’ bets. They have their own calculator, which we checked against public calculators, and the code keeps a test case so that work is never lost.
A table another player can take over.
Multiplayer runs on Photon PUN 2. At each table, one player acts as the Master Client and runs the game. That player deals, plays for the bots and closes the hand, and everyone else receives each change through remote procedure calls (RPC).
The app can block an impossible action to give instant feedback, but the player running the game must check it again. That way a slow connection, or a screen still showing an earlier turn, cannot change the real state of the table.
The risk of this set-up is obvious. If the Master Client loses connection, the table has nobody to run it. That is why we built reconnection in from the start, not at the end.
When the Master Client drops, the next player recovers the last table state and replays the last move with fresh timers. A player who disconnects has 25 seconds to return to the room, and the game retries every second. If a table stops sending signals, a watchdog warns the player and removes them ten seconds later.
A returning player does not need to replay every missed event. They need one consistent snapshot of the turn: the visible cards, the pot, the active player and what they can still do.
Bots that give up their seat.
An empty table does not invite anyone to play. If players are missing, up to five bots sit down, and a person who arrives can take a bot’s seat. There are no bots in duels with friends.
The bots use the same table of hands as the app, plus an element of chance, so they are not predictable. Anyone who would rather watch has a spectator mode.
Explaining the rule through the result.
Highlighting the winning combination and explaining the tie-break makes the result feel fair. In a game with double-value cards, that short summary stops a new rule from looking like a bug.
The same goes for everything around the table. Daily chips, challenges and the shop only work if the player understands where each reward comes from.
The leaderboard follows the same idea. It makes sense when players can always see which period it covers, where they stand and what is being measured.
A browser demo at half the size.
In October 2026 we released a playable demo at dakeronline.com/playdemo, built with WebGL. The challenge was size, because the first compressed build took up 115.5 MB.
We brought it down to 85.4 MB on desktop and 54.5 MB on mobile, measuring each change as we went. There are two builds, one with ASTC textures for browsers that support them and one with DXT for the rest.
Demo mode is switched on with a single flag and makes no requests to the production servers. We tested it in Chrome, Edge and Firefox.
The technology underneath.
Daker Online is built with Unity 6 and C#, with Photon PUN 2 for the tables, a Laravel server for accounts and Firebase for notifications. The details of each part are on the product page.
If you are commissioning a mobile card game, ask for a rules engine that can be tested without the interface, using thousands of simulated hands. Then ask what happens if the player running the game loses connection. Those two questions save the most trouble.
What we learned.
A new rule earns players’ trust through an engine that always gives the same result for the same hand, and a screen that explains why. Tests prove the first; design delivers the second.
We also learned that multiplayer has to be designed around failure. On a phone, losing connection is part of normal use, and the game has to carry on.
If you need a card, board or multiplayer game for mobile, we build it to order from Zaragoza. See our Unity mobile game development service.
