Painel Admin Roblox Seguro: Kick, Ban, Teleport e Itens
ESCOPO
Gere uma arquitetura completa de painel administrativo para Roblox, voltada a experiências que precisam de moderação segura e controle operacional em tempo real. O sistema inclui comandos de kick, banimento persistente com DataStore, teleporte de jogadores e concessão de itens, com permissões restritas a administradores configurados por UserId ou cargo/grupo.
O prompt exige uma implementação profissional com separação entre interface do cliente e autoridade do servidor. Todo comando solicitado pelo painel é validado novamente no servidor, impedindo que exploiters usem RemoteEvents para banir usuários, obter itens ou executar ações administrativas sem autorização.
Ideal para desenvolvedores que querem receber código Luau pronto para organizar e colar no Roblox Studio, mas precisam adaptar o resultado à estrutura real do próprio jogo, como nomes de pastas, ferramentas, RemoteEvents existentes, sistema de inventário e locais de teleporte.
Conteudo
Prompt principal
Atue como um desenvolvedor Roblox Luau sênior, especializado em sistemas multiplayer seguros, UI escalável e arquitetura cliente-servidor no Roblox Studio. Crie um sistema completo de Painel de Administração para meu jogo Roblox, com comandos de kick, ban persistente, teleport e dar item, pronto para ser integrado no Roblox Studio. Antes de escrever o código, analise o contexto abaixo e use exatamente os nomes de objetos, caminhos do Explorer, APIs internas e convenções que eu informar. Se algum dado indispensável estiver ausente, não invente uma integração específica: declare uma suposição objetiva, isole-a em uma seção CONFIG e explique como substituir. Contexto do meu jogo (vou preencher): - Administradores autorizados (UserIds, grupo/rank ou ambos): [COLE AQUI] - Estrutura atual do Explorer: [COLE AQUI] - RemoteEvents/RemoteFunctions já existentes e seus caminhos: [COLE AQUI] - Sistema de itens/inventário e local dos Tools ou função para concedê-los: [COLE AQUI] - Teleportes permitidos (SpawnLocations, Parts, PlaceIds ou sistema próprio): [COLE AQUI] - Política de banimento e mensagem padrão: [COLE AQUI] - Nome, tema e comportamento esperado da interface: [COLE AQUI] Implemente a solução em camadas, entregando TODOS os arquivos necessários, não apenas trechos isolados. A arquitetura mínima deve conter: (1) um Script servidor em ServerScriptService chamado AdminService, responsável por autorização, processamento de comandos, DataStore de bans, auditoria e validação; (2) um LocalScript em StarterPlayer > StarterPlayerScripts ou dentro da ScreenGui do painel em StarterGui, chamado AdminPanelClient, responsável apenas pela interface e envio de solicitações; e (3) um ModuleScript em ReplicatedStorage chamado AdminConfig, com a configuração centralizada de admins, limites, catálogo permitido de itens e destinos de teleporte. Caso necessário, crie e descreva os RemoteEvents em ReplicatedStorage > AdminRemotes, preferencialmente AdminCommandRequest e AdminCommandResult. Não permita que o cliente crie, escolha livremente ou execute ações privilegiadas. O painel deve permitir selecionar ou informar o jogador-alvo por nome de usuário/display name, mostrar lista de jogadores online, escolher a ação, preencher motivo e parâmetros aplicáveis. Implemente os comandos: kick (com motivo sanitizado), ban (persistente por UserId via DataStoreService, com motivo, autor, data e opção de duração temporária se viável), teleport (somente para destinos pré-aprovados na configuração) e dar item (somente itens explicitamente presentes em uma whitelist da configuração). Ao jogador banido, bloqueie a entrada usando Players.PlayerAdded e aplique Kick com mensagem apropriada. Se DataStore falhar, trate com pcall, registre warn detalhado no servidor e adote uma política segura explicada no código, sem permitir corrupção silenciosa de dados. A segurança é requisito obrigatório: o servidor deve ser totalmente autoritativo. Valide no servidor o remetente do RemoteEvent, a permissão administrativa atual, o alvo, o tipo de comando, os campos obrigatórios, tamanho máximo de strings, caracteres perigosos, existência do item/destino e rate limit por administrador. Nunca confie no cliente para definir dano, moeda, inventário, permissões, UserId de autor ou resultado da ação. Não aceite nomes de Tools ou CFrames arbitrários enviados pelo cliente. Use UserId para dados persistentes e autorização. Impessa que administradores executem ações sobre usuários com nível de permissão igual ou superior, quando essa regra estiver habilitada na configuração. Use RemoteEvent:FireServer apenas no cliente e OnServerEvent apenas no servidor, com argumentos mínimos e estruturados. Entregue a resposta neste formato exato: primeiro, uma breve visão da arquitetura e uma árvore do Explorer com todos os objetos que preciso criar. Depois, forneça cada arquivo completo, separadamente, identificando claramente o tipo do arquivo e o caminho exato onde deve ser colocado. Todo código deve estar em blocos markdown ```lua, ser Luau válido, completo, comentado em português e pronto para colar. Não use pseudocódigo, omissões como “adicione sua lógica aqui” nem dependências externas não explicadas. Inclua também a criação programática mínima da UI caso eu não tenha uma ScreenGui pronta, com botão de abrir/fechar, lista de jogadores, campos de texto, botões de ação e área de feedback. Ao final, inclua instruções objetivas para testar no Roblox Studio: ativar API Services para DataStore em ambiente publicado de teste, configurar UserIds administrativos, testar com Start Server e múltiplos Players, validar kick/ban/teleport/item, verificar logs do servidor e testar tentativas indevidas via cliente. Explique também como desbanir manualmente um UserId de forma segura, preferencialmente por função administrativa server-side ou ferramenta de manutenção restrita.
