Orc Incremental Blight

Quick facts

Historical build

Demo v0.09

Input one

Maximum level reached

Input two

Total gold gained during the current Dark Rebirth cycle

Formula status

Not published

Current scope

A larger branching tree is confirmed for version 1.0.

Keep the historical wording attached

The registry summary preserves the two categories named in the Demo note and leaves the operation between them open. That distinction matters: knowing which fields participate does not reveal their weights, caps, rounding, or interaction.

The Accursed Elf portrait is thematic promotional art tied to the broader reset cluster. It does not display Blight, a reward calculation, or a current tree. No value is inferred from the animation.

Use the Dark Rebirth evidence guide for the cycle comparison that surrounds a reset. Use the Blight Tree reference when the question concerns spending after the gain rather than the gain itself.

Build a matched-cycle record

Compare cycles only when the record contains enough context to explain their differences. A useful row includes the build, route, army, progression peak, cycle economy total, displayed Blight result, and every purchase that could change those fields.

Field	Cycle A	Cycle B
Build label	Record	Same or mark different
Army and route	Record	Hold fixed where possible
Progression peak	Record	Record
Cycle economy total	Record	Record
Displayed result	Record	Record
Reset prompt wording	Capture	Capture
Other changed variable	List	List

Do not compare a short experimental cycle with a long progression push and then assign the whole difference to one field. Change one intended input range at a time.

Separate observation from equation

An observation describes what the interface showed. An equation predicts what it will show for other inputs. The second claim needs more evidence than two rows that happen to differ.

Use wording such as “the displayed result increased in the longer cycle under build X.” Avoid “the game multiplies these values” or “one field is always better.” Several hidden operations can fit the same small sample, especially when displays round values.

If two models remain plausible, design a future cycle where their predictions differ. When the game does not expose enough precision, leave both open. A reproducible table can still help without selecting hidden math.

Check the current interface again

Historical Demo text is a starting point for what to record, not a promise that labels or behavior survived unchanged. Before applying the old categories to a current build:

1. Record the current version label.
2. Capture the complete reset and reward text.
3. Check whether the same input fields are still named.
4. Note any additional field, cap, preview, or warning.
5. Run one matched comparison before writing advice.

If the interface no longer names the same fields, preserve the historical record and create a new current record. Do not edit the old source into agreement.

Connect gain evidence to spending evidence

How Blight is earned and how it is spent are separate questions. A larger displayed reward does not identify the best node, and a useful node does not reveal the reward calculation. Keep one table for gain observations and another for tree choices.

For spending, record the visible node text, current cost, prerequisite path, choice made, and one outcome. The upgrade-priority framework can organize that outcome by bottleneck without ranking unpublished nodes.

This separation also makes patch review easier. A patch may change the tree without changing gain inputs, or change reward behavior without changing the visible tree layout.

Blight mistakes that erase evidence

• Combining cycles from different builds without labeling the change.
• Recording only the reward and omitting the progression and economy fields.
• Declaring an operator from one before-and-after pair.
• Treating a promotional tree screenshot as the current node database.
• Mixing a reward test with new units, a new route, and a different reset decision.
• Replacing an old row after a patch instead of preserving both records.

Publish the smallest supported result

A good report can say that two labeled cycles produced different displayed rewards under stated conditions. It should list uncontrolled variables and avoid predicting beyond the sample.

When an exact rule is eventually published, cite the new source and keep the Demo evidence as history. Do not backfill old observations with a formula they did not test. That preserves the difference between documentation and reconstruction.

Official source

Verification boundary

Build boundary

Demo v0.09 gain wording and confirmed version 1.0 tree scope

Evidence check

2026-08-28

Still unknown

exact gain formula, input weighting, caps, current node effects

Frequently asked questions

What is verified about Blight?

Demo v0.09 says Blight gain is based on maximum level reached and total gold gained during the current Dark Rebirth cycle. Boundary: Demo v0.09 gain wording and confirmed version 1.0 tree scope. Checked 2026-08-28. No exact gain formula, weighting, cap, or current node effect is published in the checked official material.

How can a Blight observation avoid inventing math?

Record the labeled build, maximum level, total cycle gold, displayed result, and any other changed variable. Compare matched cycles and describe the observed difference without naming an operator the source never publishes.

Can an old Demo result set a current target?

No. Historical wording can identify fields worth recording, but a current recommendation needs current build evidence. Preserve the old row and start a new group rather than relabeling it.