Godot Design Pattern
save formatをbinaryにするだけならstore_*()を使うとよい
解析を難しくしたいなら、保存時に
var2strを使うと様々ンデータをテキスト形式で保存する
どの行がなんの情報かはこちらで管理する必要があるが、バイナリのように解析が難しいがテキストデータとして保存できる
命名
singaleは過去形
すべてのシーンは常に独立して稼働するようにしておく
rootに必要なシグナルを定義して、外部とうまく接続できるようにしておくとよい
シーンの継承はするな
必要があれば別言語を採用する
型安全がなかったり、ほかの言語に比べてgdscript自体はまだまだ発展途上
web buildできないなど制約も強いのでトレードオフ
duck typingは受け入れろ
entity-component pattern
entity-component system(ECS)を参考にして、godot nizedした実装パターン
godot独自の解釈をしている.
あくまでcompositionの柔軟性を実現するために思想を拝借しているだけで従来のECSとは意味合い違う
componentをノードとして設計
componentをentitiyの子ノードとして持たせる
entityにどのcomponentを持たせるかで自由にentityをカスタマイズできる
継承ベースで発生しがちな多重継承が必要なケースもこれでカバーできる
coomopnentはpropertyとシグナルをもつ
compomentの関数は自身のpropertyを変更してシグナルを発信するのみを行う
誰がシグナルを受け取るか、だれがproperty変更の関数を実行するかはcomponentは知らない
componentをまとめて管理するsystemの実装
systemはcomponeごとtの共通処理を実行するイメージ
gravity componetがあったら各componentへ力を加える処理を実行するイメージ
詳細なgravity加速度の値はcomponentごとに違う可能性もあり、つまりentityの挙動に違いがでる
ただしgravity componentをもつ各entityが重力の影響を受けるのだけは共通
特定のcompoenetをもつentityの一斉更新とかしたいときにsystemを経由する
systemクラスはReferenceクラスの拡張としてつくるとよい
event bus pattern
AutoLoadでsinaglをemitするだけのシングルトンノードEventsを用意。
このEventsで各signalの定義を行う
Events.hogeでそれぞれのノードはsignalをemitしたり、singalとmethodをconnectする。
singalをグローバルなsingltonで定義することで、シーン問わずにsignalの送受信を行える
https://www.youtube.com/watch?v=S6PbC4Vqim4&ab_channel=GDQuest
Mediator
多数のオブジェクト同士の直接の相互依存をやめさせるために中継するMeditatorを作る
各オブジェクトはMeditorに依存を中継させることで、各オブジェクトの依存関係をシンプルにする。
godotではシーンのroot nodeをMediatorとするのが便利
root nodeは子ノードへメソッド呼び出しと子ノードから発信されるシグナルを移譲する
Meditatorへのsetter, getterを経由して、必要なノードへのget,setを行う
他のノードからはmeditorの変数set,getしているだけだが、実際は子ノードへのset,getになる
Mediatorは複数の子ノードのsingalをいったん受けて、それを再度別のsignalとして再emittする
子ノードが複数いても、すべてMediatorからの1つのsignalに集約されるのがポイント
Mediatorは処理の集約も行う
一つの処理で複数の子ノードに行う必要がある場合は、その一連の処理をMeditoarでまとめて記述
一つの処理に足して、それぞれの子ノードで処理を書かなくてもよくなる
code formatter