Checkpoints Roblox com Respawn no Último Ponto Salvo
ESCOPO
Gere um sistema profissional de checkpoints para Roblox em que o jogador ativa pontos de progresso e renasce automaticamente no último checkpoint válido após morrer ou entrar novamente no jogo. O prompt orienta a IA a adaptar o código aos nomes reais de pastas, peças, tags, RemoteEvents e convenções do seu projeto.
A solução exige arquitetura autoritativa no servidor, validação de progresso, proteção contra ativações indevidas, debounce por jogador, tratamento de CharacterAdded e compatibilidade com checkpoints baseados em Parts, SpawnLocations ou CollectionService. Também contempla persistência opcional com DataStore, sem confiar no cliente para definir posições ou progresso.
Ideal para obbies, jogos de plataforma, mapas de aventura, corridas por estágios e experiências com progresso linear ou ramificado. O resultado solicitado é um Script Luau completo, comentado e pronto para colar no Roblox Studio, acompanhado de instruções de instalação e testes.
Conteudo
Prompt principal
Atue como um desenvolvedor Roblox Luau sênior, especializado em sistemas multiplayer seguros, persistência de dados e arquitetura server-authoritative. Crie um sistema completo de checkpoints com respawn automático no último ponto salvo, adaptado ao contexto do meu jogo que fornecerei abaixo. Antes de escrever o código, analise as informações em "CONTEXTO DO MEU JOGO". Se houver alguma informação ausente que impeça uma implementação segura ou funcional, assuma uma convenção razoável, declare essa suposição de forma curta antes do código e mantenha as configurações concentradas no início do script para fácil alteração. Não faça perguntas de volta: entregue uma solução funcional e parametrizável. CONTEXTO DO MEU JOGO (vou preencher): - Local dos checkpoints no Explorer: [ex.: Workspace/Checkpoints] - Tipo dos checkpoints: [Part, MeshPart, SpawnLocation ou modelo com uma Part interna] - Método de identificação: [ex.: Attribute "CheckpointId", nome numérico, tag CollectionService "Checkpoint"] - Ordem/progressão esperada: [linear, livre, somente permitir checkpoint de índice maior, ramificada] - Ponto de spawn inicial/fallback: [caminho no Explorer ou descrição] - Quero salvar entre sessões com DataStore? [sim/não] - Nome do DataStore, se aplicável: [ex.: PlayerCheckpoint_v1] - RemoteEvents/RemoteFunctions já existentes e seus caminhos: [liste ou "nenhum"] - Regras especiais: [ex.: resetar progresso ao concluir mapa, teleporte entre fases, equipes, VIP, etc.] - Versão/API do jogo ou restrições de arquitetura: [opcional] Entregue especificamente UM Script de servidor (tipo Script), para ser colocado em ServerScriptService, por exemplo em `ServerScriptService/CheckpointService`. Não crie LocalScript como requisito do funcionamento. O sistema deve funcionar integralmente no servidor; a detecção de toque, validação, registro do checkpoint, carregamento de progresso e teleporte/respawn devem ser controlados pelo servidor. Se eu listar RemoteEvents existentes, use-os apenas quando forem realmente necessários e valide rigorosamente qualquer dado que possa vir do cliente. Nunca permita que um cliente informe livremente checkpoint, CFrame, moeda, dano, inventário ou progresso. O script deve implementar estes requisitos técnicos: 1. Descobrir checkpoints pelo método informado no contexto, com fallback configurável e validação para ignorar objetos inválidos. 2. Associar cada checkpoint a um ID estável e comparável. Para progresso linear, impedir regressão ou ativação de IDs fora das regras configuradas. Não deduza progresso confiando em valores enviados por cliente. 3. Detectar o jogador corretamente ao tocar o checkpoint, aceitando partes do personagem e ignorando NPCs, acessórios, ferramentas e colisões irrelevantes. 4. Usar debounce por jogador e por checkpoint, evitando múltiplas ativações por `Touched`, spam de logs, escrita excessiva em DataStore e condições de corrida. 5. Guardar o checkpoint atual em memória no servidor durante a sessão. Se DataStore estiver ativado, carregar o dado em `Players.PlayerAdded`, validar seu tipo/faixa/ID e salvar com `UpdateAsync` de maneira protegida por `pcall` em momentos apropriados. Não faça uma escrita no DataStore a cada frame nem dependa de `PlayerRemoving` como única chance de salvar. 6. No `CharacterAdded`, aguardar de forma robusta o `HumanoidRootPart` e posicionar o personagem no último checkpoint válido com `Model:PivotTo()` ou técnica equivalente. Tratar corretamente o primeiro spawn, mortes, carregamento tardio de personagem e checkpoint removido/renomeado durante a sessão. 7. Respeitar o respawn padrão do Roblox. Não desabilitar `CharacterAutoLoads` sem necessidade. O respawn deve acontecer automaticamente após a morte conforme a configuração normal de Players, e o script deve reposicionar o novo personagem no checkpoint salvo. 8. Aplicar offset vertical configurável e, se necessário, preservar orientação do checkpoint para evitar o jogador nascer dentro da peça ou cair imediatamente. 9. Incluir limpeza de conexões/tabelas de sessão em `PlayerRemoving`, salvamento em `BindToClose` quando DataStore estiver ativo e avisos (`warn`) úteis para configuração inválida, sem expor dados sensíveis. 10. Não usar APIs obsoletas, `wait()`, loops infinitos desnecessários, nem código cliente para decisões críticas. Forneça primeiro uma lista curta de suposições e a estrutura esperada no Explorer. Em seguida, entregue o código Luau integral, pronto para colar, obrigatoriamente dentro de um único bloco markdown identificado como `lua`. Comente o código de forma clara e profissional, especialmente a área de CONFIGURAÇÃO, a validação de checkpoints, o fluxo de DataStore e o teleporte no respawn. Não entregue pseudocódigo, trechos incompletos, módulos fictícios ou placeholders que impeçam a execução. Depois do bloco de código, explique objetivamente: (1) onde criar/configurar os checkpoints e quais Attributes/tags usar; (2) como ativar e testar DataStore no Roblox Studio, incluindo API Services apenas se necessário; (3) um roteiro de teste multiplayer usando Start Server e jogadores simulados; e (4) como validar morte, respawn, reentrada no jogo, checkpoint inválido e tentativa de ativação fora da ordem. Se uma decisão depender do contexto que deixei em branco, destaque exatamente qual variável da seção CONFIGURAÇÃO devo alterar.
