両方とも前のリビジョン
前のリビジョン
次のリビジョン
|
前のリビジョン
|
book:dev_game_pattern [2020/06/10 10:54] kijima [Service Locator] |
— (現在) |
====== *Game Programming Patterns ====== | |
| |
https://gameprogrammingpatterns.com/contents.html | |
| |
ゲームプログラミングでよく使われるデザインパターンを解説しているサイト。 | |
| |
===== Command ===== | |
| |
===== Flyweight ===== | |
| |
===== Observer ===== | |
| |
===== Prototype ===== | |
| |
===== Subclass Sandbox ===== | |
| |
* 浅く広い階層にして継承する? | |
* ほとんどのふるまいはsubclassに入る | |
* オーバーライドしないと使えないことを明確にする | |
| |
SuperPower | |
それぞれの具体クラスで使うメソッド() | |
サウンド() | |
パーティクル() | |
移動() | |
座標取得() | |
| |
SuperPower < SkyLaunch | |
SkyLaunch | |
superpowerのメソッドを用いる() | |
| |
多くなって来た場合、さらに分割する。サウンド関係で分けるとか…。 | |
| |
SuperPower | |
SoundPlayer() | |
... | |
| |
SoundPlayer | |
sound() | |
stop() | |
setvolume() | |
... | |
| |
みたいな。ベースクラスは、とにかくシンプルに保つ。 | |
| |
===== Component ===== | |
| |
再利用可能な部品に分割する。 | |
| |
Component: PhysicsComponent, GraphicsComponent | |
| |
* decorationはGraphicsComponentだけを持つGameObject。 | |
* zoneはPhysicsComponent, GraphicsComponentを持つGameObject(当たり判定があるので)。 | |
| |
このようにして分割。 | |
| |
GameObjectを継承して、各Componentのインスタンスを生成することで再利用が可能。 | |
| |
GameObjectはComponentを集めるだけで、実際にはほとんど何もしない。 | |
| |
===== Event Queue ===== | |
| |
その都度すべて実行していては遅くなるのでキューに入れて実行する方式にする。 | |
音やダメージなど、イベントをキューに入れて、処理していく。たとえば音が同時にたくさんなった場合(敵を2体同時に倒したときの断末魔)、ある数に達するとキューに追加しないなど。これによって遅くなるのを防ぎ、ゲーム体験もよくする。 | |
| |
キューを作るには?環状キューが便利。headとtailを用意しておいて、実行が終わったらheadを前にすすめて前の中身を削除。maxの長さに達したらheadに戻るようにする。 | |
| |
動的割当とコピーがなく、シンプルでキャッシュの使いやすい方法である。 | |
| |
イベント(event,notification)、メッセージ(message,request)、は似たような意味で使われるが、微妙な概念の違いがある。 | |
| |
* イベント→既におこったこと。(モンスターが死んだ) | |
* メッセージ→これから起こること。(音を再生する) | |
| |
リスナーによって、シングルキャストとブロードキャストがある。 | |
| |
ガベージコレクションがある言語であれば、使わないキューのアイテムを削除するのをあまり考えなくてよい。 | |
| |
===== Service Locator ===== | |
| |
いつでも使えるように便利にしたい。便利で柔軟になったsingletonパターンという感じ? | |
| |
service、service provider、locater。 | |
| |
service locatorからアクセスされ、他で実装を知ることはない。高度な分離。 | |