Skip to content
DEMO VERIFIEDOfficial source

Orc Incremental Totem Stacking

What Demo v0.09 confirms about Totem stacking and special-case tooltips, plus a controlled observation protocol that does not invent additive or multiplicative formulas.

Published
Updated
Last checked
Animated High Shaman vendor holding a staff in a tall bear headdress

Quick facts

Verified statement
Demo v0.09 says Totems stack and Totems with special stacking behavior have additional explanatory tooltip text.
Build boundary
Demo v0.09
Named context
Amber Bear + Ancient Idol
Formula status
exact additive formula; exact multiplicative formula
Evidence check
2026-08-28

Keep the Demo label attached

The registry summary gives the complete safe statement from Demo v0.09. Everything on this page follows from that historical boundary. It does not claim that version 1.0 uses the same operation, and it does not choose between mathematical models that the note never states.

The distinction matters because several different operations can produce an increase when another copy is added. A larger displayed result alone does not identify the rule. Rounding, another active bonus, acquisition order, or a special tooltip can all change what the player sees.

The High Shaman hero is promotional vendor art. It fits the Totem topic, but it does not document the stacking operation. No value or rule is inferred from the character, staff, animation, or headdress.

Separate three questions

Start by separating the questions that often get compressed into “how does stacking work?”

  1. Does another copy change a displayed or observed result?
  2. Does the order of copies matter?
  3. Does the current tooltip describe a special case?

The first question can be tested with a same-type comparison. The second needs two otherwise matched acquisition sequences. The third is a text record: copy the exact tooltip from the named build before interpreting it.

Answering one question does not answer the other two. Two copies producing a larger result confirms a change in that case. It does not show whether the game applied a sum, a product, a cap, a replacement rule, or an effect elsewhere in the calculation.

Same-type observation protocol

Use a stable displayed measure when the interface provides one. If no relevant measure is visible, choose a repeatable battle outcome and state why it is only a proxy.

StageRecord before proceeding
BaselineBuild, army, encounter, relevant tooltip, and visible measure
First copyFull card text, acquisition order, and the same measure
Second copyFull card text, acquisition order, and the same measure again
ReplaySame encounter with no other purchase or position change
RepeatA second acquisition sequence when the game permits it

Do not buy another upgrade between rows. Do not rearrange the army. Do not switch encounters and then compare the results as if the conditions were equal. The goal is to isolate the copy count before explaining the output.

If the measure changes, write the literal before-and-after values in your private field note. This guide deliberately does not publish a derived formula from the old source. A current formula belongs in a later update only after the build, inputs, rounding behavior, and repeated output can be checked.

The card-choice logging guide explains how to capture the full offer. The Totem source hub explains why a dated card or patch note cannot define final balance.

Special tooltip protocol

Special-case text needs its own record. Capture the entire tooltip, not a cropped phrase. Include the Totem name, copy count, build, language, and the event that made the text appear. If the text changes after the second copy, preserve both states.

Then test the smallest case that the tooltip describes. Keep the rest of the army fixed and repeat the same encounter. If the wording names another Totem, record whether both were present and in which order they were acquired.

A tooltip can establish an intended exception more directly than a guessed equation. Even then, it may omit rounding, timing, caps, or how another system consumes the result. Report the text first and the observation second.

The Amber combination context

Demo v0.09 contains a named pair in a bug-fix sentence. That is enough to establish combination context for Amber Bear and Ancient Idol in that historical build. It is not enough to write either card's normal effect, nor does it reveal how the pair changes a calculation.

For a later build, treat the pair as a new observation:

  • capture both current cards before selecting them;
  • note acquisition order;
  • save the special tooltip if one appears;
  • record the same visible measure before and after the pair;
  • repeat without another purchase in between.

The old sentence can explain why the pair deserves a controlled check. It cannot supply the expected result.

Interpreting outcomes without declaring math

Use bounded wording. “The displayed measure increased after the second copy in build X” is an observation. “The effect always adds” is a mechanic claim. The second statement needs stronger evidence because it predicts cases beyond the one you saw.

When two plausible operations fit the same small sample, design another input that would make their predictions differ. If the interface prevents a clean comparison, keep both explanations open. A result can still help players reproduce behavior without pretending that the hidden operation is known.

Rounding deserves its own field. Record the displayed precision and whether an intermediate value is visible. A rounded display may hide differences between operations, especially when the sample is small.

Common mistakes

Changing several variables is the quickest way to lose the answer. A new copy, a new unit, a new position, and a new encounter in the same run create many explanations for one result.

Another mistake is treating ordinary English as mathematical notation. Words such as “stack” and “bonus” describe a relationship, but they do not select one equation. Use the source's wording without adding an operator.

A third mistake is applying the Demo result to version 1.0. The old note remains useful history. The current build still needs its own tooltip and observation record.

A publishable report

A strong report contains the build, both card texts, acquisition order, fixed army, fixed encounter, displayed measure, repeats, and unresolved explanations. It can link to the build comparison worksheet when progression state matters, or to formation diagnosis when movement changed between attempts.

Publish the narrowest supported sentence. Keep the formula field empty until the game states it or the observation set distinguishes it reliably.

Official source

Verified stacking boundary

Name
Totem stacking
Boundary
Demo v0.09
Verified statement
Demo v0.09 says Totems stack and Totems with special stacking behavior have additional explanatory tooltip text.
Checked
Still unknown
exact additive formula, exact multiplicative formula, version 1.0 stacking behavior

Frequently asked questions

What is verified about Totem stacking?
Demo v0.09 says Totems stack and Totems with special stacking behavior have additional explanatory tooltip text. Exact formulas remain unverified, checked 2026-08-28.
What does the named Amber combination prove?
Demo v0.09 explicitly identifies Amber Bear as one half of a Totem combination with Ancient Idol. Demo v0.09 explicitly identifies Ancient Idol as one half of a Totem combination with Amber Bear. Those records establish combination context, not either general effect or an exact formula.
How can two copies be compared without assuming a formula?
Record the same displayed measure before either copy, after the first, and after the second while holding the army and encounter fixed. Describe the observed changes; do not label the rule additive or multiplicative until the game or a reproducible calculation proves it.
What should be captured for a special case?
Capture the full tooltip, both card identities, the build label, the order of acquisition, and the visible before-and-after result. Repeat the setup so a one-off timing change is not mistaken for a stacking rule.