Skip to content

Challenge Matters (challenge-trigger payoffs + denial) rule candidate (72 cards, 6 inks) #371

Description

@Doberjohn

Mechanic

Cards that reward the act of challenging (or surviving one): "Whenever one of your characters challenges another character, gain lore / draw / deal damage", "Whenever this character banishes another character in a challenge, gain lore", and the templated "When this character is banished in a challenge, return this card to your hand" resilience line. The counter-axis is challenge denial: "chosen opposing character can't challenge". Together this is the third combat-trigger axis alongside the two already-open candidates (Banish Matters #365, Damage Matters #368), exactly the payoff-rich axis the #363 payoff-aware ranking was built to surface.

This mechanic is not in REMOVED_RULES.md as its own rule. Two narrow, adjacent slices were removed and are worth weighing: challenger-buffs (the Challenger keyword + raw strength buff pairing) and ward-aggro (Ward + challenge/ready). Both were dropped for being too generic. Challenge Matters is a different, bounded axis: it keys on challenge-trigger payoffs (lore / draw / recur / damage), not on stat buffs or keyword presence.

Coherence caveat (read before scoping)

"Challenge" is Lorcana's core combat verb, so the raw miner phrase cluster is a grab-bag. Reading the cards splits it into three groups:

  1. Pro-challenge payoff (coherent core, 57 cards): rewards challenging or trading in combat.
  2. Challenge denial (15 cards): stops opposing characters from challenging. A related but defensive counter-axis.
  3. Self-drawback (3 cards, exclude): "This character can't challenge" as a downside (e.g., Bodyguard tax on Chief Powhatan, Percy's "ICE BATH"). These must be filtered out, same way the location rules exclude anti-location cards.

The rule must detect payoff/denial triggers, not "any card that can challenge", or it falls into the good-stuff trap (nearly every character can challenge). Detection should anchor on the trigger phrases below, not on the Challenger keyword alone.

Category

playstyle (density-based, two-sided). New playstyle challenge (suggested id). Does not fit an existing playstyle.

Roles

  • payoff (aggressive): challenge-trigger rewards (whenever ... challenges another character, banishes another character in a challenge) plus banished-in-a-challenge recursion (when this character is banished in a challenge, return ... / draw / gain lore).
  • enabler / grant: hands out Challenger, Evasive, or the "return when banished in a challenge" template to your team so a body challenges safely and profitably (Forest Duel, Magical Aid, Mother Gothel).
  • denial (control): prevents opposing characters from challenging (chosen opposing character can't challenge).

Score matrix (5-baseline)

Pair Score Justification (one sentence)
payoff ↔ payoff 5 Same-axis density: multiple challenge rewards stack in one aggressive deck without compounding.
enabler ↔ payoff 6 Complementary: the grant makes a body challenge safely/repeatedly, and the payoff cashes that challenge into lore, cards, or damage.
grant-recur ↔ recur-payoff 7 Mechanical compounding: granting "return when banished in a challenge" turns every losing trade into a repeatable challenge engine that keeps re-firing the payoff.
enabler ↔ enabler 5 Parallel: both push aggressive combat, no per-card compounding.
denial ↔ payoff 5 Parallel game plans: denial shields your attackers but does not amplify the payoff trigger.
denial ↔ denial 5 Same-axis control density: stacking challenge locks.

Reviewer option: the tight grant-recur combo (e.g., Forest Duel granting team-wide recur next to a lore-on-challenge payoff) is arguably a win condition and could be elevated to 8 if scoped narrowly. Held at 7 here because the enabler side is fuzzy (good-stuff risk), keeping the headline conservative per the audit rule.

Explanation templates

  • payoff ↔ payoff: Both turn challenges into value. Aggressive density baseline.
  • enabler ↔ payoff: {A} grants Challenger/Evasive so your characters trade up, fueling {B}'s challenge payoff.
  • grant-recur ↔ recur-payoff: {A} gives your characters "return when banished in a challenge," so every trade comes back and keeps firing {B}'s payoff.
  • denial ↔ denial: Both stop opposing characters from challenging, locking down their board.

Overlap check

  • vs Banish Matters (Banish Matters (sacrifice) rule candidate (68 cards, 6 inks) #365, open): "banished in a challenge" payoffs touch banish, but the trigger is combat (a challenge), not a sacrifice or removal effect. Recommendation: banished-in-a-challenge cards belong to Challenge (combat-triggered), not Banish (sacrifice / self-banish cost). The reviewer must set this boundary to avoid double-classification.
  • vs Damage Matters (Damage Matters (ping + damaged-payoff) rule candidate (115 cards, 6 inks) #368, open): minor. Mad Hatter ("damaged character challenges, draw a card") and Yzma ("banishes in a challenge, deal 1 damage") brush damage, but the trigger is the challenge, not damage state.
  • vs removed challenger-buffs / ward-aggro: those were narrow keyword-anchored slices removed for being generic. Challenge Matters keys on challenge-trigger payoffs, a distinct and bounded axis.

Evidence (from the miner)

Engine-as-oracle run, 1633 cards, 636 uncovered. Three phrase clusters collapse onto this axis:

Phrase Card hits Ink spread Score
in a challenge 21 Amethyst, Steel, Ruby 1016 (rank #7)
challenges another character 5 Ruby, Emerald, Steel 496
can t challenge 10 Steel, Amber 468

Full-pool scan after role classification: 57 payoff + 15 denial = 72 distinct cards across all 6 inks (3 self-drawback cards excluded). This is the top novel mechanic in the report. Everything ranked above it is already covered by the open Banish (#365) and Damage (#368) candidates. payoffCount reads 84 (highest in the report) but is keyed by anchor word, so treat it as corroborating, not decisive: the coherence above comes from reading the cards.

Sampled cards (id, snippet):

Payoff:

  • 1390 Calhoun - Marine Sergeant: "whenever this character banishes another character in a challenge, gain 2 lore."
  • 1140 Yzma - Unjustly Treated: "whenever one of your characters banishes another character in a challenge, you may deal 1 damage to chosen character."
  • 1621 Fa Zhou - War Hero: "Whenever one of your characters challenges another character, if it's the second challenge this turn, gain 3 lore."
  • 1503 Kenai - Magical Bear: "when this character is banished in a challenge, return this card to your hand and gain 1 lore."
  • 1493 Bucky - Nutty Rascal: "When this character is banished in a challenge, you may draw a card."
  • 1323 Maui - Half-Shark: "Whenever this character challenges another character, you may return an action card from your discard to your hand."

Enabler / grant:

  • 1741 Forest Duel: "Your characters gain Challenger +2 and 'When this character is banished in a challenge, return this card to your hand' this turn."
  • 1019 Magical Aid: "Chosen character gains Challenger +3 and 'When this character is banished in a challenge, return this card to your hand' this turn."
  • 1734 Mother Gothel - Knows What's Best: grants Challenger +1 and the recur line to one of your characters.

Denial:

  • 1128 Jafar - Tyrannical Hypnotist: "Opposing characters with cost 4 or less can't challenge."
  • 2649 Dr. Hamsterviel - Infamous Scientist: "When you play this character, chosen opposing character can't challenge during their next turn."
  • 2666 Containment Unit: "choose a character. They can't challenge or quest while this item is in play."

Next step

Implement through /implement-issue <this-number>, then /inkweave-add-rule. The add-rule workflow should tighten detection (anchor on the trigger phrases, exclude the 3 self-drawback "this character can't challenge" cards), settle the Banish-overlap boundary for banished-in-a-challenge cards, and decide whether the grant-recur combo earns the 8 tier.

Metadata

Metadata

Assignees

No one assigned

    Labels

    engineSynergy enginerule-candidateAuto-mined uncovered-mechanic candidate for a new synergy rule

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions