Global Top 100 Leaderboard with OrderedDataStore
ESCOPO
Generate a professional global Top 100 leaderboard system for Roblox using OrderedDataStore. The prompt guides the AI to create a ready-to-integrate server Script, with secure score persistence, global sorting, pagination, and controlled updates to respect DataStore API limits.
Ideal for simulator, obby, RPG, tycoon, racing, or any experience that needs to compare the best player score across all servers. The result should consider the real context of your Explorer, leaderstats, attributes, RemoteEvents, and existing UI models.
The prompt reinforces server-authoritative architecture, data validation, failure handling, retry backoff, result caching, and detailed testing instructions in Roblox Studio, including API Services access setup.
Conteudo
Prompt principal
Act as a senior Roblox Luau developer, specializing in scalable persistence, DataStoreService, and server-authoritative architecture. Create a complete Top 100 global leaderboard system based on OrderedDataStore, adapted to the context of my game provided below. Before writing the code, analyze the context and assume only what is explicitly provided. If an indispensable piece of information is missing, ask at most 5 objective questions before generating the script. If the context is sufficient, generate the implementation directly. Do not invent Explorer paths, RemoteEvents, leaderstats names, models, Frames, or external APIs that I have not provided. When there is an architectural choice, explain it briefly before the code. MY GAME CONTEXT (I will fill in): - Metric that defines the ranking (e.g., Wins, Coins, Time, XP): [PREENCHER] - Where this metric exists and its type (e.g., Player.leaderstats.Wins, IntValue): [PREENCHER] - Can the score decrease? [YES/NO] - Desired name for the OrderedDataStore: [PREENCHER] - Path to the leaderboard template/visual parts in Workspace, if any: [PREENCHER or NONE] - Visual structure available for each ranking row (e.g., Rank, Username, Score): [PREENCHER or NONE] - Desired ranking update interval in seconds: [PREENCHER] - Desired score save interval per player: [PREENCHER] - Existing RemoteEvents/RemoteFunctions and their paths/purposes: [PREENCHER or NONE] - Other rules, such as excluding administrators, minimum score, or number format: [PREENCHER] MANDATORY TYPE AND LOCATION: generate a single server Script to be placed in ServerScriptService, for example named GlobalLeaderboardServer. The script must use DataStoreService and Players. Do not generate a LocalScript as the source of truth for the ranking, do not save data on the client, and do not allow the client to directly provide the score value to be persisted. If there is a physical interface or SurfaceGui already described in the context, the same server Script may update its visual elements; if no interface is defined, expose the Top 100 data only through a clearly documented internal table/structure and explain exactly how to connect a UI later, without inventing assets. SCRIPT TECHNICAL REQUIREMENTS: 1. Use OrderedDataStore correctly to store integer numeric values and obtain the Top 100 with GetSortedAsync in descending order. Use pagination with AdvanceToNextPageAsync when necessary to reach up to 100 entries, without assuming a single page will contain all results. 2. Save the score in a server-authoritative way: read the value directly from the trusted object indicated in the context. Connect relevant changes in the metric to schedule persistence with debounce/dirty flag, avoiding SetAsync on every change. Also save on PlayerRemoving and execute BindToClose with a controlled deadline to attempt to persist pending players. 3. Implement operational protection for DataStore calls: pcall, a limited number of retries, moderate exponential backoff waiting, and clear warn messages on failures. Do not use aggressive loops, frame polling, unnecessary calls, or ignore DataStore request limits. 4. Keep the Top 100 cached in memory and prevent duplicate simultaneous queries with an update lock/flag. Update at a configurable interval, with an initial refresh after the server starts. Handle invalid values, negatives when not allowed, NaN/inf, and missing scores safely. 5. For each UserId returned by the OrderedDataStore, resolve the player's name with Players:GetNameFromUserIdAsync in a protected way and with name cache, reducing repeated calls. If resolution fails, use a readable fallback such as “UserId <id>”. 6. If a SurfaceGui/GUI is provided in the context, update only existing objects, safely clear old lines, and fill in position, name, and score. Preserve templates and do not improperly destroy permanent objects. Format numbers in a readable way (for example, 1.234 or 1.2K) according to the provided rule. 7. If it is necessary to consume an existing RemoteEvent to request a visual update, rigorously validate player, arguments, frequency limits, and permissions on the server. Never accept damage, currency, inventory, or score values from the client. If no Remote is needed, do not create one just for convenience. MANDATORY DELIVERABLE: respond in Brazilian Portuguese. First present a short list of prerequisites and assumed decisions. Then provide the full Luau code, with no pseudocode, inside a single markdown block ```lua. The code must be ready to paste, include useful comments in Portuguese, Luau types when they add clarity, configurable constants at the top, and defensive validations. After the code, include numbered instructions for installation in the Explorer, configuration of Game Settings > Security > Enable Studio Access to API Services for testing, publishing in a test experience, simulating with multiple players, and checking failures in Output. Also explain real limitations: DataStores are not a tool for instant global updates and the ranking may lag due to cache, intervals, and request budget.
