Orc Incremental Martyrdom
A conservative Martyrdom reference for recording the announced trigger and testing visible outcomes without inventing timing, effects, costs, targeting, or builds.
- Published
- Updated
- Last checked
Not verified yet

Quick facts
- System
- Chieftain passive
- Confirmed trigger
- A Chieftain is sacrificed.
- Timing status
- Not published
- Effect status
- Not published
Keep trigger and result separate
The summary above records the narrow relationship named by the announcement. It does not disclose what happens afterward. A trigger can be confirmed while its timing window, output, target, cost, and strategic value remain unknown.
The portrait is thematic art from the wider progression material. It does not depict a Chieftain, a sacrifice event, or a passive result. No mechanic should be inferred from the character, motion, or framing.
Use the Chieftains overview for the surrounding release scope and the bloodlines reference for the confirmed catalog boundary. Keep observations from those systems separate unless the current interface explicitly connects them.
Capture the complete before state
Before testing, save a non-destructive record of the battlefield and visible interface. Do not edit a save or force a hidden state.
| Field | What to record |
|---|---|
| Build | Exact version or dated build label |
| Subject | Exact current Chieftain label |
| Army | Units, formation, and relevant upgrades |
| Encounter | Named wave, boss, or checkpoint |
| Before state | Visible health, resources, statuses, and prompts |
| Event | Exact input or battle event observed |
| After state | First visible changes in order |
| Repeat | Whether the same sequence occurs again |
If a value is not exposed, mark it unavailable. Estimating hidden timing from a recording can be useful as an observation, but it is not an official duration.
Test one possible outcome at a time
Start without naming the expected effect. Record what changes immediately after the event, what changes later, and what does not appear to change. Repeat at the same encounter with the same army before altering another variable.
If several effects appear together, treat each as a separate question. A damage change, resource change, status icon, and unlock message may have different causes. The passive name alone does not establish that all of them belong to it.
Use a control where the relevant event does not occur if the game makes that comparison possible. Keep uncontrolled differences visible in the conclusion.
Do not turn cost into advice
Without a published or observed result, there is no evidence-based way to weigh the event against keeping a battlefield unit. Even after one result is observed, the comparison depends on the encounter, army, progression state, and objective.
A useful later recommendation should name the wall, build, tested alternatives, and stop condition. It should never claim a universal timing window or best pairing from one run. The formation guide can help hold positions and allies constant during a battlefield comparison.
Review ambiguous sequences carefully
Order matters. Record whether a visible change occurs before, during, or after the relevant animation, but avoid claiming causation from sequence alone. Another upgrade, enemy attack, or encounter transition can happen in the same window.
Frame-by-frame captures may identify a question for the next test. They do not reveal an unpublished formula or targeting rule. Repeat with a simplified setup when possible.
Preserve build history
On a later patch, start a new row. Compare visible wording, availability, sequence, and result against the old record. Do not rewrite an earlier observation to match a new outcome.
Until current evidence fills the gaps, the safest guide is explicit about what is missing. That boundary prevents a dramatic system name from becoming an invented strategy.
Official sourceVerification boundary
- Build boundary
- version 1.0 announcement
- Evidence check
- Still unknown
- sacrifice timing, resulting effect, cost and targeting, eligibility rules, recommended uses
Frequently asked questions
- What is verified about Martyrdom?
- The announced Martyrdom passive activates when a Chieftain is sacrificed. Boundary: version 1.0 announcement. Checked 2026-08-28. The checked source does not publish the sacrifice timing, resulting effect, cost, targeting, eligibility rules, stats, or recommended uses.
- How can Martyrdom be tested without assuming its effect?
- Record the full before state, the exact event, the first visible change afterward, and the build label. Repeat with one changed variable and keep effects that are not visible marked unknown.
- Does thematic character art show the passive?
- No. The portrait on this page is thematic and does not depict a Chieftain, a sacrifice, or the result of the passive.
Source ledger
- We have a release date!
steam-announcement ·