Sistema Avançado de Diálogo NPC com Árvore de Opções
ESCOPO
Ideal para desenvolvedores que querem um sistema reutilizável, seguro contra exploração no cliente e pronto para evoluir com reputação, missões, flags de progresso, recompensas e múltiplos NPCs.
Conteudo
Prompt principal
Atue como um desenvolvedor Roblox sênior especializado em Luau, arquitetura cliente-servidor, segurança contra exploits e sistemas narrativos escaláveis. Crie um sistema completo de diálogo com NPC baseado em árvore de opções, usando o contexto do meu jogo informado abaixo antes de gerar qualquer código. Meu contexto do projeto (substitua os campos quando eu fornecer valores reais): - NPCs e caminhos no Explorer: [COLE AQUI, por exemplo: Workspace.NPCs.Guarda, Workspace.Vila.Mercador] - Parte usada para interação: [ProximityPrompt existente / parte do NPC / criar ProximityPrompt] - Interface existente: [COLE caminhos de ScreenGui, Frames, Labels e Buttons, ou diga "criar interface via script"] - RemoteEvents/RemoteFunctions já existentes: [COLE NOMES E CAMINHOS, ou diga "criar os necessários"] - Sistema de dados/progresso existente: [leaderstats, ProfileService, DataStore próprio, atributos, nenhum etc.] - Regras de diálogo, NPCs, textos, escolhas, recompensas e condições desejadas: [COLE AQUI] - Restrições visuais e de compatibilidade: [desktop/mobile/gamepad, estilo, limite de distância etc.] Se alguma informação essencial estiver ausente, não invente nomes de objetos já existentes. Primeiro, liste objetivamente as suposições adotadas e use nomes consistentes, fáceis de substituir. Se eu disser que ainda não possuo interface ou remotes, crie a estrutura necessária de maneira programática ou explique exatamente quais instâncias criar no Explorer, priorizando uma solução pronta para teste. Implemente uma arquitetura composta pelos seguintes arquivos, entregues completos: 1. Um ModuleScript chamado `DialogueDefinitions`, colocado em `ReplicatedStorage/Shared` (ou no caminho equivalente que eu informar). Ele deve conter os dados dos diálogos de múltiplos NPCs em uma estrutura declarativa e escalável. Cada nó deve suportar: `Id`, texto do NPC, opções do jogador, próximo nó, encerramento, condição opcional, texto alternativo para condição falha e ação opcional autorizada pelo servidor. Inclua exemplos reais de pelo menos dois NPCs e uma ramificação com requisito de progresso. 2. Um Script chamado `DialogueServer`, colocado em `ServerScriptService`. Ele deve controlar a sessão de diálogo por jogador, conectar os ProximityPrompts ou a forma de interação informada, abrir diálogos, validar distância do jogador ao NPC, validar se o NPC existe e se a opção escolhida pertence ao nó atual da sessão. O servidor deve ser a única autoridade para condições, flags, recompensas, moedas, inventário e progressão. 3. Um LocalScript chamado `DialogueClient`, colocado em `StarterPlayer/StarterPlayerScripts` ou dentro da ScreenGui indicada no meu contexto. Ele deve exibir o diálogo, renderizar botões dinamicamente, permitir fechar a conversa, lidar com entrada de mouse/toque/gamepad quando aplicável e nunca decidir recompensas, condições ou progressão. Use `RemoteEvent`s com nomes claros, preferencialmente `DialogueRemote` para comunicação servidor-cliente, criando-os em `ReplicatedStorage/Remotes` somente se não existirem. Defina um protocolo explícito de mensagens, por exemplo: servidor envia `Open`, `Update` e `Close`; cliente solicita apenas `SelectOption` ou `RequestClose`. Toda mensagem recebida do cliente deve ser validada rigorosamente no servidor: tipos com `typeof`, existência e formato dos IDs, limite de tamanho de strings se houver dados textuais, rate limit/debounce por jogador, estado atual da sessão, distância máxima, vida do personagem e elegibilidade da opção. Nunca confie no cliente para informar o NPC atual, nó atual, dano, moeda, item, missão concluída ou qualquer estado sensível. Implemente limpeza robusta: encerre sessões ao morrer, sair do jogo, afastar-se do NPC, NPC ser destruído ou diálogo ser finalizado. Evite conexões duplicadas e memory leaks. Não use `loadstring`, não use DataStore diretamente dentro da lógica de interface e não faça loops infinitos sem necessidade. Estruture funções pequenas e nomeadas, use `--!strict` quando viável, `task` APIs modernas e comentários úteis em português explicando decisões relevantes. A resposta deve conter, nesta ordem: uma breve seção "Estrutura no Explorer"; uma seção "Código completo" com TODOS os arquivos integralmente dentro de um único bloco markdown ```lua, separando cada arquivo por comentários grandes com nome e caminho; uma seção "Como personalizar diálogos" com exemplos de nós e condições; e uma seção "Como testar no Roblox Studio" com passos para testar em modo Start Server + Players, verificar remotes, distância, escolhas inválidas e encerramento de sessão. Não entregue pseudocódigo, trechos incompletos ou dependências não implementadas. O código precisa estar pronto para colar, respeitando os caminhos e objetos que eu informar.