Skip to main content
summer-leaderboards is a skill from the Summer skill library: a guide your AI agent reads when the task matches, so it builds the good version on the first try. Leaderboards in a Summer game: queue ratings from matches, and Game rankings your authority scores.

When your agent uses it

  • The user wants a leaderboard, high scores, ranks, MMR, Elo or a ‘top 50’ screen in a Summer game
  • A rated queue should show each player’s rating, standing or percentile
  • The authority should write a score, such as total coins or best time, to a Game-wide ranking
  • A co-op mode should rate players against the content with authority_v1 rating deltas

Install

summer setup installs every skill for your agent. To add only this one:
Swap claude-code for your agent, such as codex or cursor. See Skills for every option.

The skill

Overview

Summer keeps two kinds of score board. Pick by where the number comes from: Players only ever read their own rating and score, plus the public top 50, which shows display names, never account ids. Nobody can write a score from a client. Where it works: leaderboards, standings and rankings are read through the Summer app that hosts the player, so they work in hosted games only. Under Local Play they fail with a typed code (step 5); the authority’s ratings.load returns a deterministic test value. Build the screens so they degrade gracefully, and check the real numbers on a hosted staging build. This skill extends the Courtyard game: its authority concludes matches as in summer-match-results.

Steps

1. Declare the boards

In summer.build.json, a rated queue gets a rating, and runtime.rankings declares Game rankings:
  • ratingSystemRef: elo_v1 lets Summer compute rating moves from win, loss and draw. authority_v1 makes your authority report each player’s move (step 4). Optional initialRating is a newcomer’s rating (default 1200).
  • A ranking name is lower-case letters and digits separated by single ., _ or -, at most 64 characters; at most 32 rankings. initialRating defaults to 0.
  • To make a rated queue and a ranking one board, give the queue "rankingRef": "<ranking name>" and drop the queue’s initialRating. A queue and a ranking may not share a name without rankingRef.

2. Show a queue’s top 50 and the player’s standing

On a client, after Summer is initialized (no match needed):
  • entries holds up to 50 rows, best first; you marks the player’s own row.
  • standing.rank is set only inside the top 1000; otherwise show the percentile. Before the first rated match rated is false and value is the queue’s initialRating.
  • Summer.client.ratings.get_current(queue) returns the last known SummerRatingSnapshot (value, games, version) without a network read, or null. refresh(queue) reads it again; rating_changed(queue) fires when it moves.
  • One read of each kind is in flight at a time; calling again while one is pending returns the same operation.
After a match, Summer.client.ratings.rating_committed delivers the player’s own before-and-after rating (see summer-match-results).

3. Write a Game ranking from the authority

Only the authority writes rankings, by the player’s stable id, with compare-and-set: read the score and its version, write the new absolute value against that version, and read again if someone else wrote first. In authority/main.gd, after the match concluded:
sessions maps each session_id to the SummerSession the authority keeps in _on_session_joined (summer-match-results, step 1). The engine never retries a write. After a failure other than a conflict, read the score before deciding to write again: the first write may have committed. Clients read their own ranking with Summer.client.rankings.get_score("coins"), standing("coins") (full rank and player count; rank 0 before the first score) and leaderboard("coins") (top 50, zero-score players included). These work in a standalone game too, before any match.

4. Own a co-op queue’s rating (authority_v1)

Elo rates two sides against each other. A co-op mode, where a group plays against the content, declares "ratingSystemRef": "authority_v1" and reports every player’s move when the match concludes:
  • Each delta is an int within ±1000, one for every participant. Deltas on a non-authority_v1 queue, or a missing one, fail the conclusion with invalid_request and commit nothing; conclude again with corrected arguments.
  • Summer.authority.ratings.load(session) is for the authority’s own logic. Never show one player’s rating to other players; the leaderboard is the public view.
  • Summer.authority.ratings.leaderboard("dungeon") reads the same top 50, unmarked, for an in-World trophy wall.

5. Degrade gracefully where boards aren’t available

Under Local Play these calls fail without a Summer account behind them: Hide or grey out leaderboard buttons when a read fails; never block the game on them.

Checklist

  • Every board is declared: rated queues with ratingSystemRef, rankings under runtime.rankings.
  • The leaderboard screen marks the player’s own row and shows rank or percentile.
  • Ranking writes happen only on the authority, by player.user_id, with compare-and-set and a conflict re-read.
  • authority_v1 queues conclude with a delta for every participant; other queues send none.
  • Every read handles failure, and the game stays playable without boards.
  • Real numbers checked on a hosted staging build.

Common mistakes

See also

  • summer-match-results — concluding matches, which moves ratings
  • summer-matchmaking — declaring rated queues and teams
  • summer-player-data — saving per-player progress that isn’t a ranking

From a shell

No Summer MCP tools in this session? Run each one as a command; when summer --version is missing or below 4.0, use npx -y summer-engine@latest in place of summer. Fields are flags in kebab-case (--scene-path res://main.tscn) or one --input '<json>', and summer ops describe <op> prints the exact input. The summer-cli skill has the rest.
  • multiplayer: Start here for Summer multiplayer: how authority, clients, Worlds and Sessions fit, and what comes next.
  • summer-matchmaking: Get players into matches with Summer matchmaking: queues, teams, accept prompts, join progress and failures.
  • summer-match-results: End a Summer match: report each player’s win, loss or draw, show results on clients, then close the World.
  • summer-player-data: Save a player’s progress so it follows them to every match: authority load and commit, autosave, safe retries.

Source: library/skills/summer-leaderboards/SKILL.md, rendered from summer-engine@4.3.0 on npm.