Sistema Anti-Invasão Seguro para Bases e Tycoons Roblox
ESCOPO
Gere um sistema robusto de proteção de bases e tycoons para experiências Roblox multiplayer. O resultado é um Script Luau autoritativo no servidor, preparado para identificar o proprietário de cada base, monitorar zonas protegidas, barrar invasores e controlar exceções como aliados, equipes ou permissões temporárias.
O prompt orienta a IA a adaptar o código à estrutura real do seu Explorer, incluindo nomes de pastas, Parts, Attributes, valores de proprietário, tags do CollectionService e RemoteEvents já existentes. Também exige validação rigorosa de qualquer solicitação vinda do cliente, evitando exploits relacionados a teleporte, dano, dinheiro, roubo de itens e acesso não autorizado.
Ideal para desenvolvedores que criam tycoons, jogos de construção de bases, PvP com territórios, simuladores e experiências com propriedades privadas. O código solicitado vem comentado, pronto para colar no Roblox Studio e acompanhado de um roteiro de testes multiplayer.
Conteudo
Prompt principal
Atue como um desenvolvedor Roblox sênior, especialista em Luau, segurança multiplayer e arquitetura server-authoritative. Crie um sistema completo de proteção de base/tycoon contra outros jogadores usando um único Script de servidor chamado `BaseProtectionServer`, localizado em `ServerScriptService`. Antes de escrever o código, analise e utilize o contexto do meu jogo fornecido abaixo. Meu contexto do Explorer e regras atuais (vou preencher ou substituir estes campos): - Pasta que contém todas as bases/tycoons: [EX.: workspace.Tycoons] - Como cada base é identificada: [EX.: Model com Attribute `BaseId`, nome numérico, ou pasta própria] - Como o dono é salvo: [EX.: Attribute `OwnerUserId`, IntValue `OwnerUserId`, ObjectValue `Owner`, ou sistema externo] - Nome/localização das peças de zona protegida: [EX.: Model.BaseZone, Part `ProtectionZone`, ou tag CollectionService `BaseProtectionZone`] - Estrutura das portas/barreiras: [EX.: Part `Barrier`, folder `Doors`, CollisionGroup já existente] - Método atual de reivindicar uma base: [descrever] - RemoteEvents/RemoteFunctions existentes e localização: [listar nome, caminho e finalidade] - Sistema de dano/armas usado no jogo: [descrever scripts, eventos e como o dano ocorre] - Sistema de dinheiro, roubo ou inventário que deve ser bloqueado na base: [descrever] - Times, aliados, gamepasses ou permissões que podem entrar: [descrever] - Ação desejada ao invasor entrar: [EX.: teleportar para Spawn, empurrar para fora, apenas impedir interação, aplicar aviso] - Outros objetos ou regras relevantes: [descrever] Crie o código para um Script normal de servidor (não LocalScript e não ModuleScript), a ser inserido em `ServerScriptService`. O sistema deve funcionar em ambiente multiplayer e adotar servidor autoritativo: o servidor é a única fonte de verdade para propriedade da base, permissões, dano, moedas, itens, portas e efeitos de proteção. Nunca aceite do cliente um UserId de proprietário, uma base-alvo, uma permissão, um valor de dinheiro, um dano, uma posição ou uma recompensa sem validar tudo no servidor. Implemente uma solução robusta e configurável dentro do próprio Script, com uma seção `CONFIG` claramente organizada no início. Ela deve permitir adaptar facilmente nomes de pastas, Attributes, tags, duração de proteção, comportamento para invasores, distância/limites de tolerância e regras de aliados. Se as informações do meu contexto estiverem incompletas, faça suposições seguras e centralize todas elas na `CONFIG`, documentando em comentários exatamente o que preciso alterar no Explorer. O sistema precisa, quando aplicável à minha estrutura: detectar de maneira confiável qual base pertence a cada jogador; reconhecer se um personagem está dentro da zona daquela base; permitir o proprietário e jogadores autorizados; bloquear ou remover invasores da área conforme a regra configurada; evitar loops excessivos e vazamentos de conexão; lidar com `PlayerAdded`, `PlayerRemoving`, `CharacterAdded`, respawn, morte, troca de dono, base sem dono e destruição/recriação de objetos. Use `Players`, `RunService`, `CollectionService`, `PhysicsService` e outros serviços apenas se forem realmente necessários e compatíveis com o contexto fornecido. Se houver RemoteEvents ou RemoteFunctions relacionados a portas, compra, coleta, dano, roubo, acesso ou reivindicação de base, integre validação server-side. Para cada chamada remota, valide no servidor: tipo dos argumentos com `typeof`, existência e classe das Instances, vínculo real entre jogador e base, distância plausível entre personagem e objeto, estado da base, cooldown/rate limit e autorização. Não use eventos remotos para conceder dano, moeda, itens ou propriedade apenas com base em dados enviados pelo cliente. Caso o sistema de armas/dano seja externo e não possa ser alterado neste único Script, deixe uma interface/função documentada para que o script de dano consulte antes de aplicar dano em uma zona protegida. Evite soluções frágeis como confiar somente em `Touched`, usar `while true do wait()` para todos os jogadores, definir proprietário no cliente ou tornar toda a base ancorada como única estratégia de segurança. Prefira monitoramento eficiente por heartbeat com intervalo configurável, checagens espaciais confiáveis e conexões gerenciadas. Não destrua permanentemente o personagem de invasores sem uma opção explícita na configuração. Garanta que o sistema não bloqueie o próprio dono por falhas transitórias durante respawn. Sua resposta deve seguir exatamente esta estrutura: 1. Uma lista curta de pré-requisitos e a estrutura esperada no Explorer. 2. Um único bloco de código Markdown com a linguagem `lua`, contendo o Script Luau completo, funcional, comentado e pronto para colar em `ServerScriptService`. 3. Após o bloco, explique objetivamente quais valores da `CONFIG` devo adaptar ao meu jogo. 4. Finalize com um passo a passo para testar no Roblox Studio usando `Test > Start` com pelo menos dois jogadores, incluindo testes de dono, invasor, respawn, troca de dono, RemoteEvents inválidos e tentativa de exploração pelo cliente. Não entregue pseudocódigo, trechos incompletos, código de cliente como mecanismo principal de segurança, nem dependências não explicadas. Priorize compatibilidade com Luau atual, legibilidade, tratamento de erros com avisos úteis e segurança real em servidor.
