Game leaderboard services: current alternatives to Scoreloop

Scoreloop, one of the services covered in the original version of this article, shut down in 2014. The other providers and prices in that list should not be treated as current recommendations either.

If you are adding online high scores to a mobile, desktop, web, or cross-platform game today, choose a service based on the game’s platform, authentication model, trust boundary, operational budget, and how much backend code you want to own. A leaderboard is not just a sorted table: score submission, identity, seasons, resets, moderation, and anti-cheat decisions affect the player experience.

Shortlist of current options

Service	Best fit	Main trade-off
Google Play Games Services leaderboards	An Android game that already uses Google Play Games player identity and platform features	It is closely tied to the Google Play Games ecosystem rather than being a general cross-platform backend
Unity Leaderboards	A Unity project that wants a managed leaderboard service in the Unity Gaming Services ecosystem	Review the current Unity service limits, SDK requirements, and regional availability before committing
Nakama	A team that wants an open-source game backend with leaderboards and control over deployment	Self-hosting means you own upgrades, monitoring, scaling, backups, and abuse controls; Heroic Labs pricing covers its managed offering
LootLocker	A small team looking for a hosted game backend with a dedicated leaderboard feature	Compare the current feature limits and LootLocker pricing with your expected players and writes
Custom service with Firebase Realtime Database or Supabase	A developer who needs a custom data model or already operates one of these backends	You must design score validation, ranking queries, seasons, moderation, and cost controls yourself

This is a shortlist, not a claim that one provider is universally best. Product names, limits, SDKs, and prices change, so use the linked documentation and pricing pages as the final source before starting a migration.

What to compare before choosing

Platform and player identity

Start with the platforms you will actually ship. Google Play Games Services is a natural fit for an Android title that already uses Google Play Games sign-in. Unity Leaderboards can reduce integration work for a game already built around Unity Gaming Services. A hosted or self-hosted backend is usually more flexible when the same account must work across Android, iOS, web, and desktop.

Check whether a service can map platform identities to one internal player ID. Decide what happens when a player reinstalls the game, plays offline, changes devices, links accounts, or asks to delete their data. Do not make a display name the identity key.

Score trust and anti-cheat

Never treat a score sent by an untrusted game client as proof that the player earned it. At minimum:

1. Authenticate the player and associate the submission with a server-side account.
2. Validate the result against a run, match, replay, or signed event when the game design permits it.
3. Enforce plausible bounds, rate limits, idempotency, and a submission window.
4. Keep moderation tools or an administrative path for removing invalid scores.

A leaderboard API can store and rank values, but it cannot automatically know whether a client fabricated a result. Competitive games may need a server-authoritative simulation, replay review, or a separate anti-cheat system.

Seasons, resets, and ranking rules

Confirm whether the service supports the ranking rules you need or whether you must create separate leaderboard IDs or tables. Write down:

• ascending versus descending scores;
• ties and tie-breakers;
• all-time, weekly, daily, or event-specific boards;
• timezone and reset boundaries;
• regional, platform, friend-only, and global scopes;
• pagination and a player’s rank-neighborhood query;
• retention and export requirements.

If you cannot describe the reset and tie behavior in a test case, the feature is not ready to ship.

Cost and operational ownership

Compare more than the headline free tier. Estimate authenticated players, score submissions, reads for leaderboard screens, peak traffic, storage, bandwidth, logs, and moderation requests. A service that is inexpensive for a small launch can become costly if the client refreshes the board on every screen or if an attacker floods the submission endpoint.

Managed services reduce infrastructure work but leave you dependent on their SDKs, limits, outages, regions, and pricing. Self-hosting gives more control and can be a good fit for an indie team with operational experience, but the server, database, backups, monitoring, and security become your responsibility.

How the current options differ

Google Play Games Services

Use Google Play Games Services leaderboards when the game is primarily distributed through Google Play and the platform identity and social features match your design. It is a platform service, not a replacement for a general cross-platform account and backend layer.

Before choosing it, verify the current Android SDK integration, account-linking behavior, visibility rules, quota, and migration path in the Android documentation. If you plan to ship the same competitive profile on iOS, web, or desktop, model that cross-platform identity before wiring the leaderboard directly to a platform account.

Unity Leaderboards

Unity Leaderboards is worth evaluating when your game already uses Unity and you want a managed service rather than building ranking storage and APIs yourself. Read the leaderboard concepts documentation for the service model, then confirm the supported SDKs and authentication flow for every target platform.

Use the Unity Gaming Services pricing page to model the expected reads and writes. Keep your game code behind a small leaderboard adapter so that a provider change does not require rewriting score, profile, and UI code throughout the client.

Nakama

Nakama’s leaderboard feature is part of an open-source game backend. It is a candidate when you need more than a ranking API, want to extend server-side game logic, or need the option to self-host. Heroic Labs also documents its managed hosting plans.

The flexibility comes with operational responsibility when self-hosted. Plan for authentication, database backups, upgrades, observability, capacity, DDoS protection, and moderation. For a small team, compare the engineering time for operating Nakama with the recurring price of a hosted service.

LootLocker

LootLocker’s leaderboard documentation provides a managed game-backend route for teams that do not want to build leaderboard storage and endpoints from scratch. Review its authentication, SDK, environment, and reset behavior against the game’s requirements, not only the presence of a leaderboard feature.

Use the LootLocker pricing page to calculate the cost at launch and at a realistic success case. Confirm how development, production, player counts, requests, and support are treated before making the service a dependency.

Firebase or Supabase as a custom backend

A custom implementation can be the right choice when leaderboard data is only one part of an existing backend. Firebase Realtime Database provides a general realtime data store and security model; Supabase provides a Postgres-based backend with database functions. Neither link should be read as a dedicated leaderboard product recommendation.

For a custom design, keep score submissions behind a server-side function or API. Store a normalized player ID, score, timestamp, season ID, source event, and moderation state. Use an indexed query or a materialized ranking strategy rather than downloading every player’s score to the client. Read the current Firebase pricing or Supabase pricing documentation and budget for reads, writes, storage, and egress.

A practical selection process

Use this order to avoid choosing a provider from a feature checklist alone:

1. Write the ranking contract. Define score direction, ties, seasons, scopes, resets, pagination, and account deletion behavior.
2. Choose the trust boundary. Decide which server-side event proves a score and how invalid submissions are removed.
3. List target platforms. Include launch platforms and plausible future platforms before selecting a platform-locked identity system.
4. Estimate traffic. Model submissions and reads during a normal session, a launch spike, and an abuse scenario.
5. Build an adapter. Keep authentication, submission, rank queries, and error handling behind a small interface in the game.
6. Test failure cases. Cover offline play, retries, duplicate requests, expired sessions, service errors, season changes, and a player who requests account deletion.

For a small first game, a managed service can be the fastest route if its identity and platform support fit. For a larger or long-lived game, the cost of migration and the ability to export player data deserve as much attention as the initial integration.

Migration checklist for a legacy service

If you are replacing Scoreloop or another discontinued backend:

• export any data you are legally and technically able to retain;
• map legacy accounts to a new internal player ID without exposing old credentials;
• preserve only scores that have a trustworthy provenance;
• define a cutoff time and communicate the reset or migration policy;
• use a staging project to test authentication, score submission, ranking, and moderation;
• release the new client with telemetry for rejected submissions and service errors;
• remove legacy credentials and endpoints after the migration window closes.

Do not copy a legacy provider’s client-side trust model into the new service. A new API does not make an old, forgeable score submission flow secure.

If you are still planning the game itself, Creating a Mobile Game: Where to Start covers early planning and platform decisions. For an example of the older cross-platform workflow, see How I made my first Cross Platform Game using GameMaker and Free Resources; treat its provider and platform details as historical rather than current implementation guidance.

Historical media from the original article

The original article included the following 2014 service screenshots. They are retained for editorial history and are not evidence that those services, plans, or URLs are still available.

Show the original service images