Roblox Checkpoints with Respawn at the Last Saved Point

# www.prompthubai.com.br
# Encontre prompts, agentes e workflows testados para vender, programar e automatizar com IA em português.

# Roblox Checkpoints with Respawn at the Last Saved Point

## Cabecalho
- Tipo: Conteudo
- Categoria: Games
- Modulos: 0
- Agentes: 0

## Escopo
Generate a professional checkpoint system for Roblox in which the player activates progress points and respawns automatically at the last valid checkpoint after dying or rejoining the game. The prompt guides the AI to adapt the code to the real names of folders, parts, tags, RemoteEvents, and conventions in your project.

The solution requires server-authoritative architecture, progress validation, protection against unauthorized activations, per-player debounce, CharacterAdded handling, and compatibility with checkpoints based on Parts, SpawnLocations, or CollectionService. It also includes optional persistence with DataStore, without trusting the client to define positions or progress.

Ideal for obbies, platform games, adventure maps, stage races, and experiences with linear or branching progress. The requested result is a complete, commented Luau Script ready to paste into Roblox Studio, along with installation and testing instructions.

## Prompt Principal
Act as a senior Roblox Luau developer, specialized in secure multiplayer systems, data persistence, and server-authoritative architecture. Create a complete checkpoint system with automatic respawn at the last saved point, adapted to the context of my game that I will provide below.

Before writing the code, analyze the information in "MY GAME CONTEXT". If there is any missing information that prevents a safe or functional implementation, assume a reasonable convention, state that assumption briefly before the code, and keep the settings concentrated at the beginning of the script for easy editing. Do not ask questions back: deliver a functional and parameterizable solution.

MY GAME CONTEXT (I will fill in):
- Checkpoint location in Explorer: [e.g., Workspace/Checkpoints]
- Checkpoint type: [Part, MeshPart, SpawnLocation, or model with an internal Part]
- Identification method: [e.g., Attribute "CheckpointId", numeric name, CollectionService tag "Checkpoint"]
- Expected order/progression: [linear, free, only allow checkpoint with higher index, branched]
- Initial/fallback spawn point: [Explorer path or description]
- Do I want to save between sessions with DataStore? [yes/no]
- DataStore name, if applicable: [e.g., PlayerCheckpoint_v1]
- Existing RemoteEvents/RemoteFunctions and their paths: [list or "none"]
- Special rules: [e.g., reset progress when completing map, teleport between phases, teams, VIP, etc.]
- Game version/API or architecture constraints: [optional]

Deliver specifically ONE server Script (Script type), to be placed in ServerScriptService, for example in `ServerScriptService/CheckpointService`. Do not create a LocalScript as a requirement for the system to work. The system must operate entirely on the server; touch detection, validation, checkpoint registration, progress loading, and teleport/respawn must be controlled by the server. If I list existing RemoteEvents, use them only when truly necessary and rigorously validate any data that may come from the client. Never allow a client to freely report checkpoint, CFrame, currency, damage, inventory, or progress.

The script must implement these technical requirements:
1. Discover checkpoints by the method indicated in the context, with configurable fallback and validation to ignore invalid objects.
2. Associate each checkpoint with a stable and comparable ID. For linear progress, prevent regression or activation of IDs outside the configured rules. Do not infer progress by trusting values sent by the client.
3. Detect the player correctly when touching the checkpoint, accepting character parts and ignoring NPCs, accessories, tools, and irrelevant collisions.
4. Use debounce per player and per checkpoint, avoiding multiple `Touched` activations, log spam, excessive DataStore writes, and race conditions.
5. Keep the current checkpoint in server memory during the session. If DataStore is enabled, load the data in `Players.PlayerAdded`, validate its type/range/ID, and save with `UpdateAsync` in a protected way using `pcall` at appropriate moments. Do not write to DataStore every frame or depend on `PlayerRemoving` as the only chance to save.
6. In `CharacterAdded`, robustly wait for `HumanoidRootPart` and position the character at the last valid checkpoint with `Model:PivotTo()` or an equivalent technique. Correctly handle the first spawn, deaths, late character loading, and checkpoint removed/renamed during the session.
7. Respect Roblox’s default respawn behavior. Do not disable `CharacterAutoLoads` unless necessary. Respawn must happen automatically after death according to the normal Players configuration, and the script must reposition the new character at the saved checkpoint.
8. Apply a configurable vertical offset and, if necessary, preserve the checkpoint orientation to prevent the player from spawning inside the part or falling immediately.
9. Include cleanup of session connections/tables in `PlayerRemoving`, saving in `BindToClose` when DataStore is enabled, and useful `warn` messages for invalid configuration, without exposing sensitive data.
10. Do not use deprecated APIs, `wait()`, unnecessary infinite loops, or client code for critical decisions.

First provide a short list of assumptions and the expected Explorer structure. Then deliver the full Luau code, ready to paste, required inside a single markdown block identified as `lua`. Comment the code clearly and professionally, especially the CONFIGURATION area, checkpoint validation, DataStore flow, and respawn teleport. Do not deliver pseudocode, incomplete snippets, fictitious modules, or placeholders that prevent execution.

After the code block, explain objectively: (1) where to create/configure the checkpoints and which Attributes/tags to use; (2) how to enable and test DataStore in Roblox Studio, including API Services only if necessary; (3) a multiplayer test plan using Start Server and simulated players; and (4) how to validate death, respawn, re-entry into the game, invalid checkpoint, and out-of-order activation attempts. If a decision depends on the context I left blank, highlight exactly which variable in the CONFIGURATION section I should change.