Slay the Spire型ローグライクカードバトル
アーキテクチャ設計と商用化プロセス

本レポートは、商用化を前提とした Slay the Spire 型ローグライクデッキビルダーの開発に必要な アーキテクチャ設計の全体像 と、企画から Steam リリース後運用までの開発プロセス を整理したものです。エンジン選定、コアゲームアーキテクチャ、データ駆動設計、Mod対応、 バランス調整、チーム規模・予算・スケジュール、リリース戦略の各観点で実務的な指針を示します。

1. ジャンル特性と市場ポテンシャル

ローグライクデッキビルダーは 「インディーで最も商業的に成功しやすいジャンル」 と評されつつも、Slay the Spire・Monster Train・Inscryption・Balatro 等の成功作の影に 多数の埋没作があります。Slay the Spire 2 や Balatro の登場でジャンル全体が再加熱しており、 2026年現在も新規参入の余地はあるものの、明確な差別化軸（テーマ性・メカニクス・テンポ） なしでは中央売上の壁を超えられません。

2. エンジン選定（Unity / Godot / 自作）

実務上の 推奨は Godot 4.x（小規模） / Unity 6（中規模・コンソール志向） の二択です。ホットリロードの差は数百回のイテレーションで効いてきます。 Slay the Spire 1 が LibGDX、続編 Slay the Spire 2 が Godot を選んだ事実そのものが、 2026年時点のジャンル定石を示しています。

3. コアアーキテクチャ：3層構造 + Action Queue

Slay the Spire 系のターン制カードバトルは、UI/演出と戦闘ロジックを密結合すると バランス調整・Mod対応・テストの全てが破綻します。商用品質では以下の 3層分離 が事実上の標準です。

3.1 Action Queue（命令キュー）

カード使用 → ダメージ → 状態異常付与 → 反応 → ドロー、といった連鎖を 1フレームで全解決 すると不正な状態遷移が起こります。Slay the Spire 系では、すべての効果を GameAction として キューに積み、毎フレーム1〜N個ずつ消化する Action Queue パターン が定石です。

// 概念コード
queue.push(new DamageAction(target, 6));
queue.push(new ApplyPowerAction(target, "Vulnerable", 2));
queue.push(new DrawCardAction(player, 1));
// → CombatState.update() がキューを順に解決し、
//    各解決後に EventBus.publish(CardResolved/DamageDealt/...) で View に通知

3.2 EventBus（疎結合のイベント配信）

レリック・パッシブ・状態異常の効果は 「いつ・何が起きたら発動するか」 という反応型ロジックです。 Domain 層が OnDamageDealt / OnCardPlayed / OnTurnStart 等を EventBus に publish し、効果側が subscribe する構成にすると、効果同士の組み合わせ爆発を回避できます。

3.3 ECS は使うべきか

結論：ECS は本質的には不要。Slay the Spire 系は同時アクティブなエンティティ数が 数十〜百程度で、ECS のキャッシュ効率の恩恵を受けません。 OOP + Composition + EventBus の組み合わせの方が、カードや効果の表現力で勝ります。 ただし大量Mob戦が中心の派生ジャンル（例: Vampire Survivors型の派生）なら ECS を検討する余地があります。

4. カードシステムと効果定義

4.1 データ駆動 vs スクリプト埋め込み

カード数が100枚を超えるあたりから、「カード = データ + 効果ID列」 という データ駆動アプローチでないと運用不能になります。設計選択肢は3つあります。

4.2 カードデータの最小スキーマ例

{
  "id": "strike_basic",
  "name_key": "card.strike_basic.name",
  "cost": 1,
  "type": "attack",
  "rarity": "starter",
  "target": "single_enemy",
  "effects": [
    { "op": "damage", "value": 6, "scaling": ["strength"] }
  ],
  "upgrade": { "effects": [{ "op": "damage", "value": 9 }] }
}

name_key をローカライズキーにし、テキスト本体は別ファイルに分けるのが基本です。 効果の op を有限個のプリミティブ（damage / block / draw / apply_power / energy / discard / exhaust …） に絞ると、ロジック側のテストが網羅可能になります。

5. マップ生成・シード・セーブ設計

5.1 シードRNG

ローグライクは 「同じシードで同じラン」 を保証するのが原則です。 System Random を直接使うと再現性が破綻するため、独自のSeededRandom をラン全体で使います。 さらに、用途別に分割したRNGストリーム（マップ用 / カード報酬用 / 敵パターン用）を 持たせると、ある乱数消費の追加が他系列に影響するのを防げます。

5.2 マップ生成

Slay the Spire のフロアマップは「列数固定 × 列内ノード数可変 のDAG」を パス再帰生成 + 後処理（交差排除・最終ボス強制収束）で作る方式です。 生成ロジックは Domain 層に閉じ込め、UI は 生成済みノード列 を受け取って描画するだけにします。

5.3 セーブシステム

商用品質では以下の3点が必須です。

• 継続セーブ：ランの途中で中断 → 再開できる必要がある（戦闘途中も望ましい）
• バージョン互換：パッチ後に旧セーブを読めるよう schema_version + マイグレーション関数
• 改竄検出：実績解除に関わるためHMAC等で軽い検証（チート対策ではなく事故検出）

セーブ対象は「ラン状態」「永続メタ進行」「設定」「実績」の4ファイルに分離し、 Steam Cloud と互換のあるシンプルなファイル名規約（例: save_slot_1.dat）にします。

6. データ駆動バランス調整

Slay the Spire 開発チームは、少人数では数百枚のカードを手動で調整できないと判断し、 「カードを束（archetype）で追加 → メトリクスで彫刻する」 方式を採用しました。 商用化を狙う以上、リリース直後からこの仕組みが必要です。

6.1 必須テレメトリ

• 各ランの完全なログ（シード・選択履歴・取得カード・ボス勝敗）
• カード単位のピック率・勝率・出現フロア分布
• レリック単位の獲得率・勝率寄与
• 難易度（Ascension相当）別の勝率カーブ
• クラス別プレイ時間分布

6.2 オプトインとプライバシー

PII（個人特定情報）を含めない・初回起動でオプトイン確認・ストアページとプライバシーポリシーで明示 の3点はEU/カリフォルニア州規制およびSteam規約上で必須です。

7. Mod対応アーキテクチャ

Slay the Spire の長寿は BaseMod / ModTheSpire を中心とするMod文化 に支えられました。 商用ローグライクデッキビルダーが2024年以降、ジャンル平均より長くプレイされる条件として Mod対応はほぼ必須要素です。設計選択肢は次の通り。

実務的な推奨は 「JSON-onlyデータMod + 限定的なLuaフック」 のハイブリッド構成。 Cardの追加・差し替えはJSON、特殊効果のみLuaフック関数で記述させる方式が、 導入のしやすさと表現力の両立に最も近づきます。

8. 開発プロセスとチーム構成

8.1 推奨チーム構成

8.2 予算とスケジュールの目安

9. Steamリリース・価格戦略

9.1 リリースまでの流れ

1. Steamworksアカウント作成（個人 or 会社）
2. Steam Direct手数料 $100（売上$1,000で実質返却）
3. 納税書類W-8BEN等提出（米国外開発者）
4. ストアページ作成 → Valveレビュー（合法性チェック、品質判定ではない）
5. Steam Next Festへのデモ出展（露出最大の機会、年3回）
6. Wishlist 7,000以上を目標にプロモーション
7. リリース → 初週10〜20%割引で可視性アルゴリズムに乗せる

9.2 価格と収益分配

9.3 Early Access戦略

Slay the Spire・Hades・Dead Cells の3作はいずれも Early Access期間に売上の半分以上を獲得 しています。デッキビルダーは「コミュニティとカードを作る」相性が極めて良く、EA期に 「カード追加バッチ」を月次で更新するロードマップが定石です。

10. リスクと落とし穴

• Slay the Spire 模倣の罠：マップ・3行情報・ペルソナ構成までそっくりだとレビューで叩かれる。 最低でもメカニクスかテーマで1点の独自性を立てる
• カード爆発症：効果プリミティブの種類を抑えないと、テスト不能・バランス不能・Mod困難の三重苦
• UI演出の後回し：戦闘の「気持ち良さ」は8割演出。Domain層を作り切ってからUI、ではEA時の評価が伸びない
• Mod対応の後付け：1.0後にAPIを切り出すのは事実上不可能。最初からデータ駆動にしておく
• マルチプラットフォーム前提の遅延：iOS版・Switch版を並行で作ると失敗する。PC先行→1年後移植が安全
• テレメトリ未実装でのリリース：1.0後のバランス調整が「Twitterの怒り」ベースになる

11. 推奨ロードマップ（12ヶ月モデル）

12. 結論

Slay the Spire 型ローグライクデッキビルダーの商用化において、技術的成功の鍵は 「Domain と View の徹底分離」「データ駆動カード定義」「EventBus + Action Queue」「シードRNGとテレメトリ」 の4点です。これらは初日から組み込まれていなければ、後付けでは機能しません。

ビジネス的成功の鍵は 「1点の独自性」「Early Access期のコミュニティ運営」「データ駆動バランス調整」 の3点。技術と運営の両方が噛み合って初めて、ジャンルの中央売上を超えられます。 エンジンはGodot 4またはUnity 6、チームは2〜6名、予算$50k〜$800k、期間12〜30ヶ月が 現実的なレンジです。

主要参照情報

• GDC Vault「Slay the Spire: Metrics Driven Design and Balance」
• Game Developer「How Slay the Spire's devs use data to balance their roguelike deck-builder」
• Wikipedia「Slay the Spire」「Roguelike deck-building game」「Entity component system」
• BaseMod / ModTheSpire ドキュメント（GitHub）
• guladam/deck_builder_tutorial（Godot 4 STSクローン解説）
• Game World Observer「Roguelike deckbuilders beat all indie genres on Steam」（2022）
• Ziva「How to Publish a Game on Steam in 2026」
• Datahumble「Steam Game Pricing Strategy 2026」
• Juego Studios / SteamPageAnalyzer「Indie Game Development Cost 2026」
• Cogmind / Grid Sage Games「Working with Seeds」
• RogueBasin「Random number generator」
• Breach.gg「Slay the Spire 2 Co-op Breakthrough」（2026年3月）