UE5 + GAS で PvE 協力 ARPG の戦闘コアを組む — Dungeon Wanderers Phase 2 進捗

Dungeon Wanderers の戦闘設計思想

Dungeon Wanderers は 4 人協力 PvE のプロシージャルダンジョン ARPG です。Steam を主軸に、Listen Server 方式で小規模協力プレイを想定しています。

戦闘の核は「読み合いの気持ちよさ」。派手な演出より、回避・ガード・パリィという攻防の選択が噛み合う瞬間を大事にしたい。だから Phase 2 では、まず戦闘コアの骨組みを「手触りの軸」から定義しました。

Phase 2 はまだ完了ではありませんが、戦闘 GA 4 種の骨組みが揃った節目です。この記事ではそこまでの設計判断と実装手応えを整理します。

Unreal Engine の GameplayAbilitySystem(GAS)は学習コストが高いサブシステムですが、Dungeon Wanderers では Phase 1 から一貫して GAS 前提で設計しました。理由は単純で:

ARPG で後からマルチプレイを足すと、状態同期・予測・ロールバックのすべてが後付けになり、体感が劇的に悪化します。Lyra の設計思想を見て、最初から GAS ネイティブで組むと決めました。

この 4 つの攻防が噛み合うことで、「攻撃したい → でも敵が攻撃モーションに入った → ガードで凌ぐか、タイミングに賭けてパリィするか、回避で離れるか」という選択が毎瞬間発生する設計を目指しています。

この設計の背景には、過去プロジェクトでの失敗経験があります。

以前参加していた ARPG 案件ではサーバー権威一辺倒で戦闘を組み、同期の正しさは保証されていました。しかし、プレイヤー体感は壊滅的でした。ping 60ms 環境でも「ボタンを押してから反応が返ってくる」遅延が気持ちよさを完全に殺していました。

この経験から Dungeon Wanderers では設計原則を逆転させました:

特にパリィのようなタイミング駆動のメカニクスは、サーバー判定に回した瞬間に「入力したのに効かない」という体感崩壊が起きます。Parry だけはどうしてもローカル優先という制約が、戦闘全体の設計に一貫性を要求しています。

これは UE5 標準の AbilityActivationMode::LocalPredicted を正しく使えば実現可能ですが、「設計原則として最初から優先する」と決めておくことが重要でした。

戦闘ロジックは性質上、退行バグが怖い領域です。「前は正しく動いてたパリィが、新機能追加でタイミングがズレた」みたいな退行は、プレイ感にクリティカルに効きます。

Phase 2 では以下の構造体を純粋ロジックとして分離し、Unreal のテストフレームワークで自動テスト化しました:

現在 59+ tests が常時 PASS しています。戦闘の「数字」部分は、プロジェクトが大きくなってもここで守られます。

BP 側のアニメーション・エフェクト・手触り調整は従来通り非 TDD ですが、手触り ≠ 数字ロジックの分離を最初から明確にしたのが Phase 2 の設計的な勝ち筋だと感じています。

今回 Phase 2 の実装では、Claude Code の gas-specialist / network-checker サブエージェントレビューを合わせて受けました。GAS 設計の怪しい点・ネットワーク面で詰みそうな点を、実装直後にフィードバックしてもらう運用です。

結果、以下のようなレビューが入りました:

全部手動でコードを追って気づけたレベルではなかった類の指摘です。個人開発で GAS のような巨大サブシステムを触る時、レビューパスを AI に持たせるのはかなり効く運用でした。

Dungeon Wanderers Phase 2 は 戦闘コアの骨組みが揃った地点です。GAS ネイティブ設計・LocalPredicted 優先・TDD で純粋ロジック保護 — 過去プロジェクトの失敗を教訓にした設計原則が、機能追加に耐える土台を作りつつあります。

次はダメージ適用と LockOn まわり。Parry の手触りデモ動画が撮れたら、またここで共有します。