Roblox Life, Shield, and Damage Feedback System
ESCOPO
Create a robust combat system for Roblox with configurable maximum health, delayed regeneration after no damage, a shield that absorbs damage before health, and correct handling for death, respawn, and connection cleanup. The result should prioritize server authority to prevent clients from manipulating health, damage, or shield.
The prompt requests a complete architecture with a server Script and a client LocalScript, including responsive visual feedback such as a red screen flash, shield vignette, health/shield bar, and update animations. It also asks for compatibility with the existing structure of your project, allowing you to provide RemoteEvents, GUIs, folders, and object names in the Explorer.
Ideal for developers who need a professional, extensible, and secure foundation for PvP, RPG, survival, arena, or obby experiences with combat. The generated code comes commented, organized, and accompanied by clear installation and testing steps in Roblox Studio.
Conteudo
Prompt principal
Act as a senior Roblox developer, specialized in Luau, multiplayer combat systems, HUD UX, and server-client security. Generate a complete implementation, ready to paste into Roblox Studio, of a health system with regeneration, absorbing shield, and visual damage effects. Do not deliver pseudocode, incomplete snippets, or explanations that replace working code. Before writing the code, consider and respect the context below. If any item is empty, use the suggested default names and structure, keeping them centralized in easy-to-change constants/configuration: - Structure/name of the objects already existing in the Explorer: [COLE AQUI] - Existing RemoteEvents or RemoteFunctions and their paths: [COLE AQUI] - Existing GUI/HUD, names of Frames, bars, Labels, and hierarchy: [COLE AQUI] - Current system that applies damage (weapons, NPCs, zones, etc.) and how it calls events: [COLE AQUI] - Desired values: maximum health, maximum shield, regeneration per second, regeneration delay, flash duration: [COLE AQUI] - Additional rules, for example, whether the shield recharges or not, immune teams, attributes, sounds, and platforms: [COLE AQUI] Implement the solution as a small package of scripts, explicitly stating the type and exact location of each file in the Explorer: 1. A server Script in ServerScriptService, named HealthShieldServer, responsible for authoritative state, creation/configuration of RemoteEvents when needed, Humanoid integration, regeneration, shield, validation, and death. 2. A LocalScript in StarterPlayer > StarterPlayerScripts, named DamageFeedbackClient, responsible exclusively for the interface and local visual effects. 3. If it improves maintainability, include a ModuleScript for configuration in ReplicatedStorage > Shared > HealthShieldConfig. If you create this module, provide its full code and adjust the other scripts to use it correctly. Mandatory functional requirements: each character must start with configurable health and shield; the shield must absorb damage before health and never go negative; excess damage must reach the Humanoid; health regeneration should only begin after a configurable delay since the last damage; it must stop upon taking new damage, respect maximum health, and not revive dead characters. Define replicated attributes on the Character, at minimum Shield, MaxShield, and LastDamageTime, for integration with other systems and HUDs. Handle CharacterAdded, Humanoid.Died, character switching, respawn, and connection cleanup without leaks or multiple concurrent loops. Create a clear server API for other systems to apply damage, preferably a documented local function ApplyDamage(player, amount, source) and, if needed for external integration, a RemoteEvent with an explicit contract. The server must be authoritative: never trust the client to report damage, currency, inventory, health, shield, or target. Any data received by RemoteEvent/RemoteFunction must be rigorously validated on the server: type, finite number, allowed range, existence of the Player/Character/Humanoid, sender permissions, and rate limit/debounce per player. If the game does not need clients to request damage, do not expose a damage RemoteEvent; explain how server-side weapons and NPCs should call the API or adapt the integration point. On the client, produce smooth, non-blocking visual effects: flash/redness on the screen proportional to the damage that hit health, a blue/cyan effect when the shield absorbs damage, and a HUD created by code only if the provided GUI does not exist. The HUD must show health and shield bars and values, update via Attributes and Humanoid.Health, use TweenService safely, and work after respawn. Do not allow the LocalScript to alter real combat values. Feedback may be received by a strictly informational RemoteEvent sent by the server; validate the received structure on the client as well to avoid errors. Deliver the response in this order: (1) short technical summary of the architecture and assumptions adopted; (2) Explorer installation tree; (3) COMPLETE code for each file, each inside its own markdown block identified as ```lua, with useful comments in Portuguese; (4) integration instructions for weapons/NPCs/zones to cause damage on the server; (5) detailed checklist to test in Play and Start Server + Players in Roblox Studio, including tests for partial/total shield absorption, interrupted regeneration, death, respawn, and client-side exploitation attempts. Use current Roblox APIs, idiomatic Luau, task.wait/task.spawn when appropriate, and avoid obsolete APIs.
