IA de Inimigo FSM: Idle, Patrulha, Alerta e Combate
ESCOPO
Gere uma IA robusta de inimigo para Roblox usando uma máquina de estados finitos (FSM) com os estados idle, patrulha, alerta e combate. O resultado é pensado para NPCs com Humanoid, movimentação por waypoints, detecção de jogadores por distância, campo de visão e raycast de linha de visão.
O prompt orienta a IA a adaptar o código ao contexto real do seu projeto, incluindo nomes de modelos, peças, pastas, atributos, RemoteEvents e sistemas de dano já existentes. Ele exige uma implementação server-side segura, com PathfindingService, tratamento de alvos inválidos, prevenção de recalculo excessivo de rotas e instruções práticas de teste no Roblox Studio.
Ideal para desenvolvedores que querem uma base profissional e expansível para inimigos guardas, monstros, soldados ou chefes, sem delegar decisões críticas de combate ou dano ao cliente.
Conteudo
Prompt principal
Atue como um desenvolvedor Roblox Luau sênior, especializado em IA de NPCs server-authoritative, máquinas de estados finitos (FSM), `PathfindingService` e arquitetura segura para jogos multiplayer. Gere uma implementação completa e pronta para uso de uma IA de inimigo com os estados `Idle`, `Patrulha`, `Alerta` e `Combate`, adaptando rigorosamente o resultado ao contexto do meu jogo fornecido abaixo. Antes de escrever o código, analise o contexto que vou colar ao final desta mensagem. Ele poderá conter nomes exatos de objetos no Explorer, estrutura do modelo do inimigo, nomes de Parts, pastas de waypoints, Attributes, CollectionService tags, módulos existentes, RemoteEvents/RemoteFunctions e meu sistema atual de dano. Use esses nomes literalmente quando forem fornecidos. Se alguma informação essencial estiver ausente, não invente uma integração complexa: declare no início do resultado as premissas adotadas e use nomes configuráveis concentrados em uma seção `CONFIG` no topo do script. Se o contexto estiver vazio, assuma uma estrutura padrão claramente documentada. O entregável principal deve ser exatamente um `Script` de servidor, colocado dentro do `Model` de cada inimigo no Workspace (por exemplo: `Workspace.Enemies.NomeDoInimigo.AIController`). Explique que o Model precisa conter `Humanoid` e `HumanoidRootPart`, e que a movimentação e as decisões da IA ocorrem exclusivamente no servidor. Caso eu informe uma arquitetura centralizada de NPCs ou um ModuleScript existente, adapte a localização e a interface sem transformar a solução em vários arquivos, a menos que eu peça explicitamente. Implemente uma FSM explícita, preferencialmente com uma tabela de estados, função de transição e limpeza controlada ao trocar de estado. Os comportamentos mínimos são: - `Idle`: inimigo parado ou em espera por um tempo configurável; procura jogadores válidos periodicamente. - `Patrulha`: percorre uma pasta configurável de waypoints em ordem ou de forma aleatória controlada; usa pathfinding quando necessário; retorna para idle se não houver waypoints. - `Alerta`: é ativado ao detectar ou suspeitar de um jogador; guarda a última posição conhecida, aguarda por um período configurável e investiga essa posição antes de desistir. - `Combate`: persegue o alvo enquanto ele for válido e visível/identificado; respeita distância mínima de ataque, cooldown e alcance. O ataque deve ser uma função isolada e segura, preparada para integração com meu sistema de dano. A detecção deve considerar distância máxima, campo de visão baseado no `LookVector` do inimigo e raycast para linha de visão, com `RaycastParams` excluindo o próprio modelo do NPC. Valide que o alvo é um jogador real, que o `Character`, `Humanoid`, `HumanoidRootPart` e vida estão válidos, e que o alvo não foi destruído. Mantenha memória da última posição vista e um temporizador de perda de alvo para evitar alternância caótica entre estados. Escolha o alvo mais apropriado, normalmente o jogador visível mais próximo, sem fazer loops pesados a cada frame. Use `PathfindingService:CreatePath()` e waypoints de rota de forma resiliente. Trate caminhos falhos, `MoveToFinished`, NPC preso, destino alterado, obstáculos e tentativas limitadas de recálculo. Inclua intervalos configuráveis para escaneamento de alvo e recálculo de path, evitando criar paths em excesso. Não utilize `while true do` sem `task.wait()`, não conecte eventos repetidamente a cada troca de estado sem desconectá-los, e faça limpeza de conexões/tarefas quando o Humanoid morrer ou o Model for destruído. Preserve a física normal do Humanoid e não use APIs inexistentes ou sintaxe Lua incompatível com Luau. Segurança é obrigatória: o servidor deve ser autoritativo para detecção, movimento, escolha de alvo e dano. Nunca confie no cliente para informar dano, vida, moedas, inventário, posição de inimigo ou resultado de ataque. Se meu contexto incluir RemoteEvents/RemoteFunctions, valide no servidor tipo, existência, distância, estado do jogador, rate limit e permissões antes de qualquer efeito relevante. Para o ataque padrão, aplique dano apenas no servidor por uma função `applyDamage` bem comentada; se existir um módulo de combate informado por mim, chame sua API somente após validações server-side. Não crie RemoteEvents desnecessários. Forneça primeiro uma seção curta chamada `Premissas e instalação`, indicando o local exato do Script e a estrutura esperada no Explorer. Em seguida, entregue o código Luau integral, sem pseudocódigo, sem trechos omitidos e sem usar `...`, dentro de um único bloco Markdown com a linguagem `lua`. Comente as partes importantes em português, especialmente configurações, transições de estado, visão/raycast, pathfinding, validação de alvo, ataque e limpeza. O script deve estar pronto para colar no Roblox Studio. Após o bloco de código, inclua uma seção objetiva `Como testar no Roblox Studio` com passos para criar/configurar o NPC, criar waypoints, ajustar atributos/configurações, usar Test > Start com múltiplos jogadores e verificar os quatro estados. Inclua também uma breve lista de problemas comuns e diagnósticos, como HumanoidRootPart ausente, collision group impedindo raycast, waypoints inacessíveis e Network Ownership. Não faça perguntas de acompanhamento: tome decisões razoáveis com base no contexto e documente as premissas. A seguir está o contexto do meu jogo para você usar e respeitar: [COLE AQUI a estrutura do Explorer, nomes do Model/Humanoid/RootPart, pasta de waypoints, atributos, tags, módulos de combate, RemoteEvents existentes, regras de dano e qualquer requisito adicional.]
