Sightstone

01 — The bet

A suggestion has to give its reasons.

Every score breaks down

Before every League of Legends game, the two teams take turns banning and picking champions: twenty choices, about thirty seconds each. Pro teams prepare that draft with analysts. My team at Lausanne Esport, playing semi-pro, had nothing like it. So I built what we were missing: scout the opponent, write the scenarios together, draft live on match night, then review the series.

At the centre sits the engine, and a product bet. A coach overrules a black box the first time it is wrong, and stops listening after that. So the engine is not a trained model but a sum of named weights. Every suggestion breaks down into those terms, fast enough to read on the clock.

02 — The proof

Then I let the data overrule me.

A rule set in advance

The engine has two halves. The suggestions rank champions for the next pick. The verdict reads a whole draft and says which side it favours, from four readings: the matchup in each lane, pairs of champions, the shape of each composition, and the patch. Hand-set weights are only a hunch. So a job replays 18,127 professional games through both halves, scoring each game only with the patches played before it, and fits the verdict by logistic regression.

So the fitted weights replaced mine, under a rule set before seeing the result: a fit goes live only if it is better calibrated and loses no more than half a point at ordering games. And I don’t hide it: a draft moves a game by a few points; the five players do the rest.

03 — A decision

Why it looks one pick ahead, and no further.

Not a matter of compute

A chess engine calculates many moves ahead. Sightstone looks only one pick ahead: before suggesting a champion, it checks what the other team could answer with, weighted by how likely they are to take it. Going deeper would cost almost nothing to compute, but it would make the tool worse, for four reasons.

1. 01

   The score is too faint.

   Chess suits deep search because checkmate is a clear result. A draft barely moves the outcome of a game (AUC 0.54), and a deep search on a score this noisy mostly finds the branches where the noise happened to look good.

2. 02

   The opponent is not a perfect player.

   Classic search assumes they always play the hardest move for us. An amateur team plays what it knows, so the engine reads their likely picks from their own history, and that estimate blurs a little more with every turn.

3. 03

   It would have to guess our own picks too.

   Either the engine plays against itself and reinforces its own biases, or it models the coach from about thirty games a split, which is not enough to learn from.

4. 04

   The reason has to fit on one line.

   Today a coach reads “exposed to Fiora (62%) if they take it” and can check it right away. A search tree doesn’t sum up in one line.

If search ever earns a place, it will be at the end of the draft, with few turns left and every choice weighing more. At the first pick of a game, the engine finds the pro’s choice in its top six 71% of the time; at the last, 39%. The same backtest will decide: a two-turn search goes in only if that last number goes up.

04 — Architecture

Built for a thirty-second clock, and one developer.

Two constraints shaped the rest: a room drafting against the clock, and one person to keep it running. Champion data comes from Riot’s public CDN, so drafting needs no key. Long jobs, like importing pro drafts or refitting the weights, run on GitHub Actions rather than serverless. The easiest way to see what the clock demands is to follow a single pick.