Balanceamento Automático de Times Roblox Luau
ESCOPO
Gere um sistema robusto de balanceamento automático para partidas Roblox, projetado para funcionar de forma autoritativa no servidor. O script distribui jogadores entre equipes, monitora entradas e saídas, evita trocas excessivas e pode considerar limites de capacidade, times espectador/lobby e diferença de habilidade quando houver dados disponíveis.
O prompt solicita o contexto real do seu projeto — estrutura do Explorer, nomes dos objetos Team, atributos, RemoteEvents e regras específicas — antes de produzir um código Luau pronto para colar. É indicado para desenvolvedores que precisam de uma solução escalável e segura para jogos competitivos, cooperativos ou de rounds.
Conteudo
Prompt principal
Atue como um desenvolvedor Roblox sênior, especialista em Luau, arquitetura multiplayer escalável e segurança server-authoritative. Crie um sistema completo de balanceamento automático de times para Roblox, adaptado rigorosamente ao contexto do meu jogo informado abaixo. O resultado principal deve ser UM Script Luau completo, pronto para colar no Roblox Studio. O tipo obrigatório é `Script` (não LocalScript e não ModuleScript), e ele deve ser colocado em `ServerScriptService`. O sistema deve usar o serviço `Teams` e atribuir `Player.Team` e, quando apropriado, `Player.Neutral` exclusivamente no servidor. Não use o cliente como fonte de verdade para definir times, saldo de jogadores, pontuação, dano, moeda, inventário ou elegibilidade de troca. Antes de escrever o código, leia e considere este contexto do meu projeto. Caso algum item esteja ausente, crie valores padrão seguros, concentre-os em uma seção CONFIG no início do script e explique no comentário como alterá-los: [COLE AQUI O CONTEXTO DO MEU JOGO] - Times existentes no serviço Teams: (ex.: Red, Blue, Spectators, Lobby) - Nome exato dos times que participam da partida: - Times que devem ser ignorados no balanceamento: - O jogo usa rounds? Descreva estados, atributos ou Values existentes (ex.: ReplicatedStorage.GameState): - Estrutura relevante do Explorer e caminhos dos objetos: - RemoteEvents/RemoteFunctions já existentes e suas finalidades: - Existe sistema de party/grupo? Onde a informação é armazenada (Attribute, Value, DataStore cache etc.)? - Existe pontuação, MMR, level ou skill? Informe o caminho e o tipo do valor: - Diferença máxima permitida entre os times: - Capacidade máxima por time, se houver: - Jogadores podem escolher time manualmente? Como isso acontece? - Regras especiais de respawn, lobby, espectadores, admins ou modos de jogo: - Versão/recursos Roblox que não devo usar: [FIM DO CONTEXTO] Requisitos funcionais obrigatórios: 1. Ao entrar, cada jogador deve ser alocado no time elegível menos populoso. Em empate, use uma regra imparcial e previsível, como rotação, contador persistente em memória ou sorteio controlado pelo servidor. 2. Rebalanceie ao entrarem ou saírem jogadores, e também forneça uma função pública/local bem nomeada para o servidor chamar ao início/fim de round ou após mudanças de estado. 3. Nunca mova jogadores de times ignorados, lobby ou espectador, salvo se a configuração permitir explicitamente. 4. Só realize uma troca se ela reduzir de fato o desequilíbrio e respeitar capacidade máxima, proteções de round e critérios de elegibilidade. 5. Implemente cooldown por jogador e intervalo global de rebalanceamento para evitar troca repetitiva, flickering e exploração de eventos rápidos. 6. Se houver dados de MMR/skill válidos no contexto, priorize uma distribuição que reduza a diferença total de habilidade sem violar a diferença de quantidade. Se não houver, use exclusivamente a contagem de jogadores. 7. Se houver party, não separe membros da mesma party quando isso for possível; caso seja matematicamente impossível, priorize a estabilidade e documente a decisão no código. 8. Preserve jogadores sem Character carregado e não dependa de Humanoid, SpawnLocation ou GUI para a lógica central. A atribuição de time deve funcionar independentemente do respawn. 9. Trate com segurança times ausentes, valores inválidos, jogadores removidos durante a operação, zero times elegíveis e erro de configuração. Use `warn()` com mensagens úteis, sem interromper o servidor desnecessariamente. 10. Não crie RemoteEvents novos sem necessidade. Se o contexto trouxer RemoteEvents para pedido manual de troca, o servidor deve validar integralmente o jogador, o estado do round, alvo permitido, capacidade, cooldown e toda elegibilidade antes de alterar qualquer time. Nunca confie em argumentos enviados pelo cliente. Estruture o código com CONFIG claramente tipada quando fizer sentido, funções pequenas e legíveis, comentários profissionais em português, conexões de eventos organizadas e limpeza de conexões/estado quando aplicável. Evite loops infinitos com `while true do` para polling; prefira `Players.PlayerAdded`, `Players.PlayerRemoving`, alterações relevantes de estado e agendamento controlado com `task.delay`. Não use APIs obsoletas. Não dependa de plugins ou módulos externos. Entregue a resposta nesta ordem: (1) uma breve lista de premissas adotadas a partir do contexto; (2) o caminho exato no Explorer e o tipo do script; (3) o código integral em um único bloco Markdown ` ```lua `, sem pseudocódigo, sem trechos omitidos e com comentários; (4) instruções objetivas para testar em modo Play com múltiplos clientes no Roblox Studio, incluindo casos de entrada, saída, empate, capacidade, lobby/espectador, cooldown e party/MMR se configurados; (5) uma lista curta de parâmetros CONFIG que devo ajustar. Não entregue código de cliente, a menos que eu tenha informado explicitamente um RemoteEvent manual que exija integração e você explique que a validação continua no servidor.