Skip to content

Add bounded mana payment planner for costed mana abilities#11198

Open
Madwand99 wants to merge 11 commits into
Card-Forge:masterfrom
Madwand99:mana-payment-planner
Open

Add bounded mana payment planner for costed mana abilities#11198
Madwand99 wants to merge 11 commits into
Card-Forge:masterfrom
Madwand99:mana-payment-planner

Conversation

@Madwand99

@Madwand99 Madwand99 commented Jul 10, 2026

Copy link
Copy Markdown
Contributor

Adds a bounded best-first mana payment planner for cases the greedy mana payer cannot reliably handle, especially signets, filter lands, and restricted mana abilities.
The planner searches virtual payment states without tapping real permanents, tracks floating mana and used sources, then replays the selected mana abilities once a valid plan is found. ComputerUtilMana keeps the existing greedy path for normal payments and only escalates to the planner when needed, including cases where greedy payment would leave enough total mana but strand important colors for other spells in hand.
This also updates mana color choice handling so planned combo/chosen mana outputs are preserved when the chosen mana abilities are replayed.

Thanks to Codex for help with coding and many, many tests.

@tool4ever

Copy link
Copy Markdown
Contributor

Thanks though there's now also a "human contributed" attempt in progress: #11173

If that leads nowhere either I'll check out this new approach, though I probably won't be a big fan if this separate system duplicates things too much - but we'll see

@Madwand99

Copy link
Copy Markdown
Contributor Author

Thanks though there's now also a "human contributed" attempt in progress: #11173

If that leads nowhere either I'll check out this new approach, though I probably won't be a big fan if this separate system duplicates things too much - but we'll see

I notice that many of the tests on #11173 don't pass their code, and one of them is an invalid test. I'll be checking those tests to add some to my own test suite. So far I have 55 tests, with more on the way. Should I push these to this PR? Due to your own comments I have been keeping most tests to myself.

@Madwand99

Madwand99 commented Jul 10, 2026

Copy link
Copy Markdown
Contributor Author

Comparison with PR #11173

Size

Production changes are measured against each branch's merge base.

This PR PR #11173
Production LOC +1,102 / -45 +4,778 / -427
Net production LOC +1,057 +4,351
Architecture Separate planner class CastabilityProbe plus primarily ComputerUtilMana

This PR is substantially smaller: its latest branch now adds 4,351 net production lines, including 4,360 additions in ComputerUtilMana.

PR #11173 also includes +2,026 / -1 committed test lines. Our tests remain local for now but can be made available on request.

Test Results

The current local suite has 137 behavioral payment tests plus 11 planner-internal fallback/state-cap tests.

Test group This PR PR #11173
Original AutoPaymentTest cases (64) 64 passed / 0 failed 52 passed / 12 failed
Imported comparison cases (73) 73 passed / 0 failed 69 passed / 4 failed
Behavioral total (137) 137 passed / 0 failed 121 passed / 16 failed
Planner fallback/state-cap cases (11) 11 passed / 0 failed Not applicable

The 11 fallback/state-cap tests cannot compile against PR #11173 because it does not contain the ManaPaymentPlanner API. They therefore should not count as failures for that PR.

Shared Strengths

Both implementations pass tests covering:

  • Basic filter-land and Signet activation costs
  • Hidden Grotto correctly failing to cast Vigor
  • Lotus Petal activating a Signet when needed
  • Cascading Cataracts
  • Restricted creature mana
  • Many Treasure/disposable-resource cases
  • Equivalent-source scalability cases
  • The Yuna and Goldspan performance scenarios
  • The Weatherseed Treaty filter-land scenario
  • Preserving Gaea's Cradle when exact single mana is available elsewhere
  • Avoiding a redundant second Signet

Differences

PR #11173 fails 12 of the original behavioral tests. These include:

  • Chaining two Signets when the chain is necessary
  • Evendo's variable mana
  • Castle Garenbrig's additional creature-only mana
  • Cabal Coffers
  • Nykthos castability and simulated payment
  • A filter-land line where its extra mana can pay generic cost
  • Choosing needed colors from any-color sources
  • Preferring colorless mana over a colored land for generic cost
  • Reporting floating mana and floating activation-mana sources
  • Keeping non-tap, mana-costed abilities out of the simple mana-source list

Notably, PR #11173 still avoids a redundant second Signet, but cannot chain two Signets when that is the only valid payment. This PR passes both cases.

The remaining four PR #11173 failures are intentional source-policy differences in the imported comparison tests:

  • Preserve a white-capable source needed by a known white spell in hand
  • Preserve the only {C} source needed by Thought-Knot Seer
  • Use an off-color rock for generic mana to preserve a dual land
  • Preserve Lotus Petal when reusable mana can complete the payment

Those expectations were revised locally; they should not be treated as neutral regressions in PR #11173.

Architecture

This PR uses a bounded best-first search with virtual mana state, memoization, source equivalence, a hard state cap, and legacy fallback. It searches without mutating game state and returns a replayable payment plan.

PR #11173 adds nested and recursive payment handling around the existing payment logic, with a separate CastabilityProbe. Its current implementation is concentrated primarily in ComputerUtilMana; it does not provide the same explicit planner, exhaustion, fallback, or replay-plan boundaries.

@tool4ever

Copy link
Copy Markdown
Contributor

thanks for comparing

tests will in fact be needed however 148 is a completely unreasonable amount 👎 👎 👎

they need to be written around code knowledge so we're not just setting up lots of arbitrary scenarios that just cover the same logic

it would have been better to wait and then iterate on each case / deciding if initial support is worth it

@Madwand99

Copy link
Copy Markdown
Contributor Author

thanks for comparing

tests will in fact be needed however 148 is a completely unreasonable amount 👎 👎 👎

they need to be written around code knowledge so we're not just setting up lots of arbitrary scenarios that just cover the same logic

it would have been better to wait and then iterate on each case / deciding if initial support is worth it

Almost every test covers different logic and different cards. The tests are critical for defining what the code can do. We can certainly cut down on the final tests included, but for now the more tests we have, the more cases are covered. Picking a subset of test to keep will be quite challenging as almost any test left out will mean some kinds of cards aren't going to be covered.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants