How a backgammon coach fits in your phone

You are deciding whether to hit or make a point, and both plays are legal and look reasonable. The coach’s job is to help you choose between them.

To answer perfectly, it would need to account for all the dice that could follow, all the choices both players could make, the cube, and sometimes the match score. Even the opponent’s next roll creates a new set of decisions. Carry that forward and the possibilities multiply very quickly.

To answer during a game, the engine combines quick estimates of positions with a search through possible continuations.

What if we played the position thousands of times?

One practical way to compare two moves is to play many games from each resulting position, using fresh dice and a strong engine for both sides. Doing this and counting the wins, losses, gammons and backgammons is called a rollout.

With enough games, the average becomes steadier. A move that happened to lose its first few trials gets more chances to show what it is worth. GNU Backgammon’s manual explains this approach and the ways engines make it more efficient.

An infinite rollout would not automatically give the position’s value under perfect play. Infinitely many completed games would remove sampling noise, but the answer would still describe the way those games were played. If the engine mishandles a type of position, playing more games does not remove that habit. To evaluate the position assuming perfect play, both sides would have to make the best choices throughout.

There are also two different limits people sometimes mix up. Playing each trial all the way to the end avoids having to guess its final result. Running more trials reduces the luck in the average. A truncated rollout stops early and uses an evaluator for the unfinished position, so it retains some of that evaluator’s uncertainty too.

A rollout can help settle a difficult comparison, but playing thousands of games for every possible move would make you wait far too long for a hint.

Estimate a position’s chances with a neural network

A neural network can estimate the chances of winning from a position without simulating thousands of games each time. It receives numbers describing the board: where the checkers are, how many are on the bar or already off, and whose perspective it is evaluating.

In our engine, the position evaluator returns six probabilities: a single win, a gammon win, a backgammon win, and the three corresponding losses. A gammon pays double, a backgammon triple, before applying the cube. These six separate outcomes add up to 100%. Add the three winning outcomes to get the total winning chance.

1. 1
   Find the legal plays

   The engine generates legal plays and the boards they would leave.

2. 2
   Estimate six outcomes

   The network assigns probabilities to six ways the game can end.

   • Single win
   • Gammon win
   • Backgammon win
   • Single loss
   • Gammon loss
   • Backgammon loss
3. 3
   Look further ahead

   Search examines future rolls and replies, then compares the plays.

Read the position

Ivory, point: number of checkers. 1: 2, 3: 3, 4: 5, 5: 5. Red: 19: 5, 21: 5, 22: 3, 24: 2. On the bar: Ivory 0, Red 0. Borne off: Ivory 0, Red 0.

The model does not know the next dice. A 60% winning chance means the position is estimated to win about six times in ten under the play being modelled. You can still lose the game you are playing now.

Keeping all six outcomes matters because the move that wins most often is not always the one that wins the most points.

Move B loses more often, but its extra gammons pay for that. Over 100 games matching these proportions, A earns 60 points and loses 40: a net gain of 20. B earns 40 from single wins and 30 from gammons, then loses 45: a net gain of 25.

In this no-cube example, the average points return is called equity: +0.20 for A and +0.25 for B. In a match, the value of a gammon changes with the score. Cube ownership and future doubling opportunities matter too. The six probabilities help with that decision, but the engine also needs the cube situation and match score.

Check the opponent’s replies before choosing

Evaluating the board after each legal play is a start. But a position that looks safe at first glance might give the opponent an excellent reply. A loose checker that looks alarming might be hard to attack.

Search lets the engine check those first impressions. For a candidate move, it considers the opponent’s possible rolls and replies, then uses the evaluator on the later positions. It brings those results back together, weighting them by how often each roll occurs.

There are 36 equally likely ordered dice results, or 21 distinct pairs if order is ignored. A non-double such as 6–3 occurs twice as often as 3–3. A search must preserve that difference when it averages the possibilities.

The catch is the number of boards. More candidate plays, more replies and another turn of lookahead can mean many more evaluations. A small improvement in the cost of judging one board can make a much larger search affordable.

Use a stronger engine to train a smaller one

During training, we can afford to spend much longer on a position than we can during your turn. We use a strong engine as a teacher: it examines many positions and estimates their outcome probabilities. A smaller network, the student, learns to reproduce those estimates on boards it is shown.

This approach is called knowledge distillation. It is an established machine-learning idea, developed in work including Geoffrey Hinton, Oriol Vinyals and Jeff Dean’s paper. We did not invent the method.

CUBE Backgammon builds on established backgammon research and open-source work, including wildbg and GNU Backgammon. Training takes place before the app reaches your phone, using a collection of analysed positions.

The student does not store a copy of every position it has seen. It learns numerical weights: values adjusted during training that allow it to estimate positions it has not encountered before. Once trained, it can use those weights without asking the teacher to analyse each new board.

Predictions that are close on average can still lead to a costly error on a particular move. The student may miss something the teacher gets right or copy a mistake the teacher makes, so we check selected moves as well as differences in the predicted probabilities.

Our development accounts describe a network that copied GNU Backgammon more closely but chose worse moves and a test distorted by supplying the wrong player to roll.

Good advice has to arrive while you are still playing

A hint is less useful if it arrives after you have lost track of the move you were considering. The analysis has to answer while you can still weigh the alternatives, keeping the board responsive and limiting battery use.

The difficulty also changes with the position. A racing lead is often easy to see from the pip count, while deciding whether to leave an anchor can require a much closer look at what might happen next. Even two moves that look almost identical can lead to very different games.

Spending more time on a decision can help, but time alone does not guarantee a better answer. Looking further ahead is useful only if the engine judges the resulting positions well. Examining a wider range of replies can sometimes matter more than following one line for another turn.

This is where the size of the model becomes a practical choice. A larger model may recognise more subtle differences, yet take longer to judge each board. A smaller one may leave room to consider more possibilities in the same time. The useful question is how well the complete analysis chooses a move within the time available.

A smaller network can leave more time to search

Circles represent neurons and lines their connections. A network can grow by adding neurons to a layer, adding layers, or both.

A compact network

One hidden layer in this example. Fewer connections to calculate for each board.

The same total search time

Each block represents one evaluated position.

A deeper, wider network

Three hidden layers in this example. More calculation, with the chance to recognise subtler differences.

The same total search time

Each block represents one evaluated position.

A compact network can be the better choice if the time saved lets it examine an opponent’s reply that a larger network would not have reached. But examining more boards helps only if their evaluations are reliable enough. The comparison must cover the complete analysis, on the same device and within the same time limit.

The game analysis runs on your device, so asking for a hint does not need a connection. The phone uses weights learned beforehand; it does not repeat the training process for each position.

How does the coach decide to think longer?

Difficulty is not a single confidence percentage. The engine has signals: how many possibilities exist, their estimated value and how stable the preferred choice is when checked. Those signals mean different things.

1. Rank the plays

   Generate legal plays and obtain an initial estimate.

2. Check the choice

   Examine the margins and disagreement between analyses.

3. Go further when needed

   Recheck candidates or look further ahead, depending on the decision.

Many legal plays

More resulting boards need evaluation. That creates work without necessarily making the choice ambiguous.

Close estimates

The candidates deserve a careful comparison. Two good plays can also be nearly equivalent.

A changing ranking

When analyses prefer different plays, the initial judgement needs a stronger cross-check.

A possible correction

Before interrupting, the coach needs to check the player’s move as well as the alternative. A confident correction is inappropriate if the difference remains uncertain.

A small margin does not trigger the same search everywhere. Playing against you, answering a hint and deciding whether to correct your move are different tasks. Opponent difficulty controls playing effort; the coach has its own checks.

How long should that take?

These are responsiveness targets, not guaranteed measured times or hard limits for each move. The phone, the position and work already available change the actual time.

Opponent

≈ 0.45 s

A target for routine moves, with more time allowed for a difficult case.

Requested hint

≈ 1 s

A target for 95% of requests, allowing occasional longer checks of difficult positions.

Before an interruption

≈ 0.75 s

A target for 95% of confirmation checks, to avoid a hasty interruption.

An earlier physical iPhone 15 Pro check illustrates the spread: across 154 Expert turns in a previous development build, median decision time was about 0.15 seconds and the slowest was about 3.9 seconds. Those are total decision times, not extra waiting after animations. This small sample does not describe every phone or the current release.

Post-game analysis can take longer: it has several decisions to revisit and can give them more work. Its total time also depends on the length of the game.

Choosing a move is only half the coaching job

For the first coached examples in CUBE Backgammon, we wanted you to try a move and see the coach suggest an alternative before you confirmed it. You have just made a decision, so you can compare the suggestion with what you were trying to achieve while the position is still familiar.

A small estimated difference between two plays may not justify calling one a mistake. The coach needs to account for uncertainty in its estimates before interrupting you; the review after the game then provides time to examine the decisions without holding up play.

The engine’s six probabilities do not explain by themselves why a move is preferable. To give a useful reason, the app has to examine concrete features of the board: shots left behind, useful builders, an anchor kept, a racing lead, the plan a move supports.

“This leaves 11 hitting rolls out of 36” is a claim you can inspect. “The network preferred it” tells you much less about what to look for next time. Our guide to game plans covers some of that vocabulary.

Test the probabilities and the recommended moves

First, test on positions the student was not trained on. Otherwise a reassuring score may mostly show that it remembers its lessons.

A useful test checks how close the probabilities are to the reference and how well the engine ranks the moves. It also measures the cost of mistakes and whether the quicker calculations make the phone feel faster.

Checking only against the teacher has a limit: teacher and student can share the same blind spot. Independent analysis and careful rollouts help challenge their agreement. Tests also need a variety of positions, because a good overall average can hide a weakness in a particular part of the game.

Our experiment with 47 recorded tournament matches made that especially clear for coaching. Good advice most of the time did not excuse confidently correcting a move that was already sound. That article describes a historical test, rather than a score for the current release.

Our article on CUBE Backgammon’s playing strength puts the recorded results beside the standards used for human players, and explains why they do not yet give us a professional ranking.

Finally, one game is not enough to judge an engine: the dice can make it lose even when it plays well. Good rolls can also hide poor decisions. The same is true of your own play: a run of losses can come from unlucky rolls, even when you make good decisions.