Orc Incremental Builds

Quick facts

Build definition

Army, arrangement, relevant progression, encounter, and build label.

Starting point

Name the first repeatable bottleneck.

Comparison rule

Change one army, position, or progression variable.

Reset context

Record whether the run is before or after a permanent-progress choice.

Publication limit

A result applies only to its tested conditions.

What a build record means here

A useful build record is not a memorable nickname. It is a set of conditions another player can inspect: exact game build, army, arrangement, relevant progression choices, encounter, reset context, and measured result.

The official store confirms drafting, arranging an army, automated combat, upgrades, Dark Rebirth, and permanent bonuses. The release announcement confirms four new allied roles for version 1.0. The checked sources do not publish a universal army plan, a complete value table, or a released performance comparison.

This worksheet connects the verified loop without inventing the missing numbers. It is designed for the first released observations and for later patch reviews.

Diagnose the bottleneck first

Write the first repeatable reason progress stops. Keep it concrete:

• an exposed ally is removed before acting;
• the army cannot reach a blocking target;
• a control or siege event selects an unexpected target;
• the army survives but does not finish;
• the combat plan works but the next useful change is too slow;
• a reset is available, but its purpose in the next run is unclear.

Use the progression diagnosis guide when the wall spans combat, economy, and permanent progress. Use formation diagnosis when one arrangement change may isolate the problem.

A build comparison should answer the named bottleneck. Adding survival to an army that already survives may change a visible number without changing progress.

Fill the baseline worksheet

Record the baseline before making a recommendation:

Field	Record
Game build	Exact version shown by the game
Encounter	Named or reproducibly described battle
Reset context	Current run stage and relevant permanent choices
Army	Every allied unit used
Arrangement	Positions with orientation clear
Draft context	Relevant offered and chosen unit or Totem cards
Purchases	Only choices relevant to the test
Bottleneck	First repeatable failure
Outcome	Stable visible measure
Attempts	Comparable attempt count
Open limit	Condition not controlled

If a field cannot be captured, say so. An incomplete honest record is easier to review than an exact-looking plan built on hidden conditions.

Match confirmed roles to questions

The unit registry contains four exact official roles. They support questions, not automatic picks.

Assassin

Ask whether stealth and critical events change access or the visible sequence under the same conditions. Do not assign an unpublished chance or value.

Troll

Separate durability from reflected damage. A longer survival result should not be credited to reflection without a visible event.

Warg Raider

Record hook target, movement, and area effect. A local access solution does not establish a global rank.

Juggernaut

Identify what counts as a siege interaction in the released game and what the explosive cue affects. Do not assume a placement from the class name.

The entity pages provide a post-launch checklist for each role. The tier-list gate keeps all four unranked until comparable evidence exists.

Change one layer at a time

A build has several layers. Keep the others fixed when testing one:

1. Army test: replace one role, preserve the arrangement and progression as closely as possible.
2. Formation test: move one unit, preserve the army and purchases.
3. Progression test: change one relevant purchase, preserve the army and arrangement.
4. Reset test: compare named run stages and state what permanent difference is being evaluated.

When the interface forces several changes, label the result as a new baseline. Do not claim a single cause.

Handle reset context honestly

Dark Rebirth and permanent bonuses are verified parts of the store description, but this source set does not publish a universal reset formula or a complete version 1.0 threshold. A build copied from a different run stage may not answer the same problem.

Before a reset, record the current wall and the expected purpose of the next run. After the reset, record which visible condition differs. If several permanent choices change, the result describes the combined new state.

The upgrade priority guide helps compare purchases by the problem they address. It deliberately avoids fixed numerical thresholds.

Compare candidates

Use the same outcome measure for baseline and candidate. Depending on the question, that may be encounter completion, first ally lost, blocking target reached, or a visible event order. Repeat close results.

Check	Baseline	Candidate
Same build	yes or explain	yes or explain
Same encounter	yes or explain	yes or explain
Same reset context	recorded	unchanged
Single variable	none	named
Outcome measure	defined	same measure
Repetitions	recorded	matched

If one candidate improves survival and another improves access, return to the bottleneck. Do not collapse them into a private score unless the score and its purpose are fully defined.

Avoid unsupported meta names

A label such as "critical build" or "siege build" may be convenient for a notebook, but it can imply verified interactions that the sources do not establish. Prefer a descriptive scope: "Assassin access test in this encounter" or "Juggernaut siege observation in this build."

Do not claim that two roles amplify each other unless a named-build comparison isolates that interaction. Winning with both present shows the army won, not why.

The best-formations recording template provides a more detailed arrangement comparison when position is the main variable.

Review failure cases

The candidate wins once

Repeat it and keep failed attempts. One result may be timing variation.

Several upgrades were affordable

Buy one, replay, and record the same measure. If you buy all of them, treat the next state as a new baseline.

The build works in a different encounter

Record a separate scope. Do not merge results from unlike opponents into one claim.

A patch arrives

Preserve the old build record and rerun the baseline. Update the recommendation only after the relevant result is checked again.

The exact cause stays unclear

Publish the observation and name the unresolved alternatives. A useful unknown is better than a false mechanic.

Media boundary

The Dark Rebirth prompt hero is official promotional media and fits the reset context of this worksheet. It does not publish a reset formula, prove a version 1.0 threshold, or identify a required build path.

Treat interface images as evidence for visible labels and choices only. Use released named-build tests for behavioral conclusions.

Publish a bounded recommendation

A recommendation should state the build, encounter, wall, baseline, one change, repeated result, and limit. Link the official role record for any unit named. Keep the date so a later patch audit can identify stale guidance.

That format is less catchy than a meta name and much easier to verify. It lets another player decide whether the tested conditions match their own run.

Official source

Frequently asked questions

Does this guide name a version 1.0 meta build?

No. The checked official sources do not provide released performance evidence for a universal army and upgrade plan. The worksheet keeps observations comparable without naming an unsupported meta.

What should a build record contain?

Record the game build, army, arrangement, relevant progression choices, encounter, observation count, and measured result. Note the single variable changed between comparisons.

When should a build be retested?

Retest after a relevant patch, after the progression state changes materially, or when the same setup reaches a different encounter. Keep old results labeled with their original build.