Back to articles list
- 8 minutes read

The Secrets of Dominoes, or A Domino Game Data Model

Board games like dominoes are still very popular. Let’s take a look at dominoes from a data modeling point of view.

The game of dominoes has been around for hundreds of years, and it’s played all over the world. As you might expect, this means a lot of variations in play! In this article, we’re going to examine a data model that could support the most common variants – draw and block. The basics of these two variants are almost the same; there’s just slight differences in rules. Dominoes can be played by two or more players, so our data model will support multiple players.

Let’s start with some basics of domino gameplay, then we will move on to the data model.

What Do We Need to Know About Dominoes?

  • A dominoes set contains 28 playing pieces, which are called ‘bones’ or ‘tiles’. They are rectangular, with a line in the center that divides each tile into two square ends (or faces).
  • Each end has a number of spots ranging from 0 to 6. These spots are called ‘pips’.
  • Tiles with the same values on both ends are called ‘doubles’, e.g. a double-six has six pips on each end.
  • The collection of dominoes on the playing surface is called the line of play. The ends of the line of play are called branch corners. Branch corners are where players can play new tiles.

Starting a Game

  • All tiles are placed face-down on a table.
  • If there are 2-3 players, each player draws 7 tiles. If there are 4-5 players, each player draws 5 tiles. The remaining tiles are left in a pile called the ‘boneyard’.
  • The player with the highest double gets the first move. Play usually moves clockwise.
  • To play a domino, a player lays a tile next to a tile that’s already been laid on the table. The ends of the tiles must match, i.e. a two-pip end can only be placed next to another two-pip end. (Note: Some game variants have different rules regarding matching.)

Game Rules

  • The first player lays the highest double face up on the table.
  • The next player must play a domino that matches the previously laid domino.
  • A player who cannot match either end of the formation must “knock” or “pass”. In a block game, this simply means that play passes to the next player. In a draw game, players must draw tiles from the boneyard until they find a playable tile. If the boneyard is empty, play simply passes to the next person. Some variants of the draw game limit the number of tiles a player must draw, i.e. up to 3 tiles. If the player draws the specified number of tiles and doesn’t get a match, play moves to the next person.
  • The line of play has two or more branches (playable ends) at any time. Players can play on any branch that has the same number of pips as one of their tiles. Doubles are placed at a right angle to all other tiles. (Note: Some variants have different rules about the line of play.)

Winning a Dominoes Game

  • In a draw game, the first player to play all their tiles wins. Play may (or may not) continue until both ends of the line of play are blocked and no more dominoes are left in the boneyard.
  • In a block game, the player with the fewest tiles wins when the ends are blocked and no one has any playable tiles left.

Scoring

In a draw game, the sum of the pips on the losers’ remaining dominoes is the winner’s score. In a block game, the person with the lowest sum of leftover pips wins; this player subtracts their sum from their opponent’s sum; the difference is the winner’s score. Note: In some games, players must reach a minimum score to win.

The Dominoes Data Model

The dominoes data model consists of two subject areas:

  • “Entities: players, dominoes and games” and
  • “Game progress and tracking”

We’ll discuss each subject area in the order it is listed.




Subject Area 1: Players, Dominoes, and Games

This subject area contains what we can call the main entities of a dominoes game: the players, the domino tiles, and the game.

Subject Area 1: Players, Dominoes, and Games

The “player” table holds profile details for all individual players. The columns in this table are:

  • id –A unique ID for each player.
  • player_name – The player’s first and last name.

The following columns in this table store each player’s game statistics:

  • num_block_game_played – The number of block games that player has played.
  • num_draw_game_played – The number of draw games that player has played.
  • num_block_game_win – The number of block games won by the player.
  • num_draw_game_win – The number of draw games won by the player.
  • highest_block_score – The player’s highest score ever in a block game.
  • highest_draw_score – The player’s highest score ever in a draw game.

The “bone” table contains information about the domino tiles themselves. The columns in this table are:

  • id – A unique key for each tile. This key will be referenced by other tables.
  • first_face_value – The number of dots on the first face (end).
  • second_face_value – The number of dots on the second face (end).

The “game” table stores information about games. The columns in this table are:

  • id – The primary key of this table; it uniquely identifies each game.
  • game_variant – The variant played, i.e. “block” or “draw”.
  • score_to_win – The minimum score needed to win a game.
  • num_round_complete – The number of rounds played in that game. Each game usually contains multiple rounds and lasts until someone achieves the winning score.

The “player_in_game” table tells us what players participate in a game. Besides the player_id, this table holds their current scores in the player_curr_score column. When a player wins, a “Y” is placed in the is_winner column. Since more than one player can win a game, we will record this detail here instead of in the “game” table.

Subject Area 2: Game Progress and Tracking

As any dominoes player knows, the game’s real action is made up of its hands, rounds, and moves – the tiny details that make or break a game. This subject area will handle those details.

Subject Area 2: Game Progress and Tracking

A game usually requires multiple rounds. For each round, a number of tiles are distributed to each player. Let’s call this distribution of tiles a “hand”. Every time a round begins, each player has a hand of tiles they can play. (Note: In some draw games, the number of tiles in each hand may exceed seven.)

The “round” table stores details of each round. This includes a snapshot of the current state of play, e.g. current tile values in the branch corners. The columns in this table are:

  • id – A unique number assigned to each round.
  • game_id – References the “game” table and indicates the game that round belongs to.
  • left_branch_value – Holds the value of the left branch corner. Any tile with a matching value (number of pips) can be played in the next move.
  • right_branch_value – Holds the value of the right branch corner. Any tile with a matching value (number of pips) can be played in the next move.
  • curr_num_tiles_boneyard – The number of tiles in the boneyard at any given time. This column value will be reduced by one each time a player draws a tile. This column is useful during draw games.

The “hand” table records all the tiles in players’ hands during a round. The columns in this table are:

  • id – The primary key of this table.
  • round_id – References the “round” table and indicates the relevant round.
  • player_id – References the “player” table and indicates the relevant player.
  • bone_id – References the “bone” table and indicates the what tiles the player has/had in their hand.
  • is_played – Whether a tile has been played. Initially, this column will be null. It will be populated with ‘Y’ only when a tile is played. The same tile cannot be played twice in one round.
  • is_fetched –A ‘Y’ in this column signifies that tiles have been drawn in a move. Useful for draw games.

The “move” table records the move sequence for each tile played in a round. The columns in this table are:

  • id – Uniquely identifies each move in a round.
  • round_id – References the “round” table and indicates the relevant round.
  • move_type – The type of move, i.e. pass (P), draw (D) or lay down (L).
  • hand_id – References the “hand” table and indicates which player is making the move.
  • branch_played_at – Signifies the branch (left or right) where the move is made. This column will only be populated in case of a ‘lay down’ move.
  • move_sequence – This number column starts with 1 and is increased by one after each move.

The “player_round_score” table stores the scores for individual players for each round. This table has a composite primary key made up of the game_id, player_id, and round_id columns. The game_id and player_id columns are referenced from the “player_in_game” table.

What Would You Add to The Domino Data Model?

Basic Train, Mexican Train, Chicken Foot, Bendomino, Cyprus, Maltese Cross, Matador, Spinner – these are just some of the many variants of dominos! What do you think it would take to extend this model to accommodate those games? What would you change or add to the basic model? Tell us in the comments section below!

go to top

Our website uses cookies. By using this website, you agree to their use in accordance with the browser settings. You can modify your browser settings on your own. For more information see our Privacy Policy.