『Hi-Fi RUSH』のリズムアクションはどうやって生まれたのか！？【UNREAL FEST 2023 TOKYO】

『Hi-Fi RUSH』のリズムアクションはどうやって生まれたのか！？

プレゼンのメンバー： ジョン・ジョハナス / ディレクター 中村 祐二 / リードプログラマー 畠山 耕一 / リードアニメーター

講演の内容： ①コンセプトの概要説明＆遊びのゴールを決める ②UE4を使った、Hi-Fi RUSHのプロトタイプ作成について ③UE4でプロトタイプ開発をしたことがどう本編制作に繋がったか （主にモーションについて）

①コンセプトの概要説明＆遊びのゴールを決める

Hi-Fi RUSH のコンセプト 「アクションゲームだが、世界のすべてが音楽に合わせて動く。 そして、自分のアクションが曲の一部に感じるようにシンクロする！」 「リズムアクション」

結論：面白そうだけど、本当にできる？

Hi-Fi RUSH のプロトタイプを作りましょう！（Proof of Concept) プロトタイプの目標： ・根本的な遊びを形にする。 ・抽象的な「リズムアクション」 → 具体的な遊びに落とす

UE4によるプロトタイプ開発を決めた理由 ・Ghostwire: Tokyo がUE4で開発中 ・「プロトタイプが作りやすい」らしい ・少人数で専用ツールなしでゲームを簡単に形にできる ・以前に使っていたエンジンと違う！

Hi-Fi RUSHのプロトタイプを作るチーム ・ジョン・ジョハナス ・アイディアマン・企画・レベルデザイン（UI・演出） ・中村 祐二 ・プログラマー（システム、遊び、ギミック） 二人とも… ・UE4の経験が０！ ・アクションゲームを作った経験ほぼ０！ ・音ゲーを作った経験０！

最初に決めたこと： １）「ビジュアルは無視します」 ２）「ゲームプレイとノリだけに集中する」 音楽のロジックを使って、Hi-Fi RUSHのルールを具体化 （５つのルールからシステムが作られた）

音楽にシンクロするシステムが必要： 「RSS」

音楽にシンクロするシステムが必要： On Beatに合わせるコンセプト （拍合わせ＝Quantitize）

音楽を利用して、遊びのフローを決めること：

プレイヤーの行動を「リズムアクション」に感じるように ゲームとしてもっと も大事なこと Accessibilityの重視

音楽とアクションの因果関係 プレイヤーの遊びによっては 必ずゲームシステムの レスポンスが必要です！

拍に合わせてモーションを補正 RSSの 軸になるポイント！

じゃあ、こんな感じで願い！ これ…、厳しくない？ よろしく！

PROTOTYPE

②UE4を使った、Hi-Fi RUSHのプロトタイプ作成について

RSS（Rhythm Synchro System）とは？ サウンドミドルウェア（Wwise）からの情報を取りまとめて、 アプリ側で扱えるようにするマネージャークラス

RSS（Rhythm Synchro System）とは？ プラグイン アプリ Component Wwise TangoMusicManager RSS BPノード Delegate

RSS（Rhythm Synchro System）の説明 RSSから取得出来る主な情報（プロトタイプ時） BPM 小節 2分音符 4分音符 曲の開始 曲の終了 8分音符 16分音符

RSS（Rhythm Synchro System）の活用：アニメーションの場合 ・アニメーションを曲の速さに合わせる → 再生レートを変更する事で対応 →アニメーションの速度は120BPMを基準に → 140 / 120 = 1.1666...倍 → なぜ120BPM？ →1拍が0.5秒 ＝ 15F（30FPSのアニメーションの場合） 計算しやすい！

RSS（Rhythm Synchro System）の活用：アニメーションの場合 120BPM（x1.0）

RSS（Rhythm Synchro System）の活用：アニメーションの場合 140BPM（x1.1667）

RSS（Rhythm Synchro System）の活用：アニメーションの場合 ・移動や待機は開始位置を変更 ・RSSから現在の曲の位置を取得 → アニメーションの再生開始位置にする

RSS（Rhythm Synchro System）の活用：アニメーションの場合 曲がこの位置なら… １小節は2秒だから、1秒目から開始すればいい （120BPM基準）

RSS（Rhythm Synchro System）の活用：BPの場合 コンポーネントの追加 プロパティの設定 コンポーネントをRSSに登録する

RSS（Rhythm Synchro System）の活用：BPの場合 拍イベントの実装例

RSS（Rhythm Synchro System）の活用：BPの場合

RSS（Rhythm Synchro System）の活用：BPの場合 BPノード

試行錯誤へGO！

いろんなアニメーションカーブを用意して、 拍合わせの気持ちよさのTrial and Error をしました Hit In, Hit Out, Pulseなどのバリエーション １拍呼ばれたらループできる仕組み 適切なギミックにアサインしたら背景の動きが試すことができました

シンプルなBPで拍に合わすギミックが作れるようになります 拍に合わせて伸縮するもの

シンプルなBPで拍に合わすギミックが作れるようになります 拍に合わせて移動する プラットフォーム

UIの動きを拍に合わせることができる 30Fを１拍としてアニメーションを作成

演出の開始タイミングなどを小節開始して、アクションを拍合わせができた

攻撃をリズムに合わせる ・通常のアニメーションは対応できた → 攻撃はどうする？ ・攻撃の拍合わせ → 音楽ゲーム的知識が無かったため、 この部分がプロトタイプで一番時間が掛かった

攻撃をリズムに合わせる ・攻撃がヒットするタイミング ＝インパクト ・開始からインパクトまでを1拍（15F） →次の拍に攻撃がヒットする ・ストアアセットでアニメーションを購入 → UE4のAnimMontageによるアニメーション調整

AnimMontageによるアニメーション調整 ×0.8 ×1.65 ×1.0

テストアニメーションの用意が出来た

攻撃をリズムに合わせる（拍合わせ） ・インプットに関係なく、 インパクト（攻撃が当たるタイミング）を拍に合わせる 1拍 8分音符 インプット インパクト

攻撃をリズムに合わせる（拍合わせ） ・完成！しかし… →インパクトまでが長く感じ、気持ち良さが出なかった ↓ 混迷の試行錯誤へ…

攻撃をリズムに合わせる（拍合わせ）試行錯誤１ ・インプットが拍にあってた方がいいのでは？ →インプットを拍に合わせてもらう 1拍 インプット インパクト

攻撃をリズムに合わせる（拍合わせ）試行錯誤１ ・結果 →拍に合わせるのが難しい →合っても特に気持ちよくない →コンセプトからも外れるため、なし

攻撃をリズムに合わせる（拍合わせ）試行錯誤２ ・インプットが拍にあってた方がいいのでは？ →インプット直後に攻撃が当たるようにした 1拍 インプット インパクト

攻撃をリズムに合わせる（拍合わせ）試行錯誤２ ・結果 →気持ちい時もあるけど… →拍に合わせるのが難しい →アニメーション（コンボ）の作成が難しい

攻撃をリズムに合わせる（拍合わせ）試行錯誤３ ・1拍より短い攻撃があればいいのでは？ →8分音符も混ぜる 1拍 インプット インパクト

攻撃をリズムに合わせる（拍合わせ）試行錯誤３ ・結果 →拍に合わせるのがとても難しい →連打している感が強く、気持ち良くない

攻撃をリズムに合わせる（拍合わせ） 色々試してみるも、どれも上手くいかない… →素直に最初のコンセプトに戻ろう →問題は、気持ちよさが無いアクション →どう改善する？

攻撃をリズムに合わせる（拍合わせ） ・アニメーションの問題 →やはり専用のアニメーションが必要！ →パンチ・キックをギターに！ ・インプットからインパクトまでの長さの問題 →インプットのフィードバックも追加 コントローラの振動、エフェクト、SEを追加 →インプット時にも気持ちよさを感じられるように！

1拍 8分 音符

アニメーターの合流 ③UE4でプロトタイプ開発をしたことがどう本編制作に繋がったか （主にモーションについて）

プロト版制作へ参加した際の当時の状況、心境は？ 「リズムゲーム」じゃない「リズムアクションゲーム」 →どんなゲームを作っているのかは知らない。 「リズムゲーム」という言葉が先行していた。

合流して初めに行ったことは？ ・見た目はマネキンのまま、プロト版最後まで制作する 事が決まっていた。 → 外見は変更せず、ジョイントの仕様を社内のものに。

Montageで加工して使用していた既存アニメーションは？ ・アセットストアから購入したアニメーションをオリジナルへ差し替え …がいきなり入れ替えると、２人で作ってきたものが壊れてしまう。 → 新ジョイントのマネキンに同じモーションを乗せ替え。

このプロジェクトならではのアニメーション仕様 ・拍に合ったアニメーションとは？ ・アクションゲームにおける、リズムを感じる事の 出来るアニメーションの模索

まずは、待機・移動・攻撃の作成 DCCツール上では、30FPSで制作していた為、30FPSベースでの説明 （※UE4上では、60FPSベースになります。）

待機 → 重心の上下動、左右移動を意識した動き 差し替え Store asset

移動は何を拍に？ → 足の設置を拍に合わせる事をベースに (1ループ17F) 八分音符 (1ループ15F) 四分音符 (1ループ30F) or Store asset 15Fだと忙しなく、 拍を意識できなそう … 1ループ30F（四分 音符設置）をベース Store asset 差し替え １ループ何フレ ベースにするか？ Store asset

攻撃アニメーション → 『ヒットを拍のタイミングに合わせる』は、 試行錯誤により決めてくれていた部分。 差し替え Asset store ？ とりあえず作ってみるも… 気持ちよさがでない ×

気持ちよさが出ない理由は？ 拍に合わせるという特性上 →弱攻撃でも、入力からヒットフレームまで15フレーム 程度(60fpsだと30フレーム)あり、間が長い。

レスポンスの悪さ解消の為に考えてみた事 ・初動に大きい動きを入れたアニメーションデザインにすれば？ 突進からの攻撃など色々試してみるが 全然ダメ… ・ただ、アニメーションを作って行く事で気づくことも

・シルエットの大きい変化 ・いつも以上の誇張表現とメリハリ ・「バッ」「パン」「ブンッ」など擬音の 脳内再生が可能なアニメーション ・ジャンプの着地などタイミングがビジュアル 的に想像し易いものは、拍のタイミングを掴み やすい。

プロトタイプ版で意識したポイントは、本制作でも継承

結論：アニメーションの調整で操作や拍合わせの攻撃がやっと 気持ちよくなりました。 ・論理ができましたので弱攻撃（1拍）と強攻撃（2拍） の組み合わせでプレイヤーのアクションを増やしました。 ・あとに追加したのは遊びのタイミング合わせ （BeatHit）にも追加しました

プロトタイプで作成した地上のメインコンボのアニメーションデザインは、 キャラデザができた本制作でも方向性は、大きく変更されていない。 珍しい例かもしれませんが…

最後にディレクターのまとめへ

Hi-Fi RUSH の最終プロトタイプ： ・開発期間は、ほぼ１年 ・プレイ時間は10分ほど ・遊び重視で「リズムアクション」のやりたいことが伝わった →本制作へOK！ ・基本的な遊びの実装：攻撃のタイミング、コンボ、BeatHit、 パリー、スペシャルアタック…

学習したこと： ・新しいことを作ろうとしたらやりたいことを絞って、 その面白さを具体的に伝えることが大切。 ・コンセプトをどれぐらい考えてもTrial and Errorが発生する ・UEのおかげで少人数でかなり精度が高いものが出来たので、 UEは実験しやすいことを実感した。

あまりにも頑張ってゲームプレイをプロトタイプで磨いたので 最終的なゲームにかなり似ています。

ご清聴、ありがとうございました！

アンケートへのご協力をよろしくお願いします