Godot でゲーム開発がしてみたい 4
趣旨、目的
Gotodのチュートリアル（GETTING STARTED）をこなしている。今回は下記のページをこなす。
Godotのデザイン哲学を学ぶことになる。
前回
前々回
前々々回
Godotのデザイン哲学（Godot's design philosophy）
この章はあくまでGodotがどのような考え方に基づいて開発されているかを知るためのもので、どのような機能をその得ているかは以下の動画を参考したほうがよい。
オブジェクト試行の設計と構成（Object-oriented design and composition）
Godotはオブジェクト指向設計を中核に据えており、柔軟なシーンシステムとノード階層を備えている。直感的にゲームを構成する方法を提供するために厳密なプログラミングパターンは遠ざけようと試みている。
一例として、Godotではシーンの合成や集約(compose or aggregate)ができる。ネストされたプレハブのようなもので、点滅ライト（BlinkingLight）シーンと、点滅ライト（BlinkingLight）を使用する壊れたランタン（BrokenLantern）シーンを作成できます。あなたは壊れたランタンで埋め尽くされた街を作ることもできる。点滅ライト（BlinkingLight）の色を変更して保存すると、街のすべての壊れたランタン（BrokenLantern）が即座に更新されます。
その上、どのシーンからでも継承できます。（上記の点滅ライト、壊れたランタン、街などをかな？）
Godotのシーンは、武器、キャラクター、アイテム、ドア、レベル、レベルの一部、などなんでも表現できます。エディターを使ってデザインしたり、ソースコードだけを使ってデザインしたり、2つを混ぜ合わせてデザインしたりと自由に開発できるが、（出来上がったものは）純粋なソースコードのクラスのように機能する。
いくつかの3Dエンジンで見られるプレハブとは異なり、それらのシーンを継承したり拡張したりすることができます。キャラクターを継承したマジシャンを作成できます。エディタでキャラクターを変更すると、マジシャンも更新されます。これにより、プロジェクトの構造がゲームのデザインと一致するように構築できます。
他の3Dエンジンで見られるプレハブとは異って、これらのシーンを継承して拡張することができます。キャラクターを継承したマジシャンを作成することができて、エディタでキャラクターを変更すると、マジシャンも更新される。これにより、プロジェクトの構造がゲームのデザインと一致するように構築できる。
また、Godotにはノードと呼ばれる種々のオブジェクトがあって、それぞれが特定の目的を持っている点に注目してください。ノードはツリーの一部で、常に親からNodeクラスまでを継承します。Godotのエンジンは親 physics body（なんだこれ？） が利用するcollision shapes(なんと訳すかわからん)のようなノードもあるが、たいていの各ノードは独立して機能します。
Sprite2Dは、Node2Dの一種であり、CanvasItemの一種であり、Nodeの一種です（これらを継承しているということだ。）。つまりSprite2Dは3つの親クラスのすべてのプロパティと機能、たとえばトランスフォームやカスタムシェーダを使ったカスタムシェイプの描画やレンダリング機能を備えています。
統括的なパッケージ（All-inclusive package）
Godotは、ほとんどの一般的なニーズに答えるために独自のツールを提供しようと試みている。専用のスクリプト・ワークスペース、アニメーション・エディター、タイルマップ・エディター、シェーダー・エディター、デバッガー、プロファイラー、ローカルおよびリモート・デバイスでのホット・リロード機能などがある。
Godotの目標は、ゲームを作成するためのフルパッケージと、継続的なユーザー体験を提供することだ。Godotで利用可能なインポートプラグインがあれば、外部プログラムとの連携は可能です。もしくは、Tiled Map Importer(なんだこれ？)のようなものを作ることもできます。
GodotがC#とともに独自のプログラミング言語であるGDScriptを提供しているのもそのためです。GDScriptはゲーム開発者やゲームデザイナーのニーズに合わせて設計されており、エンジンとエディタに緊密に統合されている。
GDScriptはインデントベースのシンタックスを使ってコードを書くことができ、しかも型を検出し、静的言語並みのオートコンプリートを提供します。また、VectorsやColorsのような組み込み型により、ゲームプレイのコードに最適化されている。
GDExtensionを使用すると、エンジンを再コンパイルすることなく、C、C++、Rust、Python（Cythonコンパイラを使用）などのコンパイル言語を使用して高性能なコードを記述できることも注目に値する。
3Dワークスペースは、2Dワークスペースほど多くのツールを備えていないことに注意してください。地形を編集したり、複雑なキャラクターをアニメーションさせたりするには、外部のプログラムやアドオンが必要です。Godotは、ゲームコードを使用してエディタの機能を拡張するための完全なAPIを提供します。下のをThe Godot editor is a Godot game 参照してください。
オープンソース（Open source）
GodotはMITライセンスのもと、完全なオープンソースのコードベースを提供している。これは、Godotに同梱されるすべてのテクノロジーも自由でなければならないことを意味する。ほとんどの場合、それらはコントリビュータによって一から開発されている。
誰でも自分のプロジェクトのニーズに合わせてプロプライエタリなツールを追加することができる。これにはGoogle AdMobやFMODが含まれます。これらはサードパーティ製のプラグインとして提供される。
一方、コードベースがオープンであるということは、思う存分エンジンから学び、エンジンを拡張できるということだ。また、Godotはスタックトレースとともにエラーを表示するので、たとえそれがエンジン自身から来たものであっても、簡単にゲームをデバッグすることができる。（できる自信ないなぁ…）
コミュニティドリブン（Community-driven）
Godotは、コミュニティによって、コミュニティのために、そしてすべてのゲームクリエイターのために作られている。ユーザーのニーズとオープンなディスカッションがコアアップデートの原動力です。コア開発者が開発する新機能は、多くの場合、最も多くのユーザー第一に考えられている。
つまり、一握りのコア開発者がフルタイムで取り組んでいるものの、このプロジェクトは執筆時点で600人を超える執筆者が所属している。良心的なプログラマーたちは、自分たちが必要とするかもしれない機能に取り組んでいるため、メジャーリリースのたびにエンジンの隅々まで同時に改良が施されることになる。
GodotエディタはGodotゲームである（The Godot editor is a Godot game）
Godotエディターはゲームエンジン上で動作する。エンジン独自のUIシステムを使用し、プロジェクトのテスト時にコードやシーンをホットロードしたり、エディタでゲームコードを実行することができる。
つまり、同じコードやシーンをゲームに使用したり、プラグインをビルドしてエディタを拡張することができる。
これは、エディタ自体をパワーアップさせるので、信頼性が高く柔軟なUIシステムにつながります。@toolアノテーションを使えば、どんなゲームコードでもエディターで実行できる。
RPG in a BoxはGodot 2版で作られたボクセルRPGエディターだ。ノードベースのプログラミングシステムとその他のインターフェースにGodotのUIツールを使用している。
（なんだこれ？）
GDScriptファイルの先頭に@toolアノテーションを付けると、エディター上で実行される。これにより、プラグインのインポートやエクスポート、カスタムレベルエディターのようなプラグインの作成、プロジェクトで使用しているノードやAPIと同じスクリプトの作成が可能になる。
2Dエンジンと3Dエンジンの分離（Separate 2D and 3D engines）
Godotは2Dと3Dの専用レンダリングエンジンを提供している。なので、2Dシーンの基本単位はピクセルになる。エンジンは別々だが、2Dを3Dでレンダリングしたり、3Dを2Dでレンダリングしたり、2Dのスプライトやインターフェイスを3Dの世界に重ねたりすることができる。
終わりに
単なる英訳articleになってしまった。。。
Discussion