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