Unity上級者が使っているUniTask/UniRx/DIライブラリ(VContainer/Zenject)は、どんな順番で勉強するのがよい？

※注意※
エンジニアとしての仕事はしているけど、所詮毛が生えた程度の独学プログラマが書いているまとめなので、あんまりアテにしないでください。

結論

UniTask　→　UniRx　→　DIライブラリ（VContainer/Zenject）

説明

１．UniTask

コルーチンを代替するもの、けど、コルーチンよりも絶対に使いやすい。流れでコードが書けるのがよき。
正直、始めたての人は、コルーチンなんて覚えずにUniTaskから覚えた方がラクまである。学習コストも高くない。

コルーチンの方が情報は多いけど、いまはChatGPTとかあるしなんとかなる（適当）。

２．UniRx

次がUniRx。
UniRxが輝くのは、UIに絡む部分。たとえば、HPの値が変化したらUIのゲージの値を変化させる、みたいなそういうことが出来る。

UniRxが無いと、Updateの中で毎フレーム数字の変化を検知しないといけないので非常に無駄。変化があったときだけ処理すればいいからね。
（一応C#のイベントやコールバックを使えば実装出来るけど、UniRxの方が高性能）

けど、初心者がいきなりUniRxにチャレンジする必要はない。なぜならUniRxが無いと実装出来ない！というものはほぼないと思う。
さっき書いたように、シングルトンパターンをゴリゴリに使ったり、Update文にいろんなことを書いたりすれば、UniRxがなくても実装出来る。

無駄なく、シンプルにわかりやすくて拡張性のあるコードのために必要、というのが私の理解。
ある程度自分でUIやゲーム部分を実装出来るようになった後に、もっと無駄なく、よい設計のゲームを作りたい！、と思ってから手を出すくらいで良いと思う。

最初は覚えることが多いので、普通に難しい。学習コスト高い。

けど触り部分だけでも、一度使えるようになると本当にラク。なにがラクかって、コードの内容が直感的に理解しやすくなること。
UniRxを使わない実装にはもう戻れなくなる（体験談）。

３．VContainer（Zenject）などのDIライブラリ

私見だけど、職業Unityエンジニアを目指しています！とか、大規模ゲームを作る！とかでなければ使わなくてもよいと思う。

簡単にこいつらがどういう目的のものなのかを説明しておく。誤解を恐れず、初心者でも理解出来るワードで書きます。

まず、DI（DenpencyInjection、依存性注入）というのは、このクラスがどのオブジェクト（インスタンス）を使うかを指定すること。
インスペクタでなんかのコンポーネントをアタッチする作業をよくすると思うけど、これも一つの依存性注入。

で、DIライブラリでやりたいのは、MonoBehaviourを継承しないクラス（以後、PureC#）と、Monobehaviorを継承するクラス間の依存をうまーく解決すること。

そもそも、Unityでコードを作るときに絶対に見る、MonoBehaviourという存在は、過剰に高機能なクラス。
たとえば、現在のプレイヤーの保持コインの値を保持して、増やす/減らすみたいな処理をするだけのクラスにMonoBehaviourは過剰。

さらに、Unityのシーンはオブジェクトの生成と破棄が短期間に行われる怖い場所。そんなところに消されたくないデータを保持するクラスがいるのって、ちょっと怖い。

なので、データに関する部分（MV(R)PモデルのModel部）に該当するクラスとかは、Monobehaviorを継承しないPureC#のクラスに保持しておきたい。

しかし、MonoBehaviourを継承していないクラスはUnityのシーン内に配置出来ない。
PlayerのHPデータを保持しているModelが持っている値をUIに表示する、みたいなことをするには、PureC#のPlayerのHPデータを管理するクラスと、Monobehaviorを継承したUIを表示するクラスとの間の、依存関係を解消しないといけない。
（※ModelとViewの間にPrensenterが入っているケースも同様）

そこで出てくるのがDIライブラリ。
DIライブラリがあると、上に書いた困りごとをうまーい感じに解決してくれる（適当）。

VContainerなら、LifeTime.Singletonを使えば、シーンをまたいで大事なModel部の値も保持出来る、安心。
逆に言えば、PureC#を使う想定がないなら、DIライブラリを使うメリットがあまり無いので、使わなくてよいと思う。

まとめ

個人的には、小規模ゲームであれば、PureC#を使わなくても良いと思った。
もちろん、設計やヒエラルキーがキレイにはなるメリットはあるけど、直感的な分かりやすさは下がると思う。
そのシーンで使われる要素が全部シーン内にあった方が、そりゃ分かりやすいじゃん。

あと、Model側で持っている変数を確認しようと思った時に、毎回Debugログに出すのが面倒くさかった。（これってなにか良い方法あるんですかね？）

コルーチンの代わりにUniTaskにするなら、そこまで難しい内容は無いと感じたので、バンバン使った方がよいと思う。

UniRxは、学習コストが高いので”慣れていれば”使った方がよいと思う。
ただ、1週間ゲームジャムで、UniRxの使い方を学習しながら作ります！、みたいなのは、自分には厳しかった。
使い方を慣らしてからでないとすぐに順応するのは難しいと思う。

最後に、どんだけキレイな設計を作っても、ゲームの内容の評価には影響しないからね。

良いゲームを作るために良い設計は必ずしも必要ではない。
こういうことを勉強したから、ゲームが面白くなるなんてことはないです。目的を履き違えないように。

自分にはちょっとむずかしそう、と感じたなら、ゲームをもっと面白くするには？もしくは、面白そうなゲームに見せるには？
ということを優先するのも、ありだとは思います。