Unityチュートリアルの玉転がしで、設計について考えてみた話

Unityと設計の話

Transcript

1. Unityチュートリアルの玉転がしで、 設計についてかんがえてみた話 むーさん
2. きっかけ 友達「いつも綺麗なコードを心掛けているけど、 Unityやると萎える。」
3. よくあるやつ(チュートリアルの玉転がし)
4. 関数分けたい 全部FixedUpdateでやってる 関数を分ける
5. クラスの名前変えたい PlayerController？ PlayerMover！
6. 依存度が高い Editorの入力しか受け付けない いろんな入力を同じ方法で受け取れる
7. インターフェースは利用する側で定義する PlayerがInputに依存している 入力の仕方によって、 依存するものを変えなきゃあいけない いろんな入力を同じ方法で受け取れる
8. よくあるやつ(チュートリアルの玉転がし)
9. 型安全性が皆無 Playerというタグが存在しなくても、 コンパイルエラーにならない Unityで設定しておかなきゃいけない
10. 汎用性も皆無 プレイヤーじゃないやつもItemをとりたい
11. Itemが取得されたタイミングがわからない いつItemが取得されたのか Itemが取得されたから何が起こるのか なにもわからない
12. ちなみにチュートリアルでは 毎フレームItemを全部とってきて 個数をその都度、UIに更新している
13. こうする Tagの代わりに、IItemGetterという インターフェースを定義する。 これを継承したオブジェクトにぶつ かったとき、そのオブジェクトの コライダーを通知する。
14. 使い方 Itemを継承したクラスにて、 そのアイテムの効果を記述して、 Item.OnGotに登録する。 いろんな効果のItemを作れて便利
15. デデドン(IObservableってなんだよ)
16. UniRxでggr Unity用のRxライブラリ C#のRx(リアクティブエクステン ション)がもとになっている Rxとは、Observerパターンが根幹 にある、監視型イベントシステム である UIの構築などにめっちゃ便利！！
17. 試行錯誤の末に
18. Playerに必要なコンポーネント • PlayerCore • PlayerMover • PlayerInputByKeyBoard • ScoreHolder それぞれは一切依存していないので、 それぞれの部品を好きにつけかえて、 自分だけのプレイヤーを作ることができる
19. 全部自分でつけるの？？ 小さいプロジェクトなら自分でやっ てもいいけど、 大規模な開発で、コンポーネントを 一個一個つけるのめんどくさい
20. Zenjectでggr Unity用の、DIコンテナライブラリ 依存性の注入をする 方法や引き出しを、 大幅に増やしてくれるらしい 最近流行っている(?) テスト書くときも便利
21. DIコンテナってなに？ なにもわからない
22. 結論 • 型安全にしよう 正しくない書き方をしたらコンパイルエラーにしよう • インターフェースを定義しよう 利用の仕方を定義して、汎用性を高くしよう • コンポーネントを細かく分けよう 一つのコンポーネントは一つの役割にしよう