Orc Incremental Blight Tree

Quick facts

Confirmed scale

250+ nodes

Confirmed structure

A branching tree

Release boundary

Version 1.0 announcement

Node list

Not published

Ranking status

No verified priority order

Treat scale as scope, not a database

The announcement establishes that the release tree is large and branching. It does not enumerate the current nodes. A count and a promotional image cannot safely become a node list, cost table, or recommended path.

The registered hero preserves one dated tree frame with connected icons and locked nodes. It can show the interface style visible in that frame. It cannot prove that every pictured label, connection, or cost survived into the reader’s build.

Use the Blight evidence guide for gain observations. Use the Dark Rebirth guide when the open question is whether to end the current cycle before choosing from the tree.

Map only what the build shows

A useful tree record starts with visible facts. Give every captured node a local observation ID so connections can be described without guessing hidden names.

Field	What to capture
Build	Exact version or dated label
Node name	Complete visible name
Text	Full visible effect wording
Cost	Current displayed cost
State	Available, purchased, or locked
Parents	Visible incoming connections
Children	Visible outgoing connections
Requirement	Exact visible prerequisite text
Position	Enough context to find the node again

If a line disappears behind a locked panel or crop, mark the connection unknown. Do not complete a branch because it looks symmetrical.

Choose a test by bottleneck

Node priority depends on the run’s current failure, available branch, and objective. Start with an observation: an ally dies before acting, damage does not reach the blocker, economy delays a useful purchase, or another system prevents progress.

Then select the smallest currently visible choice that should affect that observation. Record the node text before purchasing it, replay a comparable segment, and state what changed. The upgrade-priority guide provides the same bottleneck method across other purchase types.

This is not a universal ranking. Another branch, army, build, or progression state may produce a different choice. A useful recommendation names all four.

Keep prerequisites and effects separate

A prerequisite answers whether a node can be reached. An effect answers what changes after purchase. A line between icons does not disclose either on its own.

Capture locked and unlocked states around one purchase. If another node becomes available, record that transition separately from the purchased effect. This prevents an unlock observation from being mislabeled as a combat bonus.

When text uses a term defined elsewhere, link the term rather than inventing an expansion. For historical gain language, consult the patch-notes ledger and keep the Demo label in the same note.

Compare branches without claiming best

Two branch observations need a common objective. “Reached a higher checkpoint under the same build and army” is measurable. “Felt stronger” is not.

Use separate save-safe runs or naturally repeated cycles. Never edit a save to force a comparison. Record the starting permanent state, selected path, purchases outside the tree, formation, and chosen checkpoint. If those inputs differ, describe the result as a case study rather than a branch ranking.

Large trees create many interactions, so a single purchase rarely isolates a full path. Compare the next decision first. Longer path claims require more repeats and a clear account of what changed between them.

Review a tree after a patch

Start a new snapshot when a relevant update lands. Compare node names, text, costs, visible connections, and prerequisites field by field. Preserve removed or changed rows under their old build instead of overwriting them.

An image difference can identify where to inspect, but the current interface remains the authority for the current observation. Promotional frames stay labeled by their source date.

Common tree mistakes

• Copying a partial promotional frame into a complete node database.
• Inferring hidden paths from layout symmetry.
• Combining prerequisite, unlock, and purchased effect into one claim.
• Ranking nodes without a named objective or comparable run.
• Importing Demo names or art into the release tree without a current match.
• Publishing costs or effects from memory instead of the visible build.

The safe result is a versioned map of what was actually visible, plus narrow experiments for choices that matter to a diagnosed wall.

Official source

Verification boundary

Build boundary

version 1.0 announcement

Evidence check

2026-08-28

Still unknown

node names, effects, costs, paths, prerequisites, rankings

Frequently asked questions

What is verified about Blight Tree?

The version 1.0 announcement confirms a branching Blight Tree with 250+ nodes. Boundary: version 1.0 announcement. Checked 2026-08-28. Exact node names, effects, costs, paths, prerequisites, and rankings are not published in the checked source.

How should an unpublished node be documented?

Capture its exact current name, visible text, cost, prerequisites, connected paths, build label, and one controlled result. Keep the screenshot record separate from any recommendation.

Can the promotional tree image establish a node path?

Only for the dated frame it visibly preserves. It cannot establish the final tree, current costs, or a best path without matching released-build evidence.