Q&A
なるほど！いつもManagerクラスはすべてシングルトンにしてましたが、そういった管理方法あるんですね。
こちらも勉強になりました。Manage系はGameObject分けた方が良さそうですね！
ゲームを作っていると、GameManagerやSoundManagerといったManagerスクリプトを書くことがあると思います。(シングルトン問わず)
思いつく限りだと、下記①～③の手法がとれると思うのですが、
書籍を見ると③がほとんどです。
これは何かしらの管理しやすい理由があるのでしょうか。
Prefab化しやすいなど。
Camera.mainなどでアクセスできることが多いので①が便利だと思うのですが、②や③のソースが多いです。
この辺、こういう理由でこんな感じにしてるよーとかありましたらご教示いただきたいです。
① メインカメラにアタッチ
CameraMain
-- hoge1Manager.cs
-- hoge2Manager.cs
-- hoge3Manager.cs
② Managerクラス専用のGameObjectを用意してアタッチ
hogeManager
-- hoge1Manager.cs
-- hoge2Manager.cs
-- hoge3Manager.cs
③ ManagerクラスごとにGameObjectを用意してアタッチ
hoge1Manager
-- hoge1Manager.cs
hoge2Manager
-- hoge2Manager.cs
hoge3Manager
-- hoge3Manager.cs
回答2件
0
Managerたちを統括するManagerを作るという手もあります。
https://gamedev.stackexchange.com/questions/184826/efficient-way-to-implement-a-lot-of-singletons/184829#184829
①に関してはカメラ＝Managerというのが個人的に繋がらないというのと
Camera.main は GameObject.FindGameObjectWithTag("MainCamera").GetComponent<Camera>();と同義だったかと思うので頻繁に呼ぶようならカメラの参照は最初にとったほうが良いです。
投稿2021/03/03 01:23
総合スコア3302
0
ベストアンサー
私は②③を合わせた感じです。
その方がInspectorを見たときに目次みたいな感じで作業しやすいです。
https://kazupon.org/unity-ui-optimize-tips/
今はどうか知らないですけど、Camera.mainは重たいと聞きました。
以下のような例です。
System
-- Singleton.cs
Equipment
-- EquipmentManager.cs
-- UserEquipment.cs
Ads
-- AdsManager.cs
Item
-- ItemManager.cs
-- Inventory.cs
ちょっと論点ずれるかもですけど、
SystemオブジェクトにSingleton.csっていうのを付けてます。
GameObject.Findとtransform.FindだったらGameObject.Findの方が圧倒的に重たいんです。
なので
SystemオブジェクトのSingleton.csにSystemオブジェクト本体を
Transformで取得できるようにしておけば、Systemオブジェクト以下のManagerクラスを
Singleton.Instance.GetSystemObject.Find("Equipment").GetCompo...
のようになるべく軽量に取得できますよね！
さらにGetComponentの回数を減らしたいなら
Singleton.csにSystem以下のクラスを全てGetComponentして保持しておいて、それを使いまくります。
Singletonってすごくぐちゃぐちゃしちゃうイメージだけど、
それはクラスメソッド内でシングルトンをぐちゃぐちゃ使うからで、
コンストラクタ的なところで使うクラスをメンバ化しちゃえばそんなにゴチャゴチャ感ないですよね？
クラス単位での参照は１箇所になるわけだし、Getcomponentの代わりにSingleton.Instance.GetScriptみたいになるわけですから。
無駄話でした。
投稿2021/03/02 17:36
総合スコア110
あなたの回答
tips
プレビュー
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
2021/03/03 04:29