Scratch Cloud Variable High Scores and Their Limits

Every few weeks someone in our feedback threads posts the same question: "How do I make a high score list that everyone can see?" They have finished a small Scratch game, it is fun, and they want people to compete. Then they discover cloud variables, try to store a list of names and scores, and run straight into a wall. The variable will not accept letters. The scores overwrite each other. A friend reports that their score never saved at all.

Cloud variables can absolutely power a shared leaderboard, and plenty of popular Scratch games have one. But they have hard limits that the editor does not explain, and knowing those limits before you design your scoreboard saves a lot of wasted afternoons. This is what I have learned from running leaderboards on three of our community projects.

What a cloud variable actually is

A normal Scratch variable lives inside one person's copy of the project while they play it. A cloud variable is stored on Scratch's servers, so every player sees the same value. You create one by ticking "Store in the cloud" when making a variable, and Scratch marks it with a small cloud icon.

The rules that catch people out:

• Numbers only. A cloud variable can hold digits, and that is essentially it. No letters, no spaces. A username has to be converted into numbers before you can store it.
• A length cap. Each cloud variable holds up to 256 characters. Go over and the update is rejected.
• Ten per project. You can have at most ten cloud variables in one project.
• Not everyone can write. Only logged-in users with full Scratcher status can change cloud variables. Accounts still marked as New Scratchers, and anyone not logged in, can see the values but their changes do not save. This is why a friend's score "never saved".
• Online only. Cloud variables do not sync in the downloadable Scratch app, and a remix gets its own separate cloud values rather than sharing yours.

Fitting names and scores into 256 digits

The usual approach is to encode each letter as a two-digit number. You keep a list of every allowed character, perhaps abcdefghijklmnopqrstuvwxyz0123456789-_, and replace each letter with its position in that list, padded to two digits. "a" becomes 01, "b" becomes 02, and so on. Since Scratch usernames are 3 to 20 characters long and only use letters, digits, hyphens and underscores, that list covers every possible name.

Now do the arithmetic before designing anything. A 20 character username takes 40 digits. Add a two digit separator so you know where it ends, and a score padded to 6 digits, and one entry costs up to 48 digits. Divide 256 by 48 and you get 5 entries per cloud variable, rounding down.

If you want a top ten, you need two cloud variables. If most of your players have short names, you could pack more in, but then a single long username can push the variable over 256 characters and the whole save fails. I learned that the hard way when someone with an 18 character name took first place on one of our games and silently broke the board for a day.

A simpler design some makers use: store only the scores in one variable and the encoded names in another, so each fits more comfortably. The choice depends on how many entries you want and how long you expect names to be. Whatever you pick, calculate the worst case on paper first.

The overwrite problem nobody warns you about

Here is the part that took me longest to understand. When a player finishes a game, your project reads the leaderboard, inserts the new score in the right place, and writes the whole thing back. If two players finish at nearly the same moment, both read the same old board, both insert their own score, and both write. Whichever write lands second wins. The first player's score disappears.

On a game with a handful of players this almost never happens. On one of our projects that reached the front page, I counted at least four lost scores in a single afternoon from comments alone, and there were probably more that nobody mentioned.

You cannot fully fix this with Scratch's tools, but you can make it rarer:

Read the board again immediately before writing, rather than relying on the copy you loaded when the game started. That shrinks the window from minutes to a fraction of a second.

Only write if the new score actually beats the lowest entry. Most finished games do not make the top ten, so most of the time you skip the write entirely, and there is less to collide.

Wait a random short moment, say between 0.1 and 0.5 seconds, before writing. It spreads out players who finished together.

A cloud leaderboard is a shared notebook with no lock on it. Design as if two people will always try to write on the same line.

Cheating, and what you can do about it

Anyone who understands your encoding can, with some effort, push a fake score. There is no fully secure way to stop this inside Scratch. What does help is the cloud data log. Every project with cloud variables has a log showing which user changed which variable and when. When a suspiciously perfect score appears, check the log. If the account has no plays recorded elsewhere or wrote dozens of times in a minute, you can reset the variable and leave a comment explaining why.

For a beginner project, honestly, that is enough. A leaderboard does not need to be tamper-proof to be fun. If you want to think more about what a scoreboard should reward in the first place, our piece on how leaderboards shape beginner scoring design is a good companion.

Before you build it

Grab a sheet of paper this week and write out the worst-case entry for your game: the longest possible username, encoded, plus the separator, plus the largest score you can imagine. Multiply by how many entries you want. If the total is above 256, split it across variables before writing a single block. Then test with a friend who is a full Scratcher and one who is not, so you see both behaviours. If you are new to Scratch overall, start with our Scratch starting guide, and you can find more project ideas in the games section.