cocone Teck Talk Vol.2 - Singletonを使わないUnityを用いたApplication開発

Singletonは便利なんだけどあまり使いたくない… そんなあなたにSingletonを使用せずに実装されたApplicationの考え方や設計などを紹介します。

Transcript

1. Singletonを使わない Unityを用いたApplication開発 ポケコロツイン事例紹介
2. 自己紹介 堀尾 大地 • ポケコロツイン clientエンジニア 職務経歴 • 株式会社Aiming(約5年) • 株式会社インディゴゲームスタジオ（約 1年） • cocone株式会社 <= ｲﾏｺｺ 趣味 • ゲーム • youtubeでhololiveの配信を見る • 欅坂46/櫻坂46
3. 目次 1. Singletonを使いたくない理由 2. ポケコロツインの実装紹介 3. まとめ
4. Singletonを 使いたくない理由
5. Unityを使ってApplicationを作る • UnityがSceneを起点としている • アプリやチームの規模が大きくなってくると複数のSceneができる • Scene間でデータのやり取りをする仕組みが欲しくなる
6. Unityを使ってApplicationを作る • UnityがSceneを起点としている • アプリやチームの規模が大きくなってくると複数のSceneができる • Scene間でデータのやり取りをする仕組みが欲しくなる ↓ そうだ、Singletonを使おう。
7. Singletonが手っ取り早くて実装も簡単…だけど？ • Scene間のやり取りのために作ったのにどこからでも呼べる便利クラス化 • ボタン押したらボタン制御クラスが急にSingletonを呼び出したりしてこれどうやって 動いてるんだ…？ってなる • Singletonを1個作るとどんどん生まれる（割れ窓） • 複数のSingleton同士が依存しあって初期化を変えると全部死ぬ、処理が追えなく なる
8. Singletonが手っ取り早くて実装も簡単…だけど？ • Scene間のやり取りのために作ったのにどこからでも呼べる便利クラス化 • ボタン押したらボタン制御クラスが急にSingletonを呼び出したりしてこれどうやって 動いてるんだ…？ってなる • Singletonを1個作るとどんどん生まれる（割れ窓） • 複数のSingleton同士が依存しあって初期化を変えると全部死ぬ、処理が追えなく なる ↓ 管理コスト高くない？
9. 結局使う人による • 使用ルールを作って必要最低限だけをSingletonでカバーするとかなら全然いいと 思う • 人の入れ替わりが起こる運営型のProjectでずっと保守できる？
10. 結局使う人による • 使用ルールを作って必要最低限だけをSingletonでカバーするとかなら全然いいと 思う • 人の入れ替わりが起こる運営型のProjectでずっと保守できる？ ↓ やりたくない (できる or できない ではない)
11. 話をもとに戻します 論点はSingletonを使うか使わないか、どう使うかではなく Scene間のデータのやり取りをスムーズに行いたいだけ
12. 話をもとに戻します 論点はSingletonを使うか使わないか、どう使うかではなく Scene間のデータのやり取りをスムーズに行いたいだけ ↓ SceneLoad時に必要な情報をScene側に 良い感じに渡せれば良いだけ！！！！！
13. ポケコロツインの 実装紹介
14. Scene C ざっくりとしたイメージ ApplicationManager (MonoBehaviour) Scene B ApplicationManagerで共有で使う インスタンスを初期化しておいて Load時に各Sceneに渡す Scene A ApplicationOperator (c# class)
15. ApplicationManagerの役割 1. 起点となるSceneに設置されたGameObjectにAttachしApplicationのエントリポイ ントとなる 2. 初期化時にGameObjectをDontDestroy 3. Operatorを初期化してインスタンスを保持する
16. ApplicationOperatorの役割 1. 共通で使うインスタンスの初期化と保持 2. インスタンス同士の依存などを解決 共通で使う処理の例 Scene、UI、通信、AssetBundle、Sound、Localデータ、設定データ、ユーザーデータ…など…
17. SceneClassの定義 こんな感じのclassを継承して各Sceneに配置したGameObjectにAttachしておく
18. SceneのLoad
19. まとめ
20. 良かった点 • Singletonを使わずにScene間のやり取りを実現でき た！！！！！！ • インスタンスの使用スコープを絞ることが出来る • エントリポイントが明確なので処理が追いやすい • 再利用性が高い
21. 悪い点（？） • 学習コストが高め • 雑にApplicationManager側に処理を作られる
22. 結局、最終的には人をどうやって教育するかになりますね…
23. ご清聴ありがとうございました。