Sistema Avançado de Votação de Mapas entre Rodadas
ESCOPO
Gere uma implementação robusta de votação de mapas entre rodadas para experiências Roblox competitivas, cooperativas ou de minigames. O prompt orienta a IA a analisar a estrutura real do seu Explorer, adaptar nomes de RemoteEvents, pastas e interfaces existentes, e entregar arquivos Luau prontos para uso.
O sistema solicitado segue arquitetura servidor-autoritativa: o servidor escolhe candidatos, controla o tempo, valida votos, impede duplicidade e decide o mapa vencedor. Também contempla atualização visual para jogadores, tratamento de empate, jogadores entrando ou saindo durante a votação e integração segura com o carregamento da próxima rodada.
É indicado para desenvolvedores que já possuem, ou desejam estruturar, um loop de partidas profissional e precisam evitar falhas comuns como confiar no cliente para registrar votos, selecionar mapas ou determinar resultados.
Conteudo
Prompt principal
Atue como um desenvolvedor Roblox sênior, especializado em Luau, sistemas multiplayer servidor-autoritativos e arquitetura escalável para ciclos de rodada. Desenvolva um sistema completo de votação de mapas entre rodadas, adaptado estritamente ao contexto do meu jogo que será informado abaixo. Antes de escrever o código, leia e use as informações do bloco CONTEXTO DO PROJETO. Caso algum dado indispensável esteja ausente, não invente uma estrutura incompatível: declare de forma objetiva suas suposições no início da resposta e use nomes configuráveis concentrados no topo dos scripts. Meu objetivo é receber arquivos Luau completos, prontos para colar no Roblox Studio, e não pseudocódigo nem trechos incompletos. CONTEXTO DO PROJETO — vou preencher antes de enviar: - Estrutura de mapas: [ex.: ServerStorage/Maps, cada mapa é Model] - Onde o mapa ativo deve ser clonado: [ex.: Workspace/ActiveMap] - Sistema/objeto que inicia a próxima rodada: [nome, caminho e API/BindableEvent, se existir] - Duração da votação em segundos: [valor] - Quantidade de mapas candidatos: [valor] - RemoteEvents/RemoteFunctions existentes e respectivos caminhos: [listar] - Interface existente de votação e hierarquia dos elementos: [ScreenGui, Frames, botões, labels etc.] - Se a UI ainda não existe: [sim/não] - Regras de desempate desejadas: [aleatório entre empatados / ordem / outra] - Restrições especiais: [mapas bloqueados, mínimo de jogadores, gamepass, modo de teste etc.] Entregue uma solução composta obrigatoriamente por estes arquivos, deixando explícito o tipo e o local de cada um no Explorer: 1. Um Script de servidor em ServerScriptService, por exemplo MapVotingServer.server.lua. Ele deve ser a autoridade total da votação. 2. Um LocalScript em StarterPlayer/StarterPlayerScripts ou dentro da ScreenGui em StarterGui, escolhendo o local mais apropriado conforme a UI informada. Ele deve apenas renderizar estado, enviar a intenção de voto e nunca decidir resultado. 3. Caso necessário para organização, um ModuleScript de configuração em ReplicatedStorage, por exemplo MapVotingConfig. Só o inclua se trouxer benefício real; se incluí-lo, entregue o arquivo inteiro. O Script do servidor deve: localizar e validar pastas/instâncias com WaitForChild usando timeout e mensagens de erro úteis; selecionar candidatos sem repetição e somente entre mapas válidos; iniciar, sincronizar e encerrar uma contagem regressiva; enviar o estado inicial e atualizações para todos os jogadores; aceitar um voto por jogador, mas permitir troca de voto durante a janela; remover corretamente votos de jogadores que saírem; calcular contagens no servidor; resolver empate conforme a regra informada; escolher o vencedor exclusivamente no servidor; e expor uma integração clara para que o loop de rodadas carregue o mapa vencedor. Se não houver jogadores, candidatos suficientes ou votos, implemente um fallback previsível e documentado. A segurança é obrigatória. Todo dado recebido de RemoteEvent ou RemoteFunction deve ser validado no servidor: confirme que o jogador é válido, que a votação está ativa, que o identificador do mapa é permitido para aquela rodada e que não há payloads inesperados. Não aceite do cliente contagem de votos, nome de vencedor, tempo restante, dano, moeda, inventário ou qualquer decisão crítica. A lista de candidatos e o vencedor devem existir apenas no servidor. Use RemoteEvents com contratos simples e documentados; se os Remotes não existirem no contexto, crie-os com segurança em ReplicatedStorage/Remotes no Script do servidor, sem duplicá-los. No LocalScript, implemente atualização responsiva dos botões, votos exibidos, mapa atualmente selecionado, estado desabilitado após encerramento e sincronização para jogador que entrar no meio da votação. Se a UI não existir, crie uma UI simples por código com três opções configuráveis, labels de votos e contador, sem depender de assets externos. Se ela existir, adapte-se aos caminhos exatos fornecidos e não recrie componentes desnecessariamente. Faça debounce local apenas para experiência do usuário, mas deixe claro em comentários que a proteção real está no servidor. Requisitos de qualidade: use Luau moderno, --!strict quando compatível, tipos quando melhorarem segurança, nomes descritivos, comentários úteis e conexões desconectáveis quando aplicável. Evite loops infinitos desnecessários, polling excessivo, globals, require não confiável, loadstring e APIs obsoletas. Preserve compatibilidade multiplayer e tratamento de jogadores entrando/saindo. Não use DataStore, HTTPService ou sistemas de moeda a menos que o contexto peça explicitamente. Formate a resposta final nesta ordem: (1) breve resumo das suposições e da arquitetura; (2) árvore de instalação no Explorer; (3) cada arquivo completo em seu próprio bloco markdown identificado, obrigatoriamente usando ```lua; (4) explicação objetiva do contrato de cada RemoteEvent; e (5) passos detalhados para testar no Roblox Studio, incluindo Test > Start Server com múltiplos Players, troca de voto, empate, entrada tardia, saída durante votação e ausência de votos. Não omita nenhum arquivo necessário e não entregue código parcial.
