Unityで作品を作るなら、一度オブジェクト図を書いてみよう
Unityでゲーム制作を進めていると、途中でこんな状態になることがあります。
- Scriptが増えてきた
- 変数が増えてきた
- どこが何を管理しているのか分からない
- 自分で書いたコードなのに追えなくなる
これは珍しいことではありません。
むしろ、作品が大きくなってきた証拠でもあります。
そんなときに役立つのが オブジェクト図 です。
オブジェクト図って何？
難しく考えなくて大丈夫です。
オブジェクト図とは、
「ゲーム内の登場人物や部品が、誰と繋がっているかを図にしたもの」
と思ってください。
例えばシューティングゲームなら、
- Player
- Enemy
- Bullet
- GameManager
のような登場人物がいます。
これを図にすると、例えばこうなります。
GameManager
├ score
├ timer
└ player → Player
Player
├ hp
├ speed
└ weapon → Weapon
Weapon
└ damageこれだけでも、かなり頭が整理されます。
なぜ役立つのか
1. 誰が何を持っているか分かる
例えばコードでこう書いていたとします。
public GameManager manager;コードだけ見ると、分かった気になります。
でも図にすると、
PlayerController
manager ───→ GameManagerとなります。
ここで見えてくるのは、
- PlayerController が
- GameManager を参照している
という関係です。
コードを読むだけより、構造が見えやすくなります。
2. クラスと実体の違いが見える
C#でつまずきやすいポイントの1つです。
例えば、
Enemy enemy;これを見て、
Enemyが作られた
と思う人は多いです。
でも実際は違います。
この時点では、
- Enemy型の変数があるだけ
- 実体はまだないかもしれない
です。
つまり、
enemy = nullかもしれません。
この違いは、図にすると理解しやすいです。
3. バグの原因を探しやすい
Unityでよくあるエラー。
NullReferenceExceptionこれは多くの場合、
参照先がない
ことで起きます。
図を書けば、
Player → GameManagerの矢印が切れていることに気づけます。
すると、
- Inspectorで設定し忘れた
- Findで取得できていない
- 生成順がおかしい
などの原因を探しやすくなります。
UMLみたいに難しく書かなくていい
ここで誤解してほしくないのですが、
オブジェクト図を書くために
UMLを全部覚える必要はありません。
例えばこういうものは、最初は不要です。
- 多重度
- 集約
- コンポジション
- 可視性
- 関連名
実務では使うこともありますが、今はそこまでいりません。
まずは、
- 箱を書く
- 名前を書く
- 矢印で繋ぐ
これだけで十分です。
設計のためだけではない
オブジェクト図は、
- 作る前の設計
だけでなく、 - 詰まった時の整理
にも使えます。
私は授業でも、
コードをいきなり直す前に、図を書いて整理しよう
と言うことがあります。
図にすると、
「あ、管理役が2人いる」
「同じ責務を2箇所で持っている」
といった問題が見えるからです。
Unity学習で大事なこと
Unityでは、
- Scene上のGameObject
- Component
- C#クラス
- インスタンス
- 参照
が同時に出てきます。
ここが難しい。
だからこそ、
頭の中だけで管理しないこと。
紙でもホワイトボードでもいいので、一度描いてみてください。
描けないなら、まだ理解が曖昧な場所があります。
逆に描けるなら、かなり整理できています。
まとめ
Unityで作品制作中に、
- 何が何を管理しているか分からない
- 参照関係が追えない
- NullReference が頻発する
そんなときは、オブジェクト図を書いてみましょう。
たった数分でも効果があります。
コードを書く力も大事です。
でも、
構造を説明できる力
は、それ以上に大事です。
ゲームが複雑になるほど、この差が大きくなります。