Sistema de Rodadas, Times e Vitória para Roblox
ESCOPO
Gere um sistema de rodadas robusto para experiências Roblox competitivas, cooperativas ou de sobrevivência. O resultado prioriza lógica no servidor, transições de estado previsíveis e validação para impedir que o cliente controle tempo, placar, vencedor ou recompensas.
O prompt orienta a IA a adaptar o código à hierarquia real do seu projeto: objetos no Explorer, Teams, SpawnLocations, RemoteEvents e regras específicas de vitória. É ideal para desenvolvedores que precisam de uma base pronta para colar no ServerScriptService, com comentários, tratamento de casos extremos e instruções práticas de teste.
O sistema pode suportar intermissão, mínimo de jogadores, distribuição equilibrada de participantes em times, contagem regressiva, detecção de jogadores vivos, vitória por eliminação ou fim de tempo, limpeza da rodada e preparação automática da próxima partida.
Conteudo
Prompt principal
Atue como um desenvolvedor Roblox sênior especializado em Luau, arquitetura cliente-servidor, segurança multiplayer e sistemas de rodada escaláveis. Crie um Script de servidor completo para um sistema de rodadas com intermissão, times, timer e condição de vitória, adaptado estritamente ao contexto do meu jogo abaixo. O resultado principal deve ser exatamente um **Script** (não LocalScript e não ModuleScript), feito para ser colocado em **ServerScriptService**. Ele deve conter toda a lógica autoritativa da partida: estados da rodada, contagem de tempo, alocação de times, monitoramento de jogadores ativos, apuração de vitória, encerramento, limpeza e preparação para a próxima rodada. Não delegue ao cliente decisões de gameplay. Caso meu projeto já possua RemoteEvents para interface, use-os apenas para notificar clientes sobre estado, tempo e vencedor; nunca aceite do cliente informações que definam dano, eliminações, time, moeda, inventário, vencedor ou término de rodada. Antes de escrever o código, interprete e respeite o contexto que vou preencher. Se algum item indispensável estiver ausente ou ambíguo, faça no máximo 5 perguntas objetivas antes de gerar o script. Se houver informações suficientes, não faça perguntas e entregue o código diretamente. CONTEXTO DO MEU JOGO (vou preencher): - Nome do Folder/Model principal de mapas e como selecionar mapa: [PREENCHER] - Existem mapas por rodada? Local dos spawns por time dentro do mapa: [PREENCHER] - Nomes exatos dos objetos Team no serviço Teams: [PREENCHER] - Modo de alocação dos times (balanceado, aleatório, escolhido previamente etc.): [PREENCHER] - Jogadores mínimos para iniciar: [PREENCHER] - Duração da intermissão em segundos: [PREENCHER] - Duração máxima da rodada em segundos: [PREENCHER] - Regra de vitória (último time vivo, maior pontuação, objetivo, empate por tempo etc.): [PREENCHER] - Comportamento ao acabar o tempo: [PREENCHER] - Jogadores que entrarem no meio da partida (espectador, próximo round, time específico): [PREENCHER] - Política para jogador que morrer (eliminado, respawn como espectador, respawn normal etc.): [PREENCHER] - RemoteEvents/RemoteFunctions existentes e respectivos caminhos no Explorer: [PREENCHER] - Elementos de UI que devem receber atualizações e formato esperado dos dados: [PREENCHER] - Recompensas de vitória/participação, caso existam: [PREENCHER] - Outros scripts que este sistema não pode duplicar ou conflitar: [PREENCHER] Implemente uma máquina de estados explícita e legível, preferencialmente com estados como WAITING_FOR_PLAYERS, INTERMISSION, STARTING, IN_ROUND e ROUND_ENDING. Use variáveis de configuração no topo do script para valores que possam ser alterados facilmente. O timer deve ser controlado exclusivamente pelo servidor, reduzir em intervalos consistentes e nunca criar múltiplos loops concorrentes quando jogadores entram, saem ou quando uma rodada termina. Garanta que uma nova rodada somente comece após a anterior ser completamente finalizada. Gerencie corretamente PlayerAdded, PlayerRemoving e CharacterAdded. Ao iniciar uma rodada, determine uma lista fixa de participantes elegíveis, distribua-os entre os times conforme a regra fornecida, carregue personagens quando necessário e teleporte cada jogador usando SpawnLocation ou BasePart configurada, com verificações para objetos inexistentes, personagens sem HumanoidRootPart e personagens ainda carregando. Conecte Humanoid.Died apenas para participantes da rodada atual e desconecte/neutralize conexões antigas para evitar vazamentos e mortes de rodadas anteriores afetarem a rodada atual. A condição de vitória deve ser recalculada no servidor após mortes, saídas de jogadores e eventos relevantes. Trate casos extremos: um jogador sai quando seu time é o último vivo, não há jogadores suficientes durante a intermissão, todos morrem simultaneamente, apenas um time possui participantes, partidas com empate e jogadores entrando após a lista de participantes ser bloqueada. Não use waits indefinidos; prefira task.wait, task.spawn e verificações de estado/identificador único da rodada para impedir rotinas obsoletas. Se eu fornecer RemoteEvents de UI, valide sua existência com WaitForChild de tempo limitado ou checagens defensivas e envie dados mínimos, por exemplo: estado atual, segundos restantes, times vivos e mensagem de resultado. Não crie RemoteEvents automaticamente sem minha autorização. Não use DataStore, HTTPService, require remoto, loadstring ou código dependente de plugins. Entregue sua resposta nesta estrutura: 1) breve resumo das premissas adotadas; 2) uma seção com o caminho obrigatório no Explorer: ServerScriptService > [nome sugerido do Script]; 3) o código Luau integral, pronto para colar, dentro de um único bloco markdown ```lua, com comentários úteis e tipagem Luau quando ela aumentar a segurança/clareza; 4) instruções objetivas para configurar objetos necessários e testar no Roblox Studio com Test > Start Server e múltiplos Players. Não entregue pseudocódigo, trechos incompletos ou dependências ocultas.