Skulls Ludo
A multiplayer board game on Google Play: classic, rush and team up modes, in-match chat and credits earned from daily play, with the launch site that carries its token and NFT programme.

What they came with
A multiplayer Ludo game was heading for Google Play at the same time as a token and NFT programme that did not yet exist on chain. Players needed something to earn and spend from the first install, and anyone reading about the token needed the modes, the rarity tiers and the tokenomics set out in one place rather than gathered from scattered posts. Neither side could wait for the other, and a game where a dropped signal costs you the match does not survive its first week.
What the build had to do
Authoritative turn state
Ludo looks simple until four clients have to agree on one dice roll, a capture and who is on the clock. The turn, the timer and the board belong to the server, or two players see two different games.
Rooms, seats and dropouts
A match is composed before it starts: two or four seats chosen on a pre-match screen, with private rooms behind the play-with-friends mode. The room has to hold together between the first player joining and the board appearing, and a four-seat game has to keep going when somebody closes the app mid-turn.
Chat inside an Everyone-rated game
In-match chat and an emoji tray run beside the game state as a second live channel. The store rates the app Everyone with the interaction flag Google applies to player-to-player messaging, which brings a moderation and reporting obligation the board itself does not have.
Two currencies, one of them bought
The HUD carries XP for level and gems for spend, with purchases behind the gem count. Once a balance can be bought with real money it has to be held on the server and reconciled against store billing rather than trusted from the handset.
A token and collection specified in full
The whitepaper sets out the token, its supply, staking and governance, and ten thousand skulls across six rarity tiers, each tier carrying its own in-game effect. Writing an economy down to that level is what decides whether it can ever be implemented.
A launch site the length of a prospectus
Twenty thousand pixels of one page: ecosystem, the modes, the token board, tokenomics, the rarity ladder, a roadmap and a FAQ, on in-page anchors with scroll-driven motion. It is a theme-only WordPress build with no plugins behind it, so every section is code rather than a page builder.
Technical detail
Server holds the board
The authoritative board state lives on the server; clients send intents (roll, move a token) and render what comes back, so a client cannot claim a move the rules do not permit. One rules engine serves all three modes, which differ only in seat count and win condition.
Reconnect to the same seat
A seat is bound to the match, not to a socket, so a phone that loses signal rejoins to current state rather than starting a new session. The turn timer keeps running while it is away, so a disconnect costs time and not the game.
An economy with a ledger behind it
XP and gems are written as server-side transactions rather than a balance held on the device, so a balance can be recomputed and a lost install does not lose progress. The designed token maps onto the same ledger later without the game economy being rewritten.
Site content, not hard-coded sections
Tokenomics tables, rarity tiers and roadmap entries are editable fields in WordPress rather than markup, so the launch story changes without a deploy. GSAP effects attach to sections by class, so adding a section does not mean new JavaScript.
The stack
Mobile
Game services
Launch site
- Sector
- Casual multiplayer games
- Shipped
- Android, Google Play
- Shape
- Real-time, two or four seats
- Economy
- XP and gems, token designed




Something like this to build?
Tell us what runs today and where it hurts. An engineer reads it and replies.


