Chapter 02

ワークフロー (Workflow)

sh1ch
sh1ch
2020.09.23に更新

ワークフロー (Workflow)

1. 最初にスケールを決定して、すべて同じスケールになるようにビルドする

そうしないと、あとでアセットを作り直す必要がでるかもしれません。(たとえば、アニメーションのスケールはいつも正しいとは限りません)3Dゲームの場合、通常は1unity unit = 1m がベストです。

ライティングや物理を使用しない2Dゲームでは、通常1 unity unit = 1 pixel がよいでしょう。UI(と2Dゲーム)では、解像度 (HD or 2xHD) を選択して、その解像度でスケールするようにすべてのアセットをデザインします。

2. すべてのシーンを実行できる状態にしておくこと

ゲームを実行するためにシーンを切り替える必要がないようにします。ただし、すべてのシーンで必要とされる永続的なオブジェクトを持っている場合は厄介です。方法をひとつ挙げると、オブジェクト自身を singleton にすることです。singleton については、別の tips で説明します。

旧 tips.10 と同じ内容だと思います。

3. バージョン管理システム(Git など)の効率的な使い方を学んで利用すること

  • アセットをテキストとしてシリアライズする。
    実際は、シーンや Prefab がマージしやすくなるわけではないけど、何が変更されたか確認しやすくなります。
  • シーンと Prefab をまとめる手法を採用する
    一般的に、複数の人が同じシーンや Prefab を作業してはいけません。小さなチームの場合、あらかじめ(作業をはじめる前に)、他に作業していないことを聞いておくだけで十分かもしれません。シーンの所有権を示すための物理的なトークンを用意しておくと便利かもしれません。(机の上にシーンの所有権を示すトークンがあるときだけ、そのシーンの作業することができる)
  • タグをブックマークとして利用する
  • ブランチの手法を決めて採用する
    シーンと Prefab はスムーズにマージできないので、ブランチ化はすこし複雑です。どのようにブランチを使うのか決めるにしても、シーンと Prefab は一緒にするようにします。
  • サブモジュールは注意して利用する
    サブモジュールは、再利用可能なコードを維持するための素晴らしい方法です。しかし、いくつか注意点があります。
    • メタファイルは一般的に複数のプロジェクトで一貫性がありません。一般的には、non-Monobehaviour or non-Scriptable object なコードでは問題ありませんが、MonoBehaviours and Scriptable objects では問題になる恐れがあります。
    • 多くのプロジェクト(サブモジュールを1つ以上含む)で作業をしていると、ときには雪崩を起こすことがあり、すべてのプロジェクトのコード管理を安定させるために、様々のプロジェクトで pull-merge-commit-push をしなければいけないことがあります。(そして、このメンテナンス中に他の誰かが変更を加えてしまうと、さらに雪崩を起こす)この影響を最小化するための方法のひとつは、常にサブモジュール専用のプロジェクトからサブモジュールに変更を加えることです。サブモジュールを使うプロジェクトは、常に pull するだけでよくなります。

4. テストシーンとコードは分離すること

一時的なアセットやスクリプトはリポジトリーにコミットして、完了したらプロジェクトから削除します。

5. ツール(もっぱら Unity 本体)をアップデートするときは、他の人も同時にする

Unity は異なるバージョンでプロジェクトを開いたときの対応がとてもうまくなりましたが、複数の作業者が異なるバージョンで作業するとリンクが失われることがあります。

旧 tips.2 とは少し違う内容です。

6. 綺麗な状態のプロジェクトにサードパーティー製アセットをインポートして、そこで新しいパッケージをエクスポートして利用する

アセットは、プロジェクトに直接インポートすると問題を発生することがあります。

  • 特に、Plugins フォルダーの直下にファイルを追加するアセット、または、Standard Assets を利用しているアセットは、衝突(ファイル名など)する可能性があります。
  • 展開されたファイルは、プロジェクト上に整理されていないかもしれません。これは使用しないと決めて削除した場合に問題(面倒)になります。

安全にインポートをする手順は以下に従ってみてください。

  1. 新しいプロジェクトを作成し、アセットをインポート
  2. サンプルを実行して、動作することを確認
  3. アセットをより適切なフォルダー構造に整理
    (通常だと、アセットに自分の好むフォルダー構造を強制しません。しかし、すべてのファイルがひとつのフォルダーに入っていること、そして、プロジェクトを上書きするような重要な場所にファイルが追加されないことを確認します)
  4. サンプルを実行して、動作することを再確認
  5. 不要なものをすべて削除する(サンプルなど)
  6. アセットがコンパイルされ、Prefab がすべてリンクを持っていることを確認し、なにかあれば、テスト
  7. すべてのアセットを選択し、パッケージをエクスポート
  8. プロジェクトにインポート

7. ビルドプロセスを自動化する

小さなプロジェクトでも有効ですが、とくに有効なのは次のとおり:

  • ゲームの異なるバージョンをたくさんつくる場合
  • 技術力の劣るメンバーがビルドをする場合
  • ビルドをする前に、プロジェクトに微調整を加える場合

詳細は「Unity Builds Scripting: Basic and advanced possibilities」(著者の過去記事)を参照してください。

8. コーディング資料 (your setup) をドキュメント化すること

ほとんどのドキュメントはコードの中にあるべきですが、しかし、特定のものはコードの外でドキュメント化されるべきです。

コーディング資料を得るために、デザイナーにコードを調べさせるのは、時間の無駄です。ドキュメント化されたコーディング資料は、開発効率を向上させます。(ドキュメントが最新の状態を保持できれば)

ドキュメントがフォローするもの:

  • タグの使用
  • レイヤーの用途(collision, culling, raycasting など、どのレイヤーに入れるか)
  • レイヤーの GUI の深さ(なにをどの上に表示していくか)
  • 複雑な Prefab の構造
  • イディオムの設定
  • ビルドの方法

わりと Unity の設定(セットアップ)に関する技術資料を指している気がします。

旧 Tips 49 と同じ内容だと思います。