Odin を導入してみた
チームで Odin 導入時にハマったポイントと対処方法
こんにちは！パン君です。
今回はインディーズのプロジェクトで Odin Inspector を導入した際に起きたトラブルと、そのときに行った対処についてまとめます。
ざっくり言うと、
- Odin 関連の
.metaファイルに差分が出る - 一部環境で Unity が Safe Mode でしか起動しない
- Test Framework 周りのエラーも一緒に出る
という状態になりました。
自分の環境では再現せず、「動いている人」と「動かない人」が混ざる状態だったので、原因の切り分けとチーム内での対処ルールを整える必要がありました。
この記事では、実際に行った手順ベースで 「こうやっておけば最初の導入時に事故りにくい」 という視点で書いていきます。
エラー内容の整理
まず、チーム内で実際に発生していた症状を整理します。
1. meta ファイルの差分と警告
一部メンバーの環境で、Odin 関係の .meta ファイルに差分が発生し、
無効な meta ファイルが存在します
という警告や、Odin 関連のアセンブリがうまく認識されないエラーが出ていました。
2. Safe Mode での起動
- 自分の環境では普通に起動
- 別のメンバーでは UnityがSafe Modeでしか開けない
という状態に。
自分側で
- Odin をインポート
- 別のローカルプロジェクトで
クリーン → チェックアウトして検証
まで行ったときは問題なかったのですが、
一部メンバーだけ Safe Mode 行きになると報告をもらいました。
3. Test Framework のエラー
Safe Mode のログを見てもらったところ、Odin とは別に
- Test Framework 関連のエラー
が出ているパターンがありました。
Unity の Test Framework は、
- Unity エディタ上部メニュー:
Window > General > Test Runner（バージョンによって多少名称違い） - コード上では
[Test]属性などで単体テストを書くためのパッケージ
です。
ログを読む限り、
- Odin 関連のどこかで Test Framework に依存している
- しかし、あるメンバーの環境では Test Framework が壊れている / 読めていない
という状態になっていました。
ただし、
Packages/manifest.json上は Test Framework のバージョンは揃っている- 自分の別プロジェクトでは同じバージョンで問題なく動作している
という状況だったため、 パッケージそのものが壊れているわけではない と判断しました。
原因の候補
実際にログを見ながら、原因としてありそうだったものはこのあたりです。
- Unity / Odin / Test Framework のバージョン差異
- 特定メンバーだけ Unity のマイナーバージョンが違う
- Odin をインポートしたときのバージョンが微妙に違う
.metaファイルやLibraryの状態差Libraryフォルダが古いまま- 一部
.metaがローカルだけで生成されており、Git に上がっていない
- Test Framework のインストール状態の差
- Package Manager 上で一度削除 or Disable されている
- キャッシュが壊れていて、再インポートが完了していない
実際には「どれか 1 つ」というより、 複数の条件が重なって Safe Mode 送りになっていた 感じでした。
実際に行った対処手順
ここからは、チームで実際にやってもらった手順を整理して書いておきます。
手順 1: 全員の作業手順を統一する
まずは、 「Pull したあとに何をするか」 を固定しました。
git pullする- Unity を閉じた状態で
Libraryフォルダを削除- 必要なら
Tempやobjも削除（任意）
- Unity を再起動して、初回の再インポートを最後まで待つ
これをやっていないメンバーが何人かいたため、
手順を文章にして Discord / DM で流し、「まずはここから」として統一しました。
これだけで直った人もいるので、
できれば Odin 導入時に「手順書セットで配る」のがおすすめです。
手順 2: Odin および Test Framework の状態確認
次に、 問題が残ったメンバー に対しては、パッケージの状態を確認してもらいました。
Window > Package Managerを開く- Odin のバージョンを確認
- 導入したバージョンと一致しているか
Unity Registry側で Test Framework を確認- インストール済みか
- バージョンは他メンバーと同じか
- 状態が
Error/Resolve待ちになっていないか
もし Test Framework が壊れていそうな場合は、
- 一旦 Test Framework パッケージを「Remove」する
- Unity を再起動
- 再度 Package Manager から Test Framework をインストール
という形で再インポートしてもらいました。
手順 3: .meta 差分の整理
Odin 関係の .meta ファイルで差分が出ている場合は、
- まずはリポジトリ側に 正しい状態の Odin + meta をコミット
- その後、他メンバーには
1. 作業ブランチでローカル変更を避難する（stash or commit）
2. 最新ブランチに同期
3. Library を削除
4. Unity 再起動後、Odin 関係の .meta 差分が出るか確認という流れで動いてもらいました。
「動いている環境」をいったん正としてリポジトリに固め、それ以外の環境を合わせにいく
という考え方です。
チームで Odin を導入するときの運用ルール
今回のトラブルを踏まえて、次のプロジェクト以降で気をつけようと思ったポイントをまとめておきます。
1. 導入前に「担当者」を決める
- Odin のバージョン選定
- プロジェクトへのインポート
- 初回コミット
ここは 1人の担当者がまとめてやる 方が事故りにくいです。
中途半端な状態で複数人がそれぞれインポートすると、
.meta や manifest.json がぐちゃっとなりやすいです。
2. Unity / Odin / Test Framework の「想定バージョン」を明文化する
- プロジェクト開始時に
- Unity バージョン
- Odin バージョン
- Test Framework バージョン
を、どこかドキュメントに書いておく
後から参加してくるメンバーにも、「これに合わせてください」と案内するだけで済むようになります。
3. 初回セットアップ手順を README に書いておく
今回やったような、
- git clone / git pull 後にやること
- Library 削除
- Unity 再起動
- うまく起動しなかったときの確認ポイント
- Odin / Test Framework の状態確認
- Safe Mode になったときはログを添付して報告してもらう
といった内容を、簡単な手順書にしておくだけでトラブル時のコミュニケーションコストがかなり下がります。
まとめ
今回の Odin 導入で学んだことをまとめると、こんな感じです。
- Odin 自体は便利だが、チーム導入時には「Unity / Test Framework / meta ファイル」の差異で事故りやすい
- 「動いている環境」を 1 つ決めて、そこから
- Odin + Test Framework の状態をコミット
- 他メンバーの環境をその状態に寄せていくという方針がやりやすい
- 導入時の手順や想定バージョンを 事前に軽くドキュメント化 しておくだけでも、だいぶ安全になる
Odin はカスタムインスペクターやエディタ拡張まわりでかなり強力なツールなので、
一度チームで安定して導入できる形が作れると、 次以降のプロジェクトがかなり楽 になります。
今後は実際にどんな機能を Odin で作っているか（属性ベースの Editor 拡張や、Data 管理の工夫など）も、
別の記事で書いていければと思います。
コメントを読み込み中...