Dominoes in Mauritius is not exactly a quiet game.

There is the sound of tiles hitting the table.

Partners trying to understand each other's moves.

Someone celebrating a good play.

Someone else convinced you played the wrong domino.

People watching from the side.

And, eventually, somebody keeping track of the score.

So when I decided to build Domino Lakaz, I wasn't particularly interested in making a webpage where you could drag dominoes around.

I wanted to recreate the game around the game.

That turned out to be much harder.

It Started With the Rules

The first challenge was surprisingly simple:

What exactly are the rules?

A computer cannot work with:

"We normally play it like this."

Every rule has to become explicit.

Domino Lakaz uses the familiar double-six set and supports four-player games organised into two teams:

Players 1 & 3 vs Players 2 & 4

The game handles cumulative scoring toward 101 points, determines who starts each round, rotates the starter appropriately and deals with special situations such as reshuffling when a player receives five or more doubles.

Even the opening matters.

The 1|1 has a special role in the game and needed to be handled correctly, including unusual edge cases where it might end up aside rather than in a player's hand.

These sound like tiny details.

They are not.

If you digitise a familiar game and get one traditional rule wrong, players notice immediately.

The Server Is the Dealer and Referee

Once the rules existed in code, another problem appeared.

In an online multiplayer game, whose computer decides what happened?

I did not want four browsers maintaining four potentially different versions of the game.

So Domino Lakaz uses a server-authoritative architecture built with Cloudflare Workers and Durable Objects.

The server is the source of truth.

It knows:

  • whose turn it is
  • which tiles have been played
  • what remains in each hand
  • the current ends of the domino chain
  • the team scores
  • whether a move is legal
  • when a round has ended
  • when the game has been won

The browser asks to make a move.

The server decides whether that move is valid.

That distinction is important for multiplayer games because the client should not be trusted to decide the rules.

It also helps prevent something even more important at a dominoes table:

cheating.

Your Hand Is Your Hand

A multiplayer server needs to know the complete game state.

A player does not.

If I am playing, my browser should receive the information necessary to show my hand, not everybody else's.

That principle influenced how the game state is sent to clients.

The server may know every tile.

Each player sees only what they are supposed to see.

That becomes even more important once spectators enter the room.

The Table Needed People Around It

One thing I did not want Domino Lakaz to become was four isolated players silently clicking tiles.

Part of dominoes is social.

So I added spectator mode.

Someone can enter a room and watch a game without becoming a player.

They can follow the action and use emotes, but hidden hands remain hidden.

If a seat becomes available, a spectator can also claim it and join the game.

That created an interesting design problem.

Spectators should feel present without becoming disruptive.

So spectator emotes are throttled to prevent someone from filling the screen with reactions every second.

It is a tiny feature, but it contributes to what I actually wanted to reproduce:

people gathering around a game rather than merely observing a board.

The Emotes Were Not an Afterthought

Competitive games need reactions.

Domino Lakaz includes a responsive emote wheel so players can react during a match.

That might seem far less important than WebSockets or game-state validation.

Technically, it is.

Socially, I am not sure it is.

A perfectly functioning dominoes game where nobody can react to anything would feel strangely lifeless.

The rules make the game work.

The reactions help make it feel like dominoes.

Then Came the Table

The visual design followed the same philosophy.

I wanted the board to feel immediately recognisable as a dominoes table rather than a generic web-game interface.

So I used a green felt table and arranged played tiles in a snake-like pattern as the chain grows.

The pips use different colours — including red, blue, green, purple, orange and teal — to make the tiles easier to read quickly.

Scores remain visible.

Team names can be customised.

Game history is tracked.

The layout adapts across screen sizes.

None of those features changes the rules.

But games are experienced through their interface, and the interface needed some personality.

What If Nobody Else Is Online?

Multiplayer was the main goal, but it creates an obvious problem.

Sometimes you want to play and three other people are not available.

So I added AI players.

And instead of calling them:

Bot 1

Bot 2

Bot 3

I gave them identities:

Sunderi

Parsuramen

Claude

The AI evaluates possible moves using Monte Carlo-style heuristics and strategic information available during the game.

The objective was not to build a perfect dominoes AI.

It was to create opponents capable of making plausible decisions so that a solo game still feels competitive.

This also made development much easier.

I no longer needed four humans every time I wanted to test a complete match.

The AI could play thousands of games.

Thousands of Games Nobody Had to Play

This became one of the most useful parts of the project.

A multiplayer game can appear to work perfectly during normal testing while still containing rare rule failures.

Maybe a specific distribution of doubles breaks the deal.

Maybe a particular starter sequence creates an invalid state.

Maybe the game reaches a blocked position that was not anticipated.

These bugs are difficult to find manually because a human tester has to accidentally create exactly the right situation.

Automated simulations do not get bored.

I built tests capable of running through large numbers of games and checking that the engine remained valid.

That allowed me to test not just individual functions but the behaviour of the game over thousands of simulated situations.

For a rules-based game engine, that gave me much more confidence than simply playing a few successful matches myself.

Real-Time Play Changed the Architecture

Online dominoes also has a basic requirement:

when someone plays a tile, everyone else should see it immediately.

The multiplayer system therefore uses WebSockets for live communication.

A player makes a move.

The server validates it.

The authoritative game state changes.

The connected players receive the update.

The table changes.

No refresh button should be required.

That sounds obvious because we are accustomed to real-time applications.

Building it exposes a lot of less obvious problems.

What happens when someone loses connection?

What if they refresh the browser?

What if they reconnect during a round?

What if two actions arrive almost simultaneously?

Domino Lakaz therefore includes reconnection behaviour so a temporary network interruption does not automatically destroy the game.

A player can return to the room and recover their place.

Playing With Friends Without Accounts

I also wanted joining a game to remain simple.

Instead of turning Domino Lakaz into another service requiring profiles, passwords and onboarding screens, multiplayer games revolve around room codes.

Create a room.

Share the code.

Join the table.

Players are assigned into opposing partnerships and the game can begin.

For this kind of project, reducing friction was more useful than building an elaborate account system.

Sometimes the best authentication screen is no authentication screen at all.

The Hardest Bugs Were Usually the Weird Ones

Normal gameplay is rarely where a game engine breaks.

The strange situations are more dangerous.

A special tile appears somewhere unexpected.

A player disconnects at an inconvenient moment.

A round ends differently from the usual case.

A state that "should never happen" happens.

These edge cases taught me something I have seen repeatedly in other software projects:

The main logic gets the application working. Edge cases determine whether it stays working.

That was especially true for Domino Lakaz because players already know how dominoes should behave.

The software cannot simply improvise when it encounters something unusual.

Why Build a Mauritian Dominoes Game?

There are already plenty of dominoes games online.

That was never really the point.

I wanted to build our version.

Small games and traditions are interesting software projects because they force you to translate informal cultural knowledge into precise computational rules.

Things everybody at the table understands instinctively suddenly need definitions.

Who starts?

Who partners with whom?

When do we reshuffle?

How does scoring work?

What happens after the round?

What information can each person see?

Those questions turn something familiar into a surprisingly interesting engineering problem.

And once those rules are encoded, the game is no longer limited by geography.

Someone in Mauritius can play with someone overseas using the same rules they would use around a table at home.

That is probably my favourite part of the project.

Domino Lakaz Today

The game now supports both multiplayer and solo play.

Friends can create rooms and play in real time.

AI opponents can fill the table.

Spectators can watch.

Players can disconnect and return.

Teams, scores and rounds are handled by the server.

Hidden information remains hidden.

And the game engine has been exercised through extensive automated simulations.

There are plenty of directions it could still take.

Tournaments would be interesting.

Leaderboards could create longer-term competition.

AI opponents could become more sophisticated.

But those are additions to something that already works.

Domino Lakaz began as an attempt to put dominoes in a browser.

It ended up teaching me about real-time networking, authoritative game servers, state management, AI opponents, automated simulation and the difficulty of converting unwritten rules into code.

But underneath all of that technology, the objective remained surprisingly simple:

Four seats. Two teams. Twenty-seven tiles. First to 101.

And hopefully, at least a little of the atmosphere of a Mauritian dominoes table made it through the screen.