Gotanda.unity #18: 発表資料

1. Addressables
大量のリソース管理・困りどころと解消法
Gotanda.unity #18
Kenta Nagai

2. 自己紹介
ワンダープラネット株式会社
タノシムスタジオ clientエンジニア
永井 健太 (ナガイケンタ)

3. 本日の内容
多量のリソース管理について
・開発の考慮 / 設計
・運用での問題
Addressable Asset System ( 以降Addressables)
・どんな感じで使用したかの構成
・運用時の体験談

4. 課題：開発初期( モック開発 )
image
Voice BGM
キャラ UI
短期間な開発期間のプロジェクト
最小限の工数ですばやくリリース！
社内
デザイナー
DEV環境
背景
sound
組織 環境
Local環境
master
社内
エンジニア
社内
プランナー
excel
ベタ書 Se

5. あれもこれも
やりたい(仕様)
画像/シナリオ
/音声外部発注
マスターデータ
もいい感じに
外部!?
いい感じ!?

6. 課題：開発進むにつれて・・・
image
Voice BGM
キャラ UI
社内
デザイナー DEV環境
背景
sound
組織 環境
Local環境
master
社内
エンジニア
社内
プランナー
excel
ベタ書
Se
サムネ大
サムネ中
サムネ小
Spine
アプリ内包
一枚絵
セリフ
e-mote
live2D エピローグ
縦長背景
イベント
text
シナリオ
CRI
キャラの
掛け合い
掛け合い : キャラ x キャラ x パターン
発注
外部a
外部b
外部c
納品
QA環境
DEV環境
プランナー環境
デザイナー環境
version管理
（git）
no wifi
いっぱい
イベント
イベント
参照
参照
参照
参照
unity
組み込み
CDN
DLリソース
jenkins

7. リソースに埋もれる・・・
管理どうしよう・・・

8. 大量のリソースとその運用管理が必要
→ Addressables
最大限効率化しないとやばい

9. 柔軟性の高いシンプルなアセット設計を目指す
・【柔軟性のキモ】依存関係を最小限 (1bundle に他のbundleを依存させない)
・【効率化のキモ】命名規則 (base の key でasset名を作成する)
actor_[:character_key]_[:costume_key].psd
char_[:character_key]_voice_[:character_voice_key].wav
設計

10. 設計(命名規則)
・発注書の記載
・納品データ
・マスターデータ
・Unity読み込み登録
・シナリオスクリプト内のリソース登録
etc...
→ 命名規則シート作成
アセット管理全ての基盤
100行 + 25シートくらい

11. 設計(命名規則)
・Assetbundless Groupへのimporterも命名規則通りに読み込めばいい
納品(他社)
→ 組み込み/ファイル追加(デザイナー)
→ エンジニアの手を使わない登録の自動化

12. それでも運用で問題は
起きちゃいますよね〜

13. 運用/開発 問題①
並行開発/Groupコンフリクト
・メインの開発環境からブランチ切って作業
・イベントやログインボーナス、ガチャ並行
・.asset や CRI.project ファイルの競合

14. 運用/開発 解決策①
並行開発/Groupコンフリクト
強行策
・頑張ってマージする
改善策
・各作業ブランチでグループを分ける
(CRI も作業workunitを分ける)

15. 運用/開発 問題②
Addressablesバグ(機能の問題)
・赤丸を変更する
・なぜか他のリソースのIDも変わる
・変更してないファイルの再DLが入る

16. 運用/開発 解決策②
Addressablesバグ(機能の問題)
一時対応
・グループを分ける
・自動import 対象から外す
・Addressables のversion更新で解決

17. 運用/開発 問題③
バージョン管理(運用の問題)
・アプリ内包していたリソースを外出ししようとして発生
・アプリのversionは 1.0.0 / 1.1.0 → catalog_1.0 と catalog_1.1
・ファイルの上書きが発生
catalog_1.0 →
catalog_1.1 →
catalog_1.0 & 1.1 →

18. 運用/開発 解決策③
バージョン管理(運用の問題)
・local → remote 指定に(運用中変更する際は差分DLできるようにしましょう！)
・hash値をつけて再アップロードし解決
(・ 運用前提が覆る場合は、チーム全体で確認)

19. 運用/開発 問題④
DLの容量を最小限に(チーム共有の問題)
・イベント使いまわさないよ！
・✅ include in build
・イベントリソース管理
(終了したイベントのリソースをDLさせない)
・マスターデータはあるがリソースがない

20. 運用/開発 解決策④
DLの容量を最小限に(チーム共有の問題)
・チームでのすり合わせや仕組みの理解が必要
・終了したイベントなどのリソース削減のタイミングとすり合わせ重要！

21. まとめ
point 1 : 柔軟かつシンプルな設計に！(命名などで自動化)
point 2 : addressables万能ではない！の更新内容確認は定期的
に！
point 3 : 仕組みやフローはエンジニア以外も共有しよう！