Sistema de Vida, Escudo e Feedback de Dano Roblox
ESCOPO
Gere um sistema robusto de combate para Roblox com vida máxima configurável, regeneração após atraso sem dano, escudo que absorve dano antes da vida e tratamento correto para morte, respawn e limpeza de conexões. O resultado prioriza autoridade do servidor para impedir que clientes manipulem vida, dano ou escudo.
O prompt solicita uma arquitetura completa com Script no servidor e LocalScript no cliente, incluindo feedback visual responsivo como flash vermelho na tela, vinheta de escudo, barra de vida/escudo e animações de atualização. Ele também pede compatibilidade com a estrutura já existente do seu projeto, permitindo informar RemoteEvents, GUIs, pastas e nomes de objetos no Explorer.
Ideal para desenvolvedores que precisam de uma base profissional, extensível e segura para experiências PvP, RPG, survival, arena ou obby com combate. O código gerado vem comentado, organizado e acompanhado de passos objetivos de instalação e testes no Roblox Studio.
Conteudo
Prompt principal
Atue como um desenvolvedor Roblox sênior, especialista em Luau, sistemas de combate multiplayer, UX de HUD e segurança servidor-cliente. Gere uma implementação completa, pronta para colar no Roblox Studio, de um sistema de vida com regeneração, escudo absorvente e efeitos visuais de dano. Não entregue pseudocódigo, trechos incompletos ou explicações que substituam código funcional. Antes de escrever o código, considere e respeite o contexto abaixo. Se algum item estiver vazio, adote os nomes e a estrutura padrão sugeridos, deixando-os concentrados em constantes/configurações fáceis de alterar: - Estrutura/nome dos objetos já existentes no Explorer: [COLE AQUI] - RemoteEvents ou RemoteFunctions existentes e seus caminhos: [COLE AQUI] - GUI/HUD existente, nomes de Frames, barras, Labels e hierarquia: [COLE AQUI] - Sistema atual que aplica dano (armas, NPCs, zonas etc.) e como ele chama eventos: [COLE AQUI] - Valores desejados: vida máxima, escudo máximo, regeneração por segundo, atraso de regeneração, duração do flash: [COLE AQUI] - Regras adicionais, por exemplo, escudo recarrega ou não, times imunes, atributos, sons e plataformas: [COLE AQUI] Implemente a solução como um pequeno pacote de scripts, explicitando obrigatoriamente o tipo e o local exato de cada arquivo no Explorer: 1. Um Script de servidor em ServerScriptService, chamado HealthShieldServer, responsável por estado autoritativo, criação/configuração de RemoteEvents quando necessário, integração com Humanoid, regeneração, escudo, validação e morte. 2. Um LocalScript em StarterPlayer > StarterPlayerScripts, chamado DamageFeedbackClient, responsável exclusivamente pela interface e pelos efeitos visuais locais. 3. Caso melhore a manutenção, inclua um ModuleScript de configuração em ReplicatedStorage > Shared > HealthShieldConfig. Se criar esse módulo, forneça seu código completo e ajuste os demais scripts para usá-lo corretamente. Requisitos funcionais obrigatórios: cada personagem deve iniciar com vida e escudo configuráveis; o escudo deve absorver dano antes da vida e nunca ficar negativo; dano excedente deve atingir o Humanoid; a regeneração de vida só deve começar após um atraso configurável desde o último dano; ela deve parar ao receber novo dano, respeitar vida máxima e não reviver personagens mortos. Defina atributos replicados no Character, no mínimo Shield, MaxShield e LastDamageTime, para integração com outros sistemas e HUD. Trate CharacterAdded, Humanoid.Died, troca de personagem, respawn e limpeza de conexões sem vazamentos ou múltiplos loops concorrentes. Crie uma API clara no servidor para outros sistemas aplicarem dano, preferencialmente uma função local/documentada ApplyDamage(player, amount, source) e, se necessário para integração externa, um RemoteEvent com contrato explícito. O servidor deve ser autoritativo: nunca confie no cliente para informar dano, moeda, inventário, vida, escudo ou alvo. Todo dado recebido por RemoteEvent/RemoteFunction deve ser validado rigorosamente no servidor: tipo, número finito, faixa permitida, existência do Player/Character/Humanoid, permissões do emissor e rate limit/debounce por jogador. Se o jogo não precisa que clientes solicitem dano, não exponha RemoteEvent de dano; explique como armas e NPCs do servidor devem chamar a API ou adaptar o ponto de integração. No cliente, produza efeitos visuais suaves e não bloqueantes: flash/vermelhidão na tela proporcional ao dano que atingiu a vida, efeito azul/ciano quando o escudo absorver dano, e uma HUD criada por código apenas se a GUI informada não existir. A HUD deve mostrar barras e valores de vida e escudo, atualizar por Attributes e Humanoid.Health, usar TweenService com segurança e funcionar após respawn. Não permita que o LocalScript altere valores reais de combate. O feedback pode ser recebido por um RemoteEvent estritamente informativo enviado pelo servidor; valide também a estrutura recebida no cliente para evitar erros. Entregue a resposta nesta ordem: (1) resumo técnico curto da arquitetura e premissas adotadas; (2) árvore de instalação no Explorer; (3) código COMPLETO de cada arquivo, cada um dentro de seu próprio bloco markdown identificado como ```lua, com comentários úteis em português; (4) instruções de integração para armas/NPCs/zonas causarem dano pelo servidor; (5) checklist detalhado para testar em Play e Start Server + Players no Roblox Studio, incluindo testes de absorção parcial/total do escudo, regeneração interrompida, morte, respawn e tentativa de exploração pelo cliente. Use APIs atuais do Roblox, Luau idiomático, task.wait/task.spawn quando apropriado e evite APIs obsoletas.
