Unityで状態管理フレームワークを作った
どうも，学部３年のうじまる（id:uzimaru0000）です． 今日はUnityの状態管理フレームワーク「UniTEA」のことを書きたいと思います． 主にどういうことを考えて作ったのかを書きたいと思います．
詳しい使い方は
を見てください．
なぜ作ったのか
部活のメンバーと一緒にSPAJAM東北予選に出場した際に久々にUnityを使ったのですが，「アプリケーションの状態管理がつらすぎる．．．」っとなったので普段お世話になっているElmというWebフロントエンドの言語とそのアーキテクチャの「The Elm Architecture」を参考に状態管理フレームワークを作ってみました．
あと，Unityってフレームワーク的なものあまり無いですよね．なので結構，開発方針をしっかりと定めないとグチャグチャになりがちだったりしますよね．．．（無いなら作ればワンチャン，メジャーになる？？）
名前のTEAはこのアーキテクチャの頭文字をとってます．多分「ティー」と発音するので「UniTEA」で「ユニティー」と発音します．紛らわしいですね
設計方針
設計の方針としては「依存するライブラリをなくす」「最小限の構成にする」というものです．
依存ライブラリをなくす
このライブラリが依存するライブラリをなくすということです．端的にいうと，Unity単独で扱うことが出来るということです．
似たようなライブラリに「Unidux」というものがあるのですが，そのライブラリは「UniRx」に依存しています．
個人的にはライブラリに依存してしまうと，そのライブラリの知識が必要になり使用するまでのハードルが高くなってしまいます． また，ライブラリを開発・管理する際にもそのライブラリの更新を追っていかなければいけないのでコストがかかってしまいます．（UniRxは成熟しているライブラリなので破壊的変更をたくさん実装するようなアップデートは無いと思いますが．．．）
以上の理由から依存ライブラリをなくすように実装しました．
最小限の構成にする
依存ライブラリをなくすということは２つの選択肢があります
- 大量の機能を提供して自分で機能を全て実装する
- 最小限の機能を提供して最小限の実装にする
僕は後者を選択しました．
理由としては２つ
- 大量の機能を実装する力がない
- このライブラリが提供したいのは「The Elm Architecture」のみ
ということです．
大量の機能を実装する力がない
単純にたくさんの機能を実装・保守するだけの力が無いからです． 「その機能だったらこっちのライブラリのほうが優秀じゃん」みたいなことが起こったらこっちのライブラリは邪魔者になってしまいます．（内部で利用するにはいいかもしれないですが）
このライブラリが提供したいのは「The Elm Architecture」のみ
これにつきます．TEAしか提供したくないのです．継承するだけでシングルトンにしてくれるクラスは必要なら自分で実装すればいいのです（Uniduxが提供してます．．．） したがって，そもそも最低限の構成だけでいい，TEAを実装出来るだけの機能があれば十分なのです．
また，他の機能だったら今でてるライブラリで十分です．むしろそっちのほうが優秀です（それを提供するためだけ に全力を尽くしてるので）
だったらこちらも「TEAを提供するだけに全力を尽くします」
実装
以上のことを考えて実装しました． 結果，コアのクラスは50行くらいで終わりました（行数が全てではないですが）
作ったクラス・インターフェイスは
- UniTEA class
- IMessenger interface
- IUpdater interface
- IRenderer interface
- Cmd class
- OneValueMsg
の６つです．OneValueMsgはメインのnamespaceではなくUniTEA.Utilsの中に入っています．
基本的な使い方としては，UniTEA class を継承するのではなく，MonoBehaviorのclassに持たせる形で使用します．各インターフェイスを実装してUniTEA classの初期化時に渡すという感じです．
詳しい使い方はQiitaの記事 を参考にしたり，ソースコードのExampleを見てみてください．
最後に
依存はなくすと言いましたが，実際に使う際は「UniRx」や「UniTask」や「Zenject」を使ったほうがうまく扱えると思います．それを想定しての「最小限の構成」です．必要なら自分で入れましょう・作りましょう．
issueやPRは絶賛募集中なのでじゃんじゃん投げてください！（ついでにスターも付けてくれると嬉しいです😊)
