Everything starts from a seed row: a single round in which every player appears once. The example is 16 players, numbered 0–15 at this stage. The largest number (15) is a fixed "anchor" player who stays put in every round, while everyone else moves on a clock of 0–14.

Read the row four at a time. Each group is one table: the first two players are partners against the next two. Here round 1 is 1 & 2 vs 15 & 0, 11 & 13 vs 4 & 8, 6 & 9 vs 14 & 5 and 7 & 12 vs 3 & 10.

The order matters. A plain 0, 1, 2, 3… row does not work. The seed must be chosen so that, once every round is built from it, each player partners everyone exactly once and opposes everyone exactly twice. The seeds come from Durango Bill's published cyclic solutions, or are built with the methods in the seed guide, which explains the rule step by step.

The seed row is expanded similar to that shown on Devenezia's site which is typical for tournament expansion.

The Pn headings identify the player slot and the number in the grid is the individual player ID. Most statistical formulas label players from 0 - n.

The grid is created by incrementing the player ID by +1. The max player ID (15 in his case) is fixed for the grid. The players IDs are recycled to 0, after the n-1 number. There will then be a 0 - n distribution for each round / row.

The grid is then incremented by +1 to make it more relatable. Often times this format is used for tournaments and satisfies the minimum partner/opponent combinations.

The tourney grid is highlighted to show the table alignment with colored bands before table optimization.

Progressive table shifting is a major part of optimization based on JDAWiseman's work.

In this case each row are progressively shifted by n mod 4 (players divided by the 4 players at each table) or 4 in this case. The first row moves entire table groups to the left. The blue table then moves to the end. The second row moves 2 Table groups to the left...so the blue and the gold table move to the end.

This progressive shuffling breaks up the #16 player from being stuck at Table 1.

However, this also causes a pattern of each player having a round where they get stuck at the same table, highlighted in light red.

Now we can then shuffle table groups ↔ within each row. This won't break the player/partner/opponent relationship we created earlier.

In this case anywhere from 1 to 3 tables are shuffled to break up the consecutive tables issue. Afterwards you'll see there is a new pattern established across the entire grid. This will not create an even distribution of players/table relationships, but no player will play at the same consecutive table. The optimizer does this across the whole schedule at once instead of by hand: for each round order it uses a beam search, keeping many partial table assignments alive and never letting a player return to the table they just left.

Finally, round / row reordering ↕ can help level the distribution and keep the extremes like a player not appearing at a table in the entire tournament. The optimizer searches the round order directly, swapping and moving rounds and keeping any order whose best table assignment balances at least as well. Typical results are about 90–95% quality at 20 players, 98% at 24–28, and 100% from 32 players up, usually within a minute.

A perfectly even distribution is not possible, because the rounds do not divide evenly by the tables. Every player plays one round fewer than 4 per table (19 rounds over 5 tables at 20 players, 3.8 on average), so the best possible is 4 visits at every table except one, which gets 3. The optimizer aims for exactly that: first it removes repeat tables in consecutive rounds, then extremes (0, 1, 6 or more visits), then 2s, and finally any 5s and extra 3s. Visits of 3–5 are acceptable, with no extremes from 24 players up. At 20 players a stray extreme or two can remain; re-running the optimizer or allowing more attempts may remove it.

The optimizer works in two stages. A beam search first finds a clean schedule, then an annealing stage searches round order and table assignments together and keeps its result only when it scores better. The optimizer guide explains both stages step by step. In practice only some players reach the exact 4s-and-one-3 pattern. The full pattern for every player is impossible at 12 and 16 players (proved by computer search, even ignoring the repeat-table rule), and at larger sizes it is not known to be reachable.

The player-table grids in the optimizer and the tournament creator use the same colours: 4 green, 3 light green, 5 lighter green, then yellow, orange and red as a count moves further outside 3–5.