Refresh leaderstats, saving with DataStores, and the rule that the server decides — before you build your first real game systems.
The data section gave your game a memory and a spine: a leaderboard that shows stats, DataStores that remember between visits, and a security rule that keeps the economy honest. That last one — the server decides — is what everything you build next stands on. Quick lap:
A folder literally named leaderstats inside each player is the recipe. Children like Coins (a NumberValue) show up at the top-right, and changing Value updates the board live. It's created inside PlayerAdded, when the player object exists.
Where is the leaderstats folder created?
Saving is a dance: on join, GetAsync(player.UserId) pulls the saved value — defaulting brand-new players with or 0. On leave, SetAsync(player.UserId, coins) writes it back. And an autosave loop backs it up so a crash can't wipe progress.
LocalScripts run on the player's own computer — so anything they can do, an exploiter can do. The rule that fixes it: the server is the only thing that changes real data. Clients can only request.
A client fires a RemoteEvent asking for coins. What decides whether they get them?
RemoteEvents are the phone line: the client reports with :FireServer(), the server decides in OnServerEvent, and sends updates back with :FireClient(player, ...). The client never hands itself rewards — it reports, and the server decides what the action was worth.
What does the first argument of an OnServerEvent callback give you?
Data, memory, and trust are in place. Next section, you build your first actual game on top of them — the clicker, the shop, and the systems that tie it together.
