Add a leaderboard to your game: from a scores table in the preview to a live top ten on phones

Ask for "a leaderboard" and the agent gives the game a scores collection with sample rows, a top-ten screen and a submit step at game over — working in the preview on test data, and shared between phones once you flip the game to its real backend.

What a leaderboard is made of

Three pieces: a place to keep scores, a screen that lists the best ones, and the moment the game writes a new score. In a mobile game built here the place is a collection — a small table with fields such as name, score, level and date — that the agent creates together with sample rows and a tiny server that reads and writes it. The screen is a list sorted by score. The moment is the game-over overlay, which already exists.

Because React Native has no localStorage, even a single-player "personal best" needs that collection or component state; the collection is the better choice because it survives reinstalling the game.

The request

From that paragraph the agent does four things you can see in the chat: it sets up the data layer with a scores collection and a handful of realistic sample rows, writes the Top 10 screen, adds the name prompt and submit call to the game-over overlay, and adds a "best" line to the HUD. The preview reloads with the sample rows already on the board, so you can judge the layout before any real score exists.

Test data first, real backend second

Under the preview there is a switch between test data and the real backend. In test-data mode the game talks to a local copy of the collection: fast, free, and wiped whenever you want. It is the right mode while you tune the game, because every test run would otherwise push a junk score onto a public board.

When the game is ready for other people, switch it to the real backend. The agent deploys the same collection and server for your account; from then on every installed copy of the game writes to the same table and the Top 10 is genuinely shared. The switch is part of the paid plans, and the APK you build afterwards carries the real backend address. Nothing in the game code changes between the two modes — that is the point of the switch.

Keeping the board honest

A leaderboard that anyone can write to will eventually hold a score of nine billion. The fixes are cheap when you ask for them up front:

• Server-side cap. "Reject any score above the maximum the level formula allows for the level and seconds reported." Since levels are data (see the levels guide), the server can compute that maximum.
• One name per device. Store the chosen name with the device's first submission and reuse it; renaming is allowed but keeps the device's own rows.
• Keep the evidence. Level reached and seconds played make an impossible row obvious at a glance, so you can delete it from the data screen.
• Profanity filter on names. A short blocklist in the server is enough for a small game; ask for it and extend the list by chatting.

None of this requires accounts. If you do want sign-in — so a player keeps a name across phones — ask for it separately; it adds screens and most small games are better without.

Daily and weekly boards

An all-time board goes stale once a few players have unreachable scores. Boards that reset keep newcomers interested:

This is a filter on the same collection, not a second table. Pair it with a daily seed in the game itself — "everyone plays the same level order today" — and the daily board compares like with like.

What the Top 10 screen should show

Rank, name, score, and one piece of context: the level reached or the date. Highlight the player's own row even when it is outside the ten — show it pinned at the bottom with its real rank, which answers the question every player has. On the game-over overlay, two numbers are enough: this run's score and the rank it earned, with a "see the board" button.

Ask for the look you want in the same message: "neon rows on black, the top three in gold, silver and bronze". The agent styles the list without touching the data. Browse the games made here to see a few boards before deciding.

Browser games

A canvas game can use the same backend; the request is identical. Two differences to plan for: the published site has no persistent storage, so the remembered name must be stored on the backend as well, and pointer-and-keyboard players put up higher scores than thumbs do — if the same game ships as both, keep separate boards or store the platform with each row.

Submitting without a backend at all

Sometimes a board is not worth a server: a kids' game that lives on one tablet, a jam entry. Then ask for "a local best-scores list of the last ten runs" — component state in a mobile game, localStorage in a browser game during the preview — and skip the backend entirely. You can always add the collection later; the game-over overlay does not care where the score goes.

Checklist

• Sample rows look right on the Top 10 screen in the preview.
• A real run from the game-over overlay appears on the board in test-data mode.
• Server-side cap and name rules are in place before the real backend switch.
• After the switch, a score from the installed APK appears on a second phone.
• If the game shows ads, the board screen is a reasonable place for a banner — see where ads fit.

Frequently asked