『Slay the Spire 2』開発チームが語るバランス設計――まずは「カッコよくて楽しい」カードを作り、そのあとで思いきり壊してもらう
2026年3月初に早期アクセス開始予定のデッキ構築型ローグライク新作『Slay the Spire 2』について、開発元のMega CritがRedditでAMAを実施。続編に関するさまざまな質問に答えるとともに、シリーズで高く評価されてきた「バランス設計哲学」について、これまでで最も踏み込んだ説明を行った。
開発チームは、「最初から完璧な数値バランスを計算し尽くすことは目指していない」と率直に語る。むしろ出発点は「見た目がクールで、遊んでいて楽しいかどうか」という直感だという。そのうえで大量のテストプレイを重ね、徐々に数値を磨き上げていくスタイルを採用。さらには、プレイヤーが強力なコンボを発見し、ゲームを“壊す”ような体験を生み出すことすら歓迎していると明かした。
初代『Slay the Spire』は2017年にSteamで早期アクセスを開始し、2019年に正式リリース。高い戦略性とリプレイ性で圧倒的な評価を獲得し、その後のデッキ構築型ローグライク作品に大きな影響を与えた。
続編『Slay the Spire 2』も基本システムを踏襲しているが、今回のReddit AMAでは、ユーザーのoneflouが「シリーズの優れたバランスをどう維持しているのか？ プレイヤーにゲームを“壊される”ことを恐れないのか？」と質問した。
これに対し、Mega Critのリードプログラマー、Jake Cardは、『Slay the Spire 2』のバランス調整プロセスは前作とほぼ同じで、実は非常にシンプルだと説明している。
まずは「聞いただけでワクワクする、遊んでいて楽しいカード」を考案。そこにデザイナーの直感をもとに“それらしく妥当に見える”初期数値を設定する。その後、開発メンバー自身がプレイしてサニティチェック（基本的な動作確認）を行い、仕組みが正しく機能しているかを確認。さらに専門のQAチームによる集中的なテストへと進む。
Mega Critでは毎週、新カードの追加や既存カードの調整を含むテストビルドを用意し、テスターの反応を観察。評価は大きく2つの軸で行われる。
ひとつは主観的な観点――「そのカードは本当に楽しいか」。
もうひとつは客観的データ――「そのカードを含むデッキの平均勝率は、全体平均から大きく乖離していないか」。
結果が芳しくなければ、数値の微調整、あるいはカードの全面的な作り直しを実施し、再びテストサイクルへ戻る。
こうした反復的なアプローチにより、バランス調整は単なる数値管理ではなく、プレイヤーの感情や体験まで考慮した“手作業の研磨工程”として進められているという。
興味深いのは、Mega Critがプレイヤーによる“システムの攻略”を恐れていない点だ。むしろ、ゲームを壊すほどのコンボを見つけ出すこと自体が楽しさの一部だと考えているという。
Jake Cardは、チームとしてはむしろ「プレイヤーに壊してほしい」と語る。カードゲームの醍醐味のひとつは、開発側が想定していなかったシナジーを発見し、とてつもなく強力なビルドを生み出す瞬間にあるからだ。
ただし、ある組み合わせが強すぎて他の戦略の存在意義を奪ってしまう場合は話が別。そのときは共同創設者のAnthony Giovannettiが“お気に入りの仕事”であるナーフ（弱体化）を実行するという。ややユーモラスに語られたこの発言からは、「強さは許容するが、単一解に支配させない」というチームのバランス観がうかがえる。
物理的なカードゲームでは環境の即時修正が難しいが、デジタル作品ではアップデートによって迅速な調整が可能だ。初代『Slay the Spire』は早期アクセス期間中、毎週アップデートを行う「Weekly Patch」を長期にわたり継続。約1年にわたりPatch 56まで積み重ねた末に正式版をリリースしており、まさにプレイヤーフィードバックとともに完成へと近づいていったタイトルだった。
ローグライクというジャンル特性上、毎回のプレイが新たな挑戦となるため、頻繁なバランス調整も比較的受け入れられやすい。これこそが、シリーズが継続的に最適化を重ねられてきた大きな理由のひとつといえる。
バランス設計の話題に加え、AMAでもうひとつ注目を集めたのが、『Slay the Spire 2』が開発エンジンをUnityからGodotへ移行した経緯だ。
Mega Critの共同創設者であるCasey Yanoは、Godotのノードベース構造がUnityと似ていたため、移行は想像よりスムーズだったと説明。一方で、開発当時はまだ実装途中の機能もあり、チームが独自に代替機能を書いたり、エンジン側のアップデートを待ったりする場面もあったという。
また、Jake Cardは、チームが早い段階でUnityのScriptable ObjectシステムからC#クラスへとゲームデータ構造を移行し、自動テストツールも整備していたことを明かした。
その結果、ゲームのコアロジックが描画処理や入力システムから独立していたため、Godotへの切り替えを決断した際も、大量のコードをほぼそのまま再利用できたという。設計段階での分離構造が、エンジン移行コストを大きく抑える要因になった形だ。