Cronômetro de Obby com Ranking Global e Melhores Tempos
Gere um sistema profissional de corrida para obby com cronômetro individual, validação inteiramente no servidor, detecção de início e chegada, melhor tempo pessoal persistente e ranking global dos jogadores mais rápidos. O resultado é adaptado à estrutura real do seu jogo, usando os nomes e caminhos do Explorer que você informar.
O prompt exige uma implementação segura e pronta para produção, com DataStore protegido por pcall, limites contra spam, prevenção de resultados inválidos e tratamento de jogadores que saem durante a corrida. Também inclui integração opcional com RemoteEvents e uma estratégia para exibir o tempo e o ranking na interface já existente.
É indicado para desenvolvedores de obbies, jogos de parkour e experiências competitivas que precisam de uma base sólida para recordes, speedruns e tabelas de líderes sem confiar em dados enviados pelo cliente.
Atue como um desenvolvedor Roblox sênior especializado em Luau, sistemas multiplayer competitivos, DataStoreService e arquitetura servidor-autoritativa. Crie um sistema completo de cronômetro de conclusão de obby com melhores tempos persistentes e ranking global, adaptado obrigatoriamente ao contexto do meu jogo fornecido abaixo. Antes de escrever o código, leia e considere este contexto. Se algum campo estiver vazio, use nomes padrão razoáveis, declare claramente suas premissas e deixe as configurações centralizadas no início do script para facilitar ajustes: --- CONTEXTO DO MEU JOGO --- - Caminho/nome da peça que inicia a corrida (Start): [COLE AQUI] - Caminho/nome da peça que finaliza a corrida (Finish): [COLE AQUI] - Há checkpoints? Informe pasta, tags ou nomes e como devem influenciar a validação: [COLE AQUI] - Existe leaderboard padrão (leaderstats)? Quais valores já existem?: [COLE AQUI] - RemoteEvents/RemoteFunctions já existentes, com caminho e finalidade: [COLE AQUI] - GUI existente para tempo/ranking, incluindo caminhos dos TextLabels: [COLE AQUI] - Nome do OrderedDataStore desejado, se houver: [COLE AQUI] - Tempo mínimo aceitável para concluir o mapa e regras anti-exploit adicionais: [COLE AQUI] - Desejo ranking global em SurfaceGui/GUI, leaderstats ou ambos?: [COLE AQUI] - Outras regras do obby (teleporte, reset, múltiplos mapas, rounds etc.): [COLE AQUI] --- FIM DO CONTEXTO --- O resultado principal deve ser UM Script de servidor completo, não um LocalScript e não um ModuleScript. Instrua explicitamente que ele deve ser criado como Script e colocado em ServerScriptService, por exemplo com o nome ObbyTimerServer. O script deve funcionar de forma autônoma dentro do possível e usar referências configuráveis aos objetos do Workspace, ReplicatedStorage e demais serviços. Caso o contexto exija UI dinâmica ou atualização por RemoteEvent, o Script de servidor deve expor/integrar os eventos necessários de maneira segura; se for inevitável criar um LocalScript complementar para uma GUI já existente, apresente-o somente em uma seção adicional e separada, explicando o local exato dele. Priorize que toda regra crítica permaneça no servidor. Implemente estes requisitos técnicos: 1. Detectar o toque do personagem na área de início e iniciar uma corrida apenas se o jogador não estiver correndo. Registrar o horário no servidor usando uma fonte de tempo apropriada e manter estado por UserId, nunca por nome do jogador. 2. Detectar a chegada apenas para jogadores com corrida ativa. Calcular o tempo no servidor, rejeitar tempos abaixo do limite configurado, execuções duplicadas, estados inconsistentes e qualquer conclusão sem checkpoint obrigatório, quando aplicável. 3. Criar ou integrar leaderstats com pelo menos BestTime (NumberValue, usando 0 ou valor definido para ausência de recorde) e Wins/Completions, sem sobrescrever valores existentes de forma destrutiva. Escolha nomes compatíveis com o contexto e documente a decisão em comentários. 4. Salvar e carregar o melhor tempo por jogador com DataStoreService. Usar pcall em toda operação de DataStore, tentativas controladas quando apropriado, tratamento de falhas sem apagar dados válidos e salvamento em PlayerRemoving e BindToClose. Não salvar a cada frame nem depender de dados do cliente. 5. Usar OrderedDataStore para registrar somente o melhor tempo válido e permitir ranking global dos tempos mais baixos. Como OrderedDataStore ordena números de forma crescente, explique em comentário a estratégia escolhida. Implemente uma função segura para buscar os Top 10/Top N, convertendo UserIds em nomes com proteção contra falhas e respeitando limites de requisição. 6. Se houver um RemoteEvent para exibir tempo ao jogador ou alimentar interface, o servidor deve enviar apenas dados calculados por ele. Qualquer RemoteEvent recebido deve validar tipo, limites, jogador, estado de corrida e permissões. Nunca confie no cliente para dano, moedas, inventário, vitórias, tempo ou recordes. Não aceite um tempo enviado pelo cliente em hipótese alguma. 7. Tratar CharacterAdded, morte/reset, PlayerRemoving, múltiplos toques rápidos, peças com CanTouch, personagens NPC e jogadores que abandonam a corrida. Não usar loops infinitos pesados nem conexões duplicadas. 8. Adicionar comentários úteis em português, mensagens de aviso claras e uma tabela de configuração no topo com caminhos, DataStore names, tempo mínimo, tamanho do ranking e opções relevantes. Entregue primeiro uma explicação curta da arquitetura e das premissas adotadas. Em seguida, forneça o código Luau integral, sintaticamente válido, dentro de um único bloco markdown exatamente no formato ```lua. Não entregue pseudocódigo, trechos incompletos, "...", dependências ocultas ou código de cliente disfarçado de servidor. Depois do bloco, liste objetos/RemoteEvents que preciso criar manualmente, somente se eles não puderem ser criados ou encontrados pelo Script de forma segura. Finalize com um passo a passo objetivo para testar no Roblox Studio, incluindo habilitar API Services para DataStore em jogo publicado/teste apropriado, testar com dois jogadores via Start Server/Start Player e verificar tentativas de conclusão inválida.