Best Practices

Guidance that applies whichever platform you build on.

Let guests play

Most people who open your game are not signed in, and many never will be. A game that stops at a login wall loses them.

Let anonymous players play. Show signed-in players their nickname so they can see the connection is live, and show guests a sign-in button next to a short, concrete list of what signing in adds — saved progress, a place on the leaderboard, achievements. "Sign in to keep your progress" earns more sign-ins than "Sign in".

Let players choose when data is sent

Send scores and saved data at moments the player caused: finishing a run, pressing Save, completing a level. Data that leaves at a moment the player did not ask for is data they cannot retry when it fails.

Be sparing with requests

Every SDK call is a network request. Open your browser's network tab and watch your game for a minute — if requests are going out every few seconds, that is too often. Sustained traffic can be throttled, and throttled requests fail.

Batch where the SDK offers it, cache what does not change, and throttle auto-saves to at most once a minute.

Handle failures where the player can see them

Requests fail: connections drop, sessions expire, servers have bad days. Check that a call succeeded, and if a save did not go through, say so. A player who is told "Could not save — retrying" will wait. A player who is told nothing discovers the loss later, when their progress is gone and it is too late to do anything about it.

Handle it in the same place you would handle any other error, and prefer retrying quietly over interrupting play.

Verify players server-side

If your game has its own backend, never take the player's identity from the game client — verify the access token instead. See Verifying Players.