Skip to content

Hostile Consumer Panels

This folder contains hostile-consumer teachable panels for the Health system.

These panels are intentionally written as if they lived in a completely separate Unity project consuming RevFramework from the outside.

They verify that the Health system's public API surface is complete, stable, and usable without internal access.

What "Hostile Consumer" Means

Panels in this folder are restricted to using only:

  • Public APIs
  • Documented runtime components
  • Supported extension seams
  • Teaching UI utilities

They may not:

  • reference .Internal namespaces\
  • use reflection to access private state\
  • call undocumented .Core helpers\
  • depend on sample/demo utilities\
  • modify runtime wiring by automatically attaching demo components

If a panel requires any of those behaviours, the panel must not live in this folder.

Built-In Runtime Model

The Health system exposes a supported runtime component model rather than a central service.

Hostile consumer panels may interact with these documented runtime components:

HealthSystem
DamageContext
DamageResult
DamageTag
DamageRejectionReason

And the following supported built-in rule components:

ArmorRule
AffinityRule
TeamRule
CritRule
ExecuteThresholdRule

And the following supported handlers/effects:

HealthRegenerationHandler
HealthInvincibilityHandler
HealthCombatState
DotEffect
HotEffect

These are part of the public runtime API, not internal implementation details.

Purpose of These Panels

Hostile-consumer panels serve two roles.

1️⃣ API Verification

They prove that the Health system can be used through its public surface only.

If a hostile-consumer panel breaks during refactoring, it likely means the public API surface has changed.

Because these panels avoid internal APIs, they act as a real consumer test of the framework.

2️⃣ Teaching Real Usage

These panels demonstrate production-style usage patterns, including:

  • constructing DamageContext
  • calling HealthSystem.PreviewDamage
  • applying damage through HealthSystem.ApplyDamage
  • responding to DamageResult
  • interacting with rules like ArmorRule, AffinityRule, and TeamRule
  • observing runtime behaviour through public events

Everything shown here uses the same APIs developers use in real gameplay code.

Relationship to Demo Panels

Not all teaching panels are hostile consumers.

Panels that:

  • dynamically add/remove runtime components
  • rebuild shield stacks or rule configurations
  • modify scene composition for demonstration purposes

are placed in the Teaching/Demo folder instead.

Examples include panels that demonstrate:

Shield stacks
Team setups that auto-create rules
Runtime composition experiments

Those panels exist to demonstrate behaviour, not to verify the public API surface.

Summary

Panels in this folder are API verification tools disguised as teaching panels.

They guarantee that:

  • the Health public API is usable from external code
  • rules, handlers, and effects can be consumed without internal access
  • the framework can evolve internally without breaking external consumers

If these panels compile and run, the Health public API works.