【Unity】後回しにすると大変なことになった事例集

# はじめに

本記事は、[サムザップ Advent Calendar 2021 ](https://qiita.com/advent-calendar/2021/sumzap)の12/8の記事です。

## 経験上

私は、Unityを使ったゲーム開発をしております。
ゲーム開発では、モック開発中にゲームをプレーできるように優先して開発してしまいますが
開発しているときから常に意識してほしいことを説明したいと思います
後回しにすると大変になった事例をいくつか紹介します


## 意識してほしいこと

### 画面遷移
モック中に複数の画面の機能を量産して動く形に仕上げ、
デザインも適応させ見た目の確認をすることが多いと思います。
量産ばかりしていていざ本開発にむけて仕上げる状態になったときに
やりたい挙動ができなくなることがしばし見受けられます。

 1. 画面遷移中にインタラクションを入れたいけど入れにくい
 2. ダイアログを出す仕組みが各々違うからインタラクションが入れにくい
 3. Androidのバックキーを入れたいけど戻るボタンの処理が各々違うからいれにくいなどなど

上記のようなことをおろそかにすると、本開発中にチームメンバーが増えて
さらにページ数が増えてくると修正が困難になりがちです。
最初にページの遷移やダイアログの遷移のベースを先に作ってしまうことをおすすめします


####設計のポイント
ページの遷移やダイアログを(Prefab単位で実装するか複数のシーンを使って実装するか)
Unityだとどちらかの方法を使って実装することが多く見受けられます。
私の経験上だと、Prefabを使って構成することが多い印象ですが
どちらの方式でつくるか決めます

次に挙動を決める。
設計によって、細かく挙動がかわると思いますが。ここでは例として列挙します

ページに移動する
1. 初期化する
2. アニメーションを入れる
3. 画面を表示する

ページから離れる
1. アニメーションを入れる
2. 画面から離れる
3. 後始末(メモリー等やアセットの解放など)

上記のような処理で設計した場合にそれぞれをベースコードとして実装しておくことで
すべてのページが同じ挙動になります。

### アセット管理
モック開発中に乱雑に配置してしまったアセットですが、
これらは大体が使われない素材になりがちです。
ここも適当に配置して放置しまっていると本開発するというフェーズの時に
アプリサイズが肥大化してしまうという問題をよく拝見します。

1. すべての素材をResources上に配置してしまっている
2. Atlasデータと素材がResources上に一緒に置かれてしまっている
3. 圧縮形式をきめていない
4. モバイル以外のプラットフォームにも考慮しておく(Windows)など

####ポイント
素材類は、Resources上に配置せずに別フォルダーに入れておく。
Atlasデータは、Resources上に配置しておく。

>
Assets/
　├ Sandbox/
　│　└ Mock/
　│　　　└ UI/ << 開発中はこちらに配置
　│　└ Release/
　│　　　└ UI/ << 本開発になったらこちらに配置
　├ Resources/
　│　└ Atlas/ << こちらにAtlasデータを配置して、AtlasのPackingフォルダーを適宜変更
    
今回の例は、Atlas例にしていますが、他の素材も同様にわけておくことをおすすめします

圧縮形式について
圧縮形式をきめておかないと、見た目の印象から変わってしまいますし
アプリサイズにも影響してしまうのでここも抑えておきます

| 圧縮形式(モバイル) | 用途 | 注意点 |
|:-----------|:------------|:------------|
| ASTC 4x4       | UIパーツ(Atlas)        | 2048 x 2048に収める       |
| ASTC 4x4     | 他のテクスチャ      | PCでも考慮してDXT5にする予定なので4の倍数にする      |

上記は一例ですが、あらゆる素材で構成されますので
チームで相談しつつ適切に設定することをおすすめします

### アセットバンドル管理
ゲーム開発において、アセットバンドルにして外部で管理することが多くなると思います。
乱雑に配置してしまっていると肥大化してしまう傾向になりがちです。
肥大化するとダウンロード時間の配慮も必要になってきてしまいます

####ポイント
1. アセットは、フォルダパック管理で管理する
2. アセットサイズが大きい素材は、ファイルパックにして分割しておく
3. 並列ダウンロードの実装もしておく 

この3点を抑えておくだけ、効果が違います。

>
Assets/
　├ AssetBundles/
　│　└ character/
　│　　　└ 1/
　│　　　　│ head
　│　　　　│ body
　│　　　　│ hair
　│　　　　│ background
　│　　　　│ icon
　│　└ movie/
　│　　　└ 1/
　│　　　　│ sample1
　│　　　　│ sample2
　│　　　　│ sample3
　│　　　　│ sample4
　│　　　　│ sample5

上記のような構成でアセットバンドルに管理されているという例で説明します

キャラクターの素材を下記のように管理した場合

| パック形式| AssetBundle Label | 補足 |
|:-----------|:------------|:------------|
| フォルダパック       | character/1        |   一つで5つの素材を管理(一つの素材が数K Byte)    |
| ファイルパック     | character/1/head<br>character/1/body<br>character/1/hair<br>character/1/background<br>character/1/icon | 5つをそれぞれ管理 |

ムービーの素材を下記のように管理した場合

| パック形式| AssetBundle Label | 補足 |
|:-----------|:------------|:------------|
| フォルダパック       | movie/1        |   一つで5つの素材を管理(一つの素材が数M Byte)     |
| ファイルパック     | movie/1/sample1<br>movie/1/sample2<br>movie/1/sample3<br>movie/1/sample4<br>movie/1/sample5 | 5つをそれぞれ管理 |

例として、それぞれを10万台の端末が一斉にダウンロードを開始した場合

| パック形式| 素材 | 補足 |
|:-----------|:------------|:------------|
| フォルダパック       | キャラクター        |   10万台 × 1コネクション    | 
| ファイルパック       | キャラクター        |   10万台 × 5コネクション    | 
| フォルダパック       | ムービー       |   10万台 × 1コネクション      | 
| ファイルパック       | ムービー        |   10万台 × 5コネクション    | 

フォルダパックのほうがコネクション数が少なく済むので
ダウンロードが高速になりそうですが
ムービーは数M Byte × 5のファイルサイズになるので
ファイルサイズが数M Byte以上あると一つのダウンロード時間が
遅くなる傾向が経験上体験しましたので
並列ダウンロードできる仕組みを用意しておくをおすすめします

####ポイントまとめ

 * アセット管理は小さいサイズでまとめて管理できるならフォルダパック
 * 大きいサイズになるなら、ファイルパックして分割ダウンロード

アセットバンドルでは一つの素材でもフォルダパックで作成しておき、
大きいサイズになるものはファイルパックで管理することをおすすめします
フォルダパックにしておくことで、後で追加しやすくなります。