Orc Incremental Enemies

Quick facts

Confirmed new units

Cryomancer; Paladin; Griffon

Confirmed detail

Names only

Role status

Not published

Counter status

Not published

Keep names separate from mechanics

The registry supplies the exact release-confirmed name scope. It does not turn familiar fantasy labels into roles. The snowfield hero is generic promotional battle art; none of its figures is identified here as one of the announced units.

The individual references for Cryomancer, Paladin, and Griffon intentionally begin with empty mechanic records. Use the bosses overview for a separate entity class.

Build an encounter record

Match an enemy by exact visible label before adding behavior. A silhouette, color, weapon, or animation is not enough when no registered media identity exists.

Field	Evidence
Name	Complete current label
Build	Exact version or date
Encounter	Level, wave, or boss context
Position	Starting lane or relative place
Action	First observable action
Target	What is visibly selected
Outcome	Damage, status, movement, or other shown result
Repeat	Result across comparable attempts

Use “not visible” where the interface hides a value. Do not estimate stats from sprite size or animation duration.

Observe before naming a role

A role is a summary of repeated behavior, not an extension of the enemy’s name. Record action order, target selection, range cues, movement, and visible status text across comparable encounters. One surprising event may come from another enemy or an active modifier.

Change the formation only after preserving the baseline. Then test one position or unit swap against the same checkpoint. If the enemy’s behavior changes, state the setup rather than declaring a universal counter.

Write counters as bounded experiments

A useful counter note names the build, enemy, encounter, failure event, tested change, and observed result. It also lists what was not controlled. “This move kept the front unit alive in this wave” is evidence; “always counter with X” is not.

Keep army strength and progression state visible. A successful result after several purchases cannot be assigned solely to formation.

Review identity after patches

On each relevant update, verify names, visible text, encounter locations, and behavior again. Keep old records under their original build. If official media later identifies an entity, link the exact asset and source rather than retroactively labeling generic art.

This codex is designed to grow from current observations while keeping the initial announcement boundary intact.

Distinguish a catalog from a strategy page

The catalog should prioritize identity and reproducible behavior. Strategy belongs in a separately bounded observation tied to a checkpoint and setup. This keeps a newly verified action from becoming an instant universal counter.

For each entity, show which fields are official text, current interface transcription, repeated observation, or interpretation. When two sources disagree, preserve both build labels and state the conflict. A clean provenance trail is more valuable than a single confident sentence that hides version drift.

Official source

Verification boundary

Build boundary

version 1.0 announcement

Evidence check

2026-08-28

Still unknown

roles, stats, abilities, encounter locations, counters, exact visual identities

Frequently asked questions

What is verified about Enemies?

The version 1.0 announcement confirms three new enemy unit names: Cryomancer, Paladin, and Griffon. Boundary: version 1.0 announcement. Checked 2026-08-28. Their roles, stats, abilities, encounter locations, unlock order, counters, and exact visual identities are not published in the checked source.

How should a new enemy encounter be cataloged?

Match the exact visible name first, then record the build, encounter, observable action, target, and outcome. Art resemblance alone is not enough to identify an announced enemy.