はじめに
- Playerクラスを作らずにプレーヤーを表現したい！という設計の話です
- すべてがそれで上手くいくわけではないですが、使える場面は多いと思います
- だいたい毎回うまくできないので、いつかうまく設計できるように考え方をメモしておきます
unityはコンポーネント思考
- UnityはGameObjectに色々なコンポーネントをアタッチして動きを作ります
- 部品を組み合わせて、ロボットを作る様なイメージです
- 細かい粒度では、位置を決定するtransformがあって、描画するためにrendererがあって、物理を制御するrigidbodyがあって、という感じ
- 独自コンポーネントもいい感じの粒度で実装します
characterクラスに集約
- transformやらrendererやらrigidbodyを制御するクラスはどうしても必要なので、それをCharacterと命名します
- CharacterにはMoverとかAttackerとかいい感じの粒度でコンポーネントを実装します
- PlayerもEnemyもCharacterです
Playerとは
- Playerっぽい動きをするCharacterがPlayerです
- なのでGameObjectのnameがPlayerであるべきだと思います
- Playerっぽい動きかどうかを決めるのはController
- ユーザーが操作するならUserControllerのアタッチされたCharacterがPlayerという名前のGameObject
Enemyとは
- AiControllerのアタッチされたCharacterが、ターゲットとしてPlayerを指定されたら、そいつはEnemyという名前のGameObject
良い点
- 鬼ごっこのゲームを作っていたら「鬼も操作できるようにして！」と言われた
- EnemyとPlayerで実装してると大変だった
- Controllerをすげ替えるだけでPlayerにもEnemyにもなれるがよい
マリオ
- マリオを作るときにmarioクラスが登場するのは具体的過ぎると感じます
- プログラムはいつだって抽象的で汎用的あったほうがいいと思う
- 1〜10を出力するのにたぶんforを使うと思います。print 1; print2;...とはしないのと同じ感じ
- プログラムはいつだって抽象的で汎用的あったほうがいいと思う
結局Playerクラスを作ってしまう
- なんだかんだ「これはPlayer！」「これはEnemy！」と書いちゃった方がラクなことが多い
- 継承したいこともやっぱりある
銀の弾丸はない
- 作りたいものによって最適な設計は変わると思う
- でも意識して作れると疎結合できれいなクラス分けくらいの設計になるのでおすすめ
