Roblox Auto-Save with BindToClose and Secure DataStore
ESCOPO
Generate a robust persistence system for Roblox that saves player data at periodic intervals, when they leave the server, and during instance shutdown. The prompt requires proper DataStoreService practices, including UpdateAsync, exponential backoff retries, dirty-state tracking, and prevention of concurrent saves for the same player.
Ideal for games with coins, levels, inventory, stats, or persistent progression. The result is aimed at a ready-to-use server Script for ServerScriptService, but it considers the real project context — such as data structure, folders, attributes, Values, modules, and RemoteEvents already in place — that the developer can provide before generating the code.
Conteudo
Prompt principal
Act as a senior Roblox developer specialized in Luau, DataStoreService, server-authoritative architecture, and persistence reliability. Generate a single complete server Script for a periodic auto-save system with saving in PlayerRemoving and shutdown protection using game:BindToClose(). Before writing the code, use the context below. If any field is empty, adopt a safe and configurable solution, briefly document the assumption, and do not invent unnecessary RemoteEvents or structures. === MY GAME CONTEXT (FILL IN) === - DataStore name: [e.g.: PlayerData_v1] - Data structure to save: [e.g.: leaderstats.Coins, leaderstats.Level, Inventory folder, Player attributes, etc.] - Where the data lives at runtime: [full paths in the Explorer] - Default values for a new player: [describe table/values] - Desired auto-save interval in seconds: [e.g.: 120] - Is there a data loading system? [yes/no; script/module path and returned format] - Is there an existing saving system? [yes/no; path and available APIs] - Existing RemoteEvents/RemoteFunctions related to data: [list paths and purpose] - Special data rules: [non-serializable items, limits, migrations, versions, optional data] - Names of relevant objects/folders in the Explorer: [list] === END CONTEXT === The script type must be a server Script, placed in ServerScriptService. Do not generate a LocalScript, ModuleScript, or multiple files, unless the context indicates that there is already a required data module; in that case, keep this result as a single Script that integrates with it. The code must be ready to paste into Roblox Studio and must contain useful comments in Portuguese. Implement a professional system with these requirements: 1. Use DataStoreService and a configurable DataStore at the top of the file. Persist with UpdateAsync, never SetAsync as the main strategy, to reduce overwrite risk between servers and allow safe merging when applicable. 2. Include a central function SavePlayer(player, reason), where reason identifies at least "AutoSave", "PlayerRemoving", and "BindToClose". It must collect and validate server data before persisting. 3. Do not trust the client for currency, inventory, level, damage, or any persistent data. This system must not accept a save payload sent by RemoteEvent/RemoteFunction. If the context mentions existing remotes, make it explicit in comments that they cannot authorize direct saving and that any state change must be validated on the server. 4. Implement per-player control to prevent two simultaneous save operations. Use a state table with, at minimum, flags for saving in progress, "dirty"/changed state, and pending attempts. If a change occurs while a save is in progress, ensure the player remains marked for a later new save. 5. Implement retries for transient DataStore failures with pcall, a configurable maximum number of attempts, and limited exponential backoff. Log clear warnings with warn, including UserId, reason, and attempt number, without exposing unnecessary sensitive data. 6. Create a periodic loop using task.spawn/task.wait that iterates through connected players and saves only players marked as dirty. If the project does not provide a mechanism for detecting changes, include a MarkDirty(player) function in the code itself and connect safe examples to Changed/AttributeChanged only for objects that exist in the context. Avoid a generic and expensive connection on DescendantAdded for the entire Player. 7. Connect Players.PlayerRemoving to attempt to save the player who is leaving. After the attempt, clean up associated references and connections carefully, without destroying data before confirmation or without explaining the behavior in case of failure. 8. Use game:BindToClose() to initiate the final save of all still-connected players. During shutdown, avoid starting duplicate saves, attempt to save in parallel with a configurable concurrency limit or in a safe way, and wait only for a maximum configurable time, respecting Roblox's practical shutdown limit. Do not use infinite waiting. Explain in comments that BindToClose reduces data loss, but does not guarantee absolute persistence in abrupt crashes. 9. Ensure DataStore-compatible serialization: only numbers, strings, booleans, and simple tables. Validate types, handle nil, and avoid saving Instances, functions, userdata, or object references. If the context includes inventory, explicitly convert it to a stable serializable table. 10. Organize configurable constants at the beginning: DATASTORE_NAME, AUTOSAVE_INTERVAL, MAX_RETRIES, RETRY_BASE_DELAY, SHUTDOWN_TIMEOUT, and, if used, MAX_CONCURRENT_SHUTDOWN_SAVES. Include defensive validations and maintenance comments. Deliver the response in this order: first, a short list of assumptions made based on the context; then the full code in exactly one markdown block identified as ```lua; finally, objective instructions for installing and testing in Roblox Studio. In the testing instructions, include how to enable API Services in Game Settings > Security, how to test with Start Server/Start Player, how to check Output, how to simulate player leaving, and how to test server shutdown. Do not omit any part of the code, do not use pseudocode, and do not leave placeholders like "complete here".
