Developer’s Eye Vol.6 Hades

死ぬたびに”物語が進む”、ローグライクの再発明

■ 1. ゲーム概要
■ 購入先・プレイ環境（2026年7月4日時点）
■ 公式PV
■ 2. 開発者が注目した”一点突破の面白さ”
■ 3. その面白さを開発者視点で分解する
■ 4. 設計思想の推測（開発者視点）
■ 5. 制作に応用できるポイント（Unity/Unreal で再現する場合の構造案も）
■ 6. まとめ：このゲームは”作り手の教材”である
■ 参考文献（一次情報）
■ 著作権表記

■ 1. ゲーム概要

Hades

開発：Supergiant Games
ジャンル：ローグライク・アクションRPG
プレイ時間：クリアまで20時間前後、やり込みは無制限
特徴：何度死んでも最初からになる”周回”そのものを、キャラクターとの関係性が進んでいく物語装置に変えたゲーム
開発エンジン：自社製カスタムエンジン（『Bastion』以来使ってきたC#・XNAベースの自社エンジンを、本作の開発中にC++＋The Forgeフレームワークベースへ全面刷新）

■ 購入先・プレイ環境（2026年7月4日時点）

販売先	リンク
Steam	store.steampowered.com/app/1145360
Microsoft Store（Xbox / PC）	xbox.com/ja-JP/…/hades

Xbox Game Pass：対象（Essential・Premium・Ultimate に含まれる） Xbox公式ストアページ（日本版）で「Xbox Game Pass Essential、Premium、Ultimate でクラウドプレイ可能なゲームが含まれています。」の表示を確認済み。Game Pass加入者は追加課金なしでプレイできます。続編『Hades II』も同じくGame Pass対象です。

■ 公式PV

■ 2. 開発者が注目した”一点突破の面白さ”

死んでも、プレイヤーが積み重ねた”知識”と”関係”は失われない。

ローグライクは通常、死ぬたびにすべてがリセットされる。Hadesはこの前提をそのまま受け入れつつ、キャラクター同士の会話や関係性の進展だけは死んでも失われないようにした。Supergiant Gamesのクリエイティブディレクター Greg Kasavin は、GameHub掲載のインタビューで「髪型や新しい靴のような小さな変化に誰かが気づいて気にかけてくれるのは嬉しいものだ。自分たちのゲームは、その感覚に相当するものを持たせようとしている」と語っている。

■ 3. その面白さを開発者視点で分解する

● ① 「何度も見た」こと自体を演出に変える

Kasavinは同インタビューで、「ローグライクで最もハードコアな形——死ぬたびに完全に最初からになる形——であっても、プレイヤーは知識だけは持ち越している」と述べている。ボスと2回目に対峙する時点で、それはもう「初対面」ではない。この”プレイヤー側の記憶”を前提に会話やイベントを設計している点が、Hadesの物語がローグライクの周回構造と衝突しない理由になっている。

● ② 前作の反省から生まれた設計

Wikipediaの記述によれば、Supergiantは前作『Pyre』で分岐する物語を作ったが、プレイヤーが同じ物語を何周もプレイしてくれないという課題に直面した。ローグライク構造であれば、周回そのものが前提になっているため、分岐する物語を無理なく提示できる——という発想がHadesの出発点になっている。

● ③ アーリーアクセスを”物語調整”の手段にする

RPG Siteのインタビューで Kasavin は、Hadesの開発方針をアーリーアクセスにすると最初に決めたのはPyre発売直後のことだったと語っている。プレイヤーからのフィードバックを反映しながら物語とゲームデザインを磨き上げたことが、同作を「Supergiant史上最も成功したタイトル」にした要因の大部分を占めるとしている。

● ④ エンジンをゼロから作り直す決断

Wikipediaによれば、Hadesの開発中、SupergiantはC#・XNAベースの自社エンジン（『Bastion』以来使用）の限界——特に移植性とパフォーマンス——に直面し、C++と『The Forge』フレームワークをベースにしたエンジンへの全面書き直しを決断している。ジャンルを問わず長年使ってきた技術基盤を、必要と判断すれば作り直すという姿勢がうかがえる。

■ 4. 設計思想の推測（開発者視点）

検証できる発言から見えてくる Supergiant Games の設計思想は、次のように整理できる。

ジャンルの前提を壊さず、上に物語を重ねる：ローグライクの”リセット”はそのままに、プレイヤーの記憶と関係性だけを持続する資産にする
前作の反省を次作の土台にする：分岐する物語が活きる構造（周回前提のジャンル）を選び直す
プレイヤーの声を物語調整に使う：アーリーアクセスを単なる先行販売でなく、フィードバックを取り込む開発プロセスとして活用する

■ 5. 制作に応用できるポイント（Unity/Unreal で再現する場合の構造案も）

● ① 「周回前提」のジャンルに会話進行度を乗せる

ローグライク・ローグライトを作る場合、死亡時にリセットする要素と、しない要素（会話履歴・関係値・世界の知識）を明確に分けて設計すると、Hades的な”死んでも進む”感覚に近づけられる。Unityなら、セーブ対象外のランタイムデータと、永続化するScriptableObject／セーブファイルを最初から分離しておくと実装しやすい。

● ② 同じイベントの”2回目”を設計する

キャラクターとの再会シーンやボス戦の再戦時に、初見と異なる台詞・リアクションを用意するだけでも、プレイヤーの「もう知っている」という感覚を演出に活かせる。台詞データを「初回用」「2回目以降用」で分岐管理する設計は、小規模開発でも導入しやすい。

● ③ フィードバックを取り込む開発体制を作る

アーリーアクセスやクローズドテストを、単なる先行体験の場ではなく、物語やバランスを継続的に調整する仕組みとして設計する。小規模チームでも、Discordコミュニティ等を使って同様のサイクルを回すことは可能。

■ 6. まとめ：このゲームは”作り手の教材”である

Hades は、「ローグライクの”死んでリセットされる”という前提を壊さずに、その上に物語を乗せる」という発明によって、周回プレイそのものを飽きさせない構造に変えたゲームだ。前作の反省、アーリーアクセスでの調整、そしてエンジンをゼロから作り直す決断——いずれも、ジャンルと技術基盤の両方を疑い続けた開発姿勢の表れと言える。

■ 参考文献（一次情報）

■ 著作権表記

© Supergiant Games / Hades
本記事内の開発者コメントは上記一次情報を要約・翻訳したものであり、逐語引用は最小限（15語未満・出典1件につき1箇所まで）に留めています。