【Unity・NGO】マルチプレイFPS開発の泥沼から脱出せよ！アニメーションIK・UIの罠・大量の敵を捌く通信最適化のリアルドキュメント

公開日: 2026年6月22日 | カテゴリ: ゲーム開発 / Unity / C#

はじめに：個人開発マルチプレイFPS『VALOPEX STRIKE 2』の挑戦

個人で3Dマルチプレイゲーム、それも一瞬の同期ズレが命取りになるインディーズFPSを開発するというのは、文字通り「終わりなき泥沼との戦い」です。現在、スタジオで開発を進めている期待の超新作FPS『VALOPEX STRIKE 2』では、Unityの標準ネットワーク機能である「Netcode for GameObjects（NGO）」をベースに、Cowsins（FPS Engine）を統合した独自のマルチプレイ環境を構築しています。

開発初期は順調に見えるものの、複数プレイヤーを接続した瞬間に牙を剥くのが「アニメーションの同期ズレ」「三人称視点（他プレイヤー）のIK（逆運動学）の破綻」、そして「敵が大量に発生した際の大規模なネットワーク負荷（ラバーバンディング）」です。本記事では、筆者が実際に何日も頭を抱え、AIアシスタント（Cursor）と共に一つひとつの罠を解き明かし、最終的にプロ品質の最適化にまで到達したリアルな開発プロセスのすべてをドキュメントとして残します。同じようにUnityでマルチプレイやFPS開発に挑み、絶望している開発者の道標となれば幸いです。

第1章：MixamoアニメーションとUnityの「In-Place」の罠

移動を伴うモーションが引き起こすラバーバンディング

ゲーム内でプレイヤーが走る、歩く、しゃがむ、あるいは激しくスライディングする。これらのモーションデータを、多くのインディー開発者はアセットサイト「Mixamo」などから調達します。しかし、ここに最初の巨大な罠が隠されています。

Mixamoからダウンロードした「スライディング」や「前転」のようなアニメーションの多くには、その場で動くための「In-Place」チェックボックスがサイト上に用意されていません。これをそのままUnityにインポートすると、キャラクターの肉体（メッシュ）がアニメーションの再生と同時に物理的に前方へ数メートル滑り出していきます。これをマルチプレイで同期しようとすると、同期の基準となるシミュレーションカプセル（当たり判定の筒）はその場に留まっているのに、見た目の体（Hipsボーン）だけが遥か彼方へ走っていき、アニメーションの終了やループの瞬間に元のカプセル位置へ「ガクッ」とワープして戻るという、不気味で激しいラバーバンディング（引き戻し現象）が発生します。

Unityの「Bake Into Pose」では解決しなかった根本原因

多くのUnity開発者は、この現象をUnityのインスペクター設定で解決しようと試みます。FBXのアニメーション設定を開き、Root Transform Position (XZ) の Bake Into Pose にチェックを入れるアプローチです。筆者もこれを最初に適用していました。

Unityの Bake Into Pose は、確かに「キャラクターのルート座標（カプセル）がアニメーションの移動力によって勝手に前進するのを止める」という役割を果たします。しかし、アニメーションデータそのものに含まれている「骨の移動情報」までは消し去ってくれません。基準点であるカプセルは固定されているものの、キャラクターの最親ボーンである腰（mixamorig:Hips）だけが空間を前方へと突き進んでいってしまうのです。

これにより、後述するAnimation RiggingのIK（Inverse Kinematics）ターゲット（武器のグリップ位置など）がカプセル中心に取り残され、キャラクターの体だけが前方に進むため、「左腕がゴムのように後ろへビヨーンと不自然に伸びてしまう」という致命的なホラー映像が完成してしまいました。Unityの機能で無理やり動きを抑え込むのと、アニメーションデータ自体が最初から「その場（0, 0, 0）」で動いているのとでは、データ構造上、全く意味が異なるのです。

Blenderを駆使したFBXデータの物理的改造アプローチ

Mixamoが「In-Place」を提供してくれないなら、自分でアニメーションデータの骨の動きを書き換えるしかありません。筆者は無料の3Dモデリングソフト「Blender」を立ち上げ、スライディングのFBXファイルを直接改造する以下の手順を確立しました。

1. BlenderへMixamoからダウンロードしたスライディングFBXをインポートします（ファイル ＞ `インポート` ＞ `FBX`）。
2. 読み込んだキャラクターの骨格（アーマチュア）を選択し、オブジェクトモードから「ポーズモード」に切り替えます。
3. キャラクターのすべての親である中心のボーン、mixamorig:Hips（腰ボーン）をクリックして選択します。
4. 画面下部のタイムラインを「グラフエディター（Graph Editor）」に切り替え、左側パネルの展開ツリーから mixamorig:Hips の 位置 (Location) を開きます。
5. グラフを見ると、前進している軸（UnityとBlenderの座標軸の変換により、通常はY位置またはZ位置）のカーブが斜めに大きく右肩上がり、あるいは右肩下がりにズレているのを確認できます。これこそが、体を前方に引っ張っていた犯人です。
6. この前進している軸（例：Y位置）の文字をクリックして選択し、右側のグラフエリアにマウスを置いた状態で A キーを押してすべてのキーフレームを全選択、X キーを押して「キーフレームを削除」を実行します。これで、前に進む力が完全に消滅します。
7. キーフレームを消去しただけでは初期位置がズレることがあるため、画面右側の「トランスフォーム」パネルで、該当する軸の位置を 0 m に手入力で書き換えます。
8. 0 m と入力した欄の上にマウスを乗せたまま右クリックし、「キーフレームを挿入（単一）」を選択（または I キー）して、常に原点に留まるように上書き固定します。

スペースキーで再生すると、キャラクターが1ミリも前進せず、その場で綺麗にスライディングのポーズをとるだけの「真のIn-Placeアニメーション」に生まれ変わりました。これを再びFBXとしてエクスポートし、Unityへと連れ戻します。

第2章：呪いの補正コードの大掃除とNGO標準機能の再発見

複雑怪奇な「CoopVisualFollower」という負の遺産

真のIn-Placeアニメーションを手に入れる前のプロジェクトコードには、骨格が勝手に移動するバグをプログラム側で無理やりねじ伏せるための、複雑怪奇なスクリプトが存在していました。それが CoopVisualFollower です。

このスクリプトは、毎フレームLateUpdateの中で compensateRootMotion や hipsBoneNameContains といった処理を走らせ、前方に逃げていくHipsボーンの座標を計算し、無理やり引き戻すという涙ぐましい補正を行っていました。しかし、この強引な引き戻し計算こそが、マルチプレイ時に他プレイヤーの腕のIKをバグらせ、カクつき（スタッター）を生み出し、ネットワーク同期と激しく衝突する「諸悪の根源」「呪いのコード」と化していたのです。

Cursor AIのエージェント機能による「89個のタスク」一括処理

In-Place版のFBXが揃った今、この呪いのコードは1行たりとも残す必要がありません。筆者は最新のAIコードエディタ「Cursor」を起動し、プロジェクト全体の「大掃除」を命じました。Cursorのエージェント機能はプロジェクトの全ファイルを解析し、実に見事なリファクタリングを自動で実行しました。

Cursorが自動で遂行したタスクは実に89個。新しく用意した5つのIn-Place対応FBXを正しく Humanoid アニメーションに変換し、Animatorのブレンドツリー（Forward, Backward, Strafe Left, Strafe Right, Slide）へと精密に再ワイヤリング。そして、不要になった CoopVisualFollower 内の _hips 検索ブロック、フレームごとのプルバックロジック、不要なヘルパー関数、古いコメントアウトを跡形もなく、かつ完璧な依存関係の整合性を保ったまま完全に削除したのです。コンソールエラーは「0」。手動で行えば数時間はかかり、必ずどこかで参照エラーを起こすレベルの大工事が、一瞬で完了しました。

「実は最初から滑らかだった」というネットワーク同期のオチ

この大掃除の過程で、Cursorがソースコードの深部から衝撃的な事実を掘り起こしました。 Unity標準のネットワークライブラリである「Netcode for GameObjects（NGO）」のコンポーネント ClientNetworkTransform の OnNetworkSpawn() 内を調査したところ、最初から Interpolate = true（位置・回転の補間機能）が有効化されていたのです。

つまり、他プレイヤーのシミュレーションカプセルは、NGOの標準機能によってすでにネットワーク越しにヌルヌルと滑らかに動いていました。私たちが重い処理を書いて必死に実装していた CoopVisualFollower は、**「すでに滑らかに動いているものを、二重に滑らかにしようとして座標を狂わせ、バグを引き起こしていただけの完全な超冗長スクリプト」**だったというオチでした。システムをシンプルに保つことの重要性を、改めて痛感させられた瞬間です。

第3章：スライディング中の「真横を向いて滑る」向きのバグ

進行方向に対して体が常に90度横を向く現象

アニメーションをクリーンにし、無駄なコードをすべて消去して他プレイヤーを走らせたところ、移動の滑らかさと左手の張り付きは完璧になりました。しかし、ここで新たな問題が浮上します。「スライディングを発動した瞬間、キャラクターの体が進行方向に対して常に真横（90度）を向いたまま、氷の上を滑るように進んでいく」という極めて不自然な挙動になったのです。

FPSゲームでは、スライディングや特定の特殊アクション中、プレイヤーのエイム（視点）は自由に動かせますが、キャラクターのカプセル（当たり判定の正面）は進行方向に固定されるか、あるいは独自の回転制御に移行します。先ほど、何でもかんでも視点の向き（LookYaw）に体を無理やりねじ曲げていた CoopVisualFollower を消し去ったため、アニメーションデータ本来の「正面」がそのまま画面に露出した形になります。

Unityインスペクターの「Root Transform Rotation」でノーコード解決

これはプログラムの不具合ではなく、Mixamoのアニメーション、あるいはBlenderで加工したデータの「正面の軸」が、Unityの世界の基準軸（Z軸フォワード）に対して最初から90度ズレて作られているという、3Dアセット特有の定番の罠でした。解決のためにコードを書く必要は一切ありません。Unityのインスペクター上で以下の設定を施すだけで解決します。

1. UnityのProjectビューで、該当するスライディングの**アニメーションファイル（FBX）**を選択します。
2. 右側のInspectorウィンドウで **`Animation`** タブを選択し、下部へスクロールします。
3. **`Root Transform Rotation`** セクションを見つけます。
4. `Bake Into Pose` にチェックが入っていることを確認します。
5. そのすぐ下にある **`Offset`** という入力欄（初期値は0）の数値を **`90`** （あるいはアニメーションの向きに応じて **`-90`** や **`180`**）に変更します。
6. インスペクター右下の **`Apply`** ボタンを押して適用します。

ゲームを再生してスライディングを行うと、先ほどまで真横を向いていたキャラクターが、完璧に進行方向の正面を向いて鋭く滑り出していくようになりました。3D開発において、なんでもコードで解決しようとする前に、アセット自体のインポート設定（トランスフォームオフセット）を見直すことの大切さを物語る事例です。

第4章：IK（逆運動学）が効きすぎる悪夢と、動的ウェイト制御への挑戦

「左手が武器のグリップにガチガチに接着される」問題

次の課題は、Animation Riggingの「IK（Inverse Kinematics）」が強力に効きすぎていることによるモーションの破綻でした。他プレイヤーの左手は、Cowsinsのシステムによって「三人称用武器のフォアグリップ位置（Targetオブジェクト）」に完璧に吸い付くようになりました。位置ズレはゼロです。しかし、これが新たな悪夢の始まりでした。

IKの適用度（Weight）が常に 1.0（100%強制固定）のままであるため、キャラクターが「リロード」を行って左手でマガジンを抜こうとした時も、IKが「何が何でもグリップから手を離すな！」と命令し続けます。結果、左手が銃の先っぽに接着されたまま、肘や肩の関節だけが不気味にグニャグニャと動くというホラーなリロードモーションになってしまいました。スライディング時や、ナイフで敵を切りつける「メレー（近接攻撃）」の時も同様に、左手が銃に固定されたまま腕を振り回そうとするため、見た目が完全に破綻してしまったのです。

Animatorの「アニメーションカーブ」を用いた動的ウェイト制御

プロのゲーム開発において、この「ガチガチIK問題」は、アニメーションの状況に応じてIKの力（Weight）を 1.0（完全固定） から 0.0（完全自由） まで動的にブレンドすることで解決されています。筆者はAnimatorの**「アニメーションカーブ（Animation Curves）」**機能を使用して、C#コードからIKの強さを完全にコントロールする仕組みを構築しました。

まず、UnityのAnimator Controllerのパラメータタブに、新しいFloat型のパラメータ `LeftHandIKWeight` を作成します。そして、リロード、スライディング、メレー攻撃の各アニメーションクリップをインスペクターで開き、Curves セクションに同じ LeftHandIKWeight という名前のカーブを追加して、以下のようにグラフのキーフレーム（点を打つ）を設定します。

• リロード通常時： 数値は 1.0（左手はしっかり銃を握る）
• マガジンに手を伸ばす瞬間：** 1.0 から 0.0 へ滑らかに下降（IKをオフにして手をアニメーション通り自由に動かす）
• リロード中（マガジン交換）：** 0.0 をキープ（手が自由にマガジンを扱う）
• 新しいマガジンを装填し、銃を構え直す瞬間：** 0.0 から 1.0 へ滑らかに上昇（再び左手が銃のグリップに吸い付く）

// 毎フレームのアニメーション評価後（LateUpdate）に実行
void LateUpdate()
{
    if (animator != null && leftHandIKConstraint != null)
    {
        // Animatorのカーブから現在のウェイト値を取得
        float targetWeight = animator.GetFloat("LeftHandIKWeight");
        
        // 直に代入するとカクつくため、Mathf.Lerpで滑らかにブレンド
        leftHandIKConstraint.weight = Mathf.Lerp(leftHandIKConstraint.weight, targetWeight, Time.deltaTime * 15f);
    }
}