Orc Incremental Cards

Quick facts

Verified choice types

The Steam description names units and Totems.

Verified visual

Official promotional media shows a card-style offer.

Unknown rules

Complete draw, rarity, weighting, and refresh behavior are unpublished.

Choice log

Record build, offers, selection, army state, and later observation.

Image boundary

A pictured choice does not prove final balance or availability.

What official material verifies

The official Steam description says players draft units and Totems to build an army. The official publisher press kit includes a promotional card-draft image. The pictured interface offers an Amber Drake Totem and a Dragon unit at the base.

Those facts establish a choice interface and named categories. They do not establish how choices are drawn, how often an offer appears, whether the pictured content has the same role in version 1.0, or how rarity affects selection.

This page uses the image as a visual record, not as a data table. It keeps behavior questions open until the released game or an official rule answers them.

Read a draft as a recorded choice

A useful choice log captures the state before selection:

Field	What to record
Build	Exact game version
Offer event	When or where the choice appeared
Cards shown	Names and visible labels exactly as displayed
Selected card	One chosen option
Army before	Existing allies and relevant arrangement
Progression context	Relevant run and permanent choices
Expected question	What bottleneck the choice may answer
Later observation	Visible result without assigning a hidden cause

Record every offered option, not only the chosen one. If an offer repeats later, a sequence of complete records can support a question about draw behavior. A memory of only desirable cards cannot.

Separate unit choice from Totem choice

The Steam description names both units and Totems as draft categories. That does not mean they follow the same selection, rarity, or persistence rules. Keep the visible type with each record.

For a unit choice, consult the confirmed version 1.0 roster before assigning a role. The four Task 13 entity records are limited to Assassin, Troll, Warg Raider, and Juggernaut because those are the names in the release announcement.

For a Totem choice, record the exact displayed name and text. Do not infer an effect from promotional art alone. A dedicated Totem codex belongs to a later implementation task and requires its own evidence boundary.

Use the army bottleneck, not the card frame

The visual prominence of a card does not show that it answers the current run. Name the first repeatable problem:

• an ally falls before acting;
• the blocking target remains untouched;
• a useful action occurs too late;
• the army survives without finishing;
• the combat plan works but progression is slow.

Then ask which offered choice has a visible, testable connection to that problem. If the interface text does not make the connection clear, record the selection as an experiment.

The build worksheet keeps that choice beside the army, arrangement, and progression state. The formation guide helps determine whether position, rather than the draft, caused the wall.

Do not invent rarity rules

Official descriptions mention rarities, and the promotional interface may show visual distinctions. The checked sources do not provide a complete version 1.0 rarity table, draw weight, protection rule, or upgrade path.

Do not assign probability from a small personal sample. Do not claim a border color always maps to a specific rate without a source or a reproducible released-build record. Do not treat the availability of one promotional card as proof that it appears in every mode or build.

If the released interface labels rarity, quote the visible label in a field note and keep the build. If a later official source publishes rules, cite it directly.

Design a draw observation

When the same offer process can be repeated, define the observation before collecting it:

1. name the released build and game mode;
2. state what counts as one offer event;
3. record every card in every event;
4. preserve visible type and rarity labels;
5. avoid changing progression conditions during the sample when possible;
6. report the full sample, including ordinary offers;
7. describe what the sample cannot establish.

A small sample can document that a card appeared. It cannot establish a precise probability. A changed progression state may alter the eligible pool, so record it rather than combining unlike runs.

Compare the result of a choice

If you want to test whether one choice answered a bottleneck, keep the later comparison narrow. Record the army and arrangement before selection, the chosen card, and the same visible outcome afterward. Avoid making other purchases before the first comparison when the game permits.

A changed outcome after a unit card may still depend on position. A changed outcome after a Totem card may coincide with another progression change. List these alternatives. Repeat a comparable case before stating causation.

Use the best-formations template when the card changes the army and forces a new arrangement. It provides fields for baseline, candidate, repetitions, and limits.

Promotional media boundary

The card-draft hero comes from the official Playsaurus press kit. It visibly presents an Amber Drake Totem and Dragon unit choice at the base. That makes it suitable for explaining what promotional card media can show.

It does not prove final version 1.0 availability, values, rarity, draw weights, timing, or balance. The source archive date and build state remain part of the media registry. An editor should not crop away the context and present the frame as a current probability table.

Common logging failures

Recording only the selected card

This loses the choice context. Record all visible offers.

Recording only rare-looking offers

This creates a biased sample. Preserve ordinary events too.

Mixing builds

Keep each version separate. A patch may change the pool or visible text.

Inferring rules from art

Color, frame, and composition can be observed. Their behavioral meaning requires an explicit label or tested evidence.

Crediting one card after many changes

Treat the later state as a new baseline unless the card was the isolated variable.

What remains unverified

Complete version 1.0 draw pools, rarity mapping, weights, refresh behavior, duplicate handling, progression gates, and card-specific values were not published in the checked sources. This page assigns none of them.

The next reliable step is a released-build choice log. Keep the record small, complete, and dated so later observations can be compared without erasing their conditions.

Official source

Frequently asked questions

What card choices are officially verified?

The Steam description says players draft units and Totems, and official promotional media shows a card-style choice screen. The checked sources do not publish complete draw or rarity rules.

Does a promotional screenshot prove version 1.0 values?

No. Promotional media verifies what the pictured interface shows, not every rule behind it or the values in a released build. Keep image observations separate from tested behavior.

How should I log a draft choice?

Record the build, offered choices, selected card, relevant army state, and later observation. Avoid crediting one choice for an outcome when several other variables changed.