Card game deck mana curve calculator

This mana curve calculator turns a decklist into a clear distribution from zero through seven or more mana, weighting every row by its number of copies. It also compares the result with a broad, general-purpose reference shape and highlights large differences. The result gives deck builders a fast diagnostic without pretending that one curve is correct for every game, format, strategy, or resource system.

Enter the deck as cards and copy counts

Add one row for each distinct card and provide its name, mana cost, and number of copies. The copy count defaults to one, but entering it explicitly makes a full decklist easier to audit. Mana cost must be a whole number of zero or more. Use the printed cost unless your game or deck-building process has a consistent reason to use an effective cost instead. Cards costing seven or more are combined into one top-end bucket, since their shared deck-building question is usually whether the deck can afford enough expensive plays. Zero-cost cards remain visible in their own bucket. If a game treats lands or resource cards as zero-cost deck entries, include them only when you actually want those cards to influence the displayed distribution; otherwise omit them and interpret the curve as the spell or action curve. The calculator multiplies each cost by its copy count, so four copies contribute four cards rather than one row. An empty decklist is rejected because percentages and an average cost would have no meaningful denominator. Names help identify rows but do not change the arithmetic, and repeated names are counted as separate submitted rows rather than silently merged or discarded.

Read the distribution and the comparison

The output reports the total number of cards, the copy-weighted average mana cost, and eight curve buckets: zero, one, two, three, four, five, six, and seven or more. Every bucket includes its card count and percentage of the submitted deck. It also shows a general-purpose reference percentage and the signed difference in percentage points. Positive differences mean the deck carries more cards at that cost than the reference; negative differences mean it carries fewer. A bucket is marked as greatly deviating when the absolute difference reaches ten percentage points. The overall flag turns on when at least one bucket crosses that threshold, and flagged_costs tells you exactly where to look. This comparison is deliberately transparent: the reference totals one hundred percent and favors a rise into the two- and three-cost range followed by a taper toward expensive cards. It is a diagnostic baseline, not a rulebook. A low-cost aggressive deck, a control deck with acceleration, or a game with unusual resource mechanics may deviate for sound strategic reasons. Use the flags to prompt questions about playability, not to replace testing or format knowledge.

Turn a flagged curve into useful deck changes

Start with the earliest flagged bucket because early turns often determine whether the rest of a hand becomes usable. If one- and two-cost percentages are far below the reference, review opening hands and count how often the deck has a legal early play. If the seven-plus bucket is high, check whether those cards have alternate costs, resource acceleration, or enough game-ending impact to justify drawing several together. Do not automatically cut every card in an overfilled bucket. First identify each card's role, then preserve the roles the deck must perform while shifting replaceable effects toward a healthier cost. Likewise, a missing bucket is not automatically a defect when the game's rules or the deck's plan intentionally skip that turn. Compare revisions by rerunning the same list after each change, and validate the proposed curve through sample hands and actual matches. The average cost is a helpful summary, but two decks can share an average while having very different distributions, so inspect the individual buckets as the primary evidence. Because the method is deterministic, identical decklists always return identical results, making it suitable for build reviews, automated checks, and before-and-after records in a deck-testing workflow.