Health — Diagnostics¶

Folder Overview¶

Development-time visualisation for Health state.

One component lives here: ShieldDebugger, which draws a shield bar and label in the Scene view for the shield on its GameObject.

Purpose¶

Shields absorb damage before HP is touched, which makes them the part of the damage pipeline you are least able to see. A health bar shows the result; this shows the layer that changed it.

What Lives Here¶

ShieldDebugger¶

Reads the shield on its GameObject and draws its current and maximum values as a Scene-view overlay while you work.

Everything it draws is Editor-only and costs nothing in a player build.

Important Notes¶

Why a Runtime folder holds an Editor-only tool¶

This is the distinction the folder exists to make, and it is easy to get backwards.

The drawing is Editor-only. The component is not. ShieldDebugger is a MonoBehaviour that lives on a GameObject in a scene, which means a player build has to be able to compile a type by that name — otherwise every scene carrying one loads with a missing script.

It previously sat under Editor/Gizmos/, which no .asmdef covered, so Unity compiled it into the predefined assembly and it behaved correctly by accident. It lives here now because a serialised component belongs in a runtime assembly, and its Editor-only body is gated internally rather than by the folder it sits in.

The rule generalises: if a type can appear in a serialised scene or prefab, it belongs under Runtime/, whatever it does when it gets there. Guarding the whole class inside #if UNITY_EDITOR produces the missing-script failure it looks like it prevents.

Not a supported runtime surface¶

This is a development aid. It has no public API worth building against, and nothing in the framework consults it. Delete it and Health is unaffected.

Related Documentation¶

• Shields
• Health Runtime Overview