*Game Programming Patterns

https://gameprogrammingpatterns.com/contents.html

ゲームプログラミングでよく使われるデザインパターンを解説しているサイト。

• 浅く広い階層にして継承する？
• ほとんどのふるまいはsubclassに入る
• オーバーライドしないと使えないことを明確にする

SuperPower

  それぞれの具体クラスで使うメソッド()
  サウンド()
  パーティクル()
  移動()
  座標取得()
  
SuperPower < SkyLaunch    
SkyLaunch
  superpowerのメソッドを用いる()

多くなって来た場合、さらに分割する。サウンド関係で分けるとか…。

SuperPower
  SoundPlayer()
  ...

SoundPlayer  
  sound()
  stop()
  setvolume()
  ...

みたいな。ベースクラスは、とにかくシンプルに保つ。

再利用可能な部品に分割する。

Component: PhysicsComponent, GraphicsComponent

• decorationはGraphicsComponentだけを持つGameObject。
• zoneはPhysicsComponent, GraphicsComponentを持つGameObject(当たり判定があるので)。

このようにして分割。

GameObjectを継承して、各Componentのインスタンスを生成することで再利用が可能。

GameObjectはComponentを集めるだけで、実際にはほとんど何もしない。

その都度すべて実行していては遅くなるのでキューに入れて実行する方式にする。 音やダメージなど、イベントをキューに入れて、処理していく。たとえば音が同時にたくさんなった場合(敵を2体同時に倒したときの断末魔)、ある数に達するとキューに追加しないなど。これによって遅くなるのを防ぎ、ゲーム体験もよくする。

キューを作るには?環状キューが便利。headとtailを用意しておいて、実行が終わったらheadを前にすすめて前の中身を削除。maxの長さに達したらheadに戻るようにする。

動的割当とコピーがなく、シンプルでキャッシュの使いやすい方法である。

イベント(event,notification)、メッセージ(message,request)、は似たような意味で使われるが、微妙な概念の違いがある。

• イベント→既におこったこと。(モンスターが死んだ)
• メッセージ→これから起こること。(音を再生する)

リスナーによって、シングルキャストとブロードキャストがある。

ガベージコレクションがある言語であれば、使わないキューのアイテムを削除するのをあまり考えなくてよい。

いつでも使えるように便利にしたい。便利で柔軟になったsingletonパターンという感じ?

service、service provider、locater。

service providerに登録する。locatorで実装と呼び出しを対応づけする(電話帳みたいに)。 他で実装を知ることはない。高度な分離。

登録されてないやつが呼ばれたときは、Null Objectを使う。