How to Track Guild League Scoreboards in Black Desert Online

Black Desert Online shows you a Guild League scoreboard for about as long as it takes to read three rows, and then it is gone. There is no export button, no match history and no API. If your guild wants to know who actually carried last night, somebody has to capture that screen and turn it into data. This guide covers how Project Athena does it: screenshot OCR, the match identity rule that prevents double counting, family-name reconciliation, and getting the numbers back out again.

Why Guild League tracking is harder than it looks

Three properties of the in-game scoreboard make naive tracking fail. It is transient, so the only durable artefact is a screenshot. It shows two guilds side by side, so half of every capture is data you must not store. And the family names are rendered in a game font at whatever resolution the player's monitor happens to be, which means optical character recognition will misread some of them, every time, forever. A tracking system that does not plan for all three produces a leaderboard nobody trusts.

Screenshot OCR: Gemini vision with a Tesseract fallback

Upload a scoreboard screenshot and it goes down one of two extraction paths. When a Gemini API key is configured and the guild is within its quota, the image is sent to Gemini vision, which is asked for a strict JSON object containing the match date, the match time, the result and one row per player. If that call fails, returns no rows, or Gemini is simply not configured, extraction falls back to a local Tesseract pass over the same image.

Both engines produce the same row shape, so nothing downstream cares which one ran — the stored report just records which engine produced it, along with a confidence figure where one is available. That fallback matters: a self-hosted guild with no API key still gets a parsed scoreboard rather than an error page.

What gets extracted per player

A Guild League scoreboard reports six numeric columns. That is deliberately fewer than a Node War scoreboard, and the two are stored as separate record types rather than being forced into one shared shape with nine permanently empty fields.

From those six columns the dashboard derives per-player aggregates, a kill/death ratio, a damage board, category leaders and an impact score. The impact weighting for Guild League is its own model rather than the Node War one, because a league match has no objectives, no structures and no siege mechanics to weight.

Date plus time is the match identity

Guild League runs several matches in a single evening — a guild might play at 00:15, 00:43, 01:13 and 23:41 on the same calendar day. A tracker keyed on the date alone treats those as one match, and every re-upload silently doubles each player's kills, deaths, damage and match count.

So the identity key is the date and the clock time together. Uploading a scoreboard for a kickoff that already exists is refused, and the refusal names the existing match so you can edit or delete it instead of entering it twice. It is a small rule that removes an entire class of "why does the leaderboard say I played 14 matches" support question.

Reconciling family names: rename and merge

OCR misreads names. A leading glyph gets absorbed into the first letter, an h becomes an n, a capital I becomes a lowercase l. Left alone, one player fragments into three ghosts, each with a third of their real statistics, and the leaderboard becomes fiction. Two tools fix this:

• Rename rewrites a single spelling across every stored match. Use it when the correct name is obvious and there is only one wrong version.
• Merge folds several spellings into one canonical family name at once. The dashboard surfaces likely duplicate clusters — near-identical spellings that appear across different matches — so you are confirming a suggestion rather than hunting through history by eye.

Both operations rewrite the historical rows, which means totals, category leaders, the impact ranking and any export you generate afterwards all agree immediately. There is no separate alias table to keep in sync.

Comparison and export

Two matches side by side answers questions a single scoreboard cannot: did the roster change help, did the player you promoted actually perform, did the damage taken figure move after you rebuilt the defence group. The war comparison view puts two reports next to each other for exactly that.

And when you want to leave the dashboard entirely, CSV export hands you the raw per-player rows. Your data is not held hostage: pull it into a spreadsheet, chart it however your officers prefer, or feed it into whatever analysis you already run. A Discord export command also posts a formatted summary embed straight into a channel, so the highlights reach the guild without anybody opening a browser.

A workable routine

• Screenshot the scoreboard before the results screen closes. One capture per match.
• Upload it the same night, with the correct match time. The time is part of the identity key, so guessing costs you a duplicate later.
• Review the extracted rows before saving. OCR is good, not infallible, and the edit step exists for a reason.
• Run a merge pass roughly monthly to fold in whatever new misspellings have accumulated.
• Export to CSV before any large clean-up, so you always have the pre-change snapshot.

Scoreboard analysis is the back half of the loop; the front half is fielding the right roster in the first place. Start with the Node War roster guide, size it with the tier composition comparison, and see the documentation for the upload commands and permissions.