Godotの設計思想について

一通り学んだところで、Godotの設計思想について説明しましょう。

すべてのゲームエンジンは、それぞれ別のニーズに合わせて作られています。単に機能の違いだけではなく、エンジンによって異なる設計がされているのです。これにより、ワークフローや、ゲームを構築する方法に違いが生じます。これらはすべて、それぞれの設計思想に由来するものです。

このページは、Godotがどのように機能するのかを理解するのに役立ちます。これは利用可能な機能のリストでもエンジンの比較でもありません。自分のプロジェクトに適したエンジンがあるかどうかを知るには、自分で試してみて、その設計と制限を理解する必要があります。

エンジンの機能の概要を知りたい場合は、 Godot explained in 7 minutes をご覧ください。

オブジェクト指向の設計と構成

Godotは、柔軟なシーンシステムとノード階層を備えたオブジェクト指向設計をコアに採用しています。ゲームを直感的に構築する方法を提供するために、厳密なプログラミング・パターンを避けています。

一例として、Godotはあなたがシーンを構成または集約することを可能にします。これは入れ子になったプレハブのようなものです。BlinkingLight(ちらつく光) シーンと、そのBlinkingLightを使用するBrokenLantern(壊れたランタン) シーンを作成できます。その次に、BrokenLanternでいっぱいの街を作成します。それからBlinkingLightの色を変更して保存すると、街にあるすべてのBrokenLanternが即座に更新されます。

それに加えて、あらゆるシーンから継承することができます。

Godotのシーンは、武器になったり、キャラクター、アイテム、ドア、レベル、レベルの一部……など、何にでもなれます。これは純粋なコードにおけるクラスのような働きをします。しかしシーンは、エディタのみを使って作ることも、コードのみで構成することも、あるいは両方組み合わせて作成することもできます。

これは、いくつかの3Dエンジンにあるようなプレハブとは異なるものです。シーンは他のシーンから継承し、派生させることができます。キャラクターから派生させて魔法使いを作ることもできます。そしてキャラクターをエディタで編集すれば、魔法使いにも変更が反映されます。このように、ゲームのデザインに合わせてプロジェクトを構築する助けとなります。

image0

また、Godotにはノードと呼ばれるさまざまなタイプのオブジェクトがあり、それぞれに特定の目的を持っていることに注意してください。ノードはツリーの一部であり、常に親からNodeクラスまでを継承します。エンジンには、親の物理ボディが使用するコリジョンシェイプなどのノードがありますが、ほとんどのノードは互いに独立して動作します。

つまりGodotのノードは、他のゲームエンジンのコンポーネントのようには動作しない、ということです。

image1

Sprite2D は Node > CanvasItem > Node2D と継承した Node です。 これには、トランスフォームやカスタムシェイプの描画やカスタムシェーダーでのレンダリングなど、3 つの親クラスのすべてのプロパティと機能が備わっています。

オールインワン・パッケージ

Godotは最も一般的なニーズに答えるために、備えているツールを提供しようとします。専用のスクリプトワークスペース、アニメーションエディタ、タイルマップエディタ、シェーダエディタ、デバッガー、プロファイラー、ローカルおよびリモートデバイス上でのホットリロードなどが可能です。

image2

目標は、ゲーム作成のための完全なパッケージと継続的なユーザーエクスペリエンスを提供することです。Godot にインポートプラグインが用意されている限り、外部プログラムとの連携も可能です。

これが、Godot が C# とともに独自のプログラミング言語 GDScript を提供している理由の 1 つでもあります。 GDScript は、ゲーム開発者とゲーム デザイナーのニーズに合わせて設計されており、エンジンとエディタに緊密に統合されています。

GDScriptでは、インデントベースの構文を使ってコードを書くことができ、しかも型を検出して静的型付け言語並の品質のオートコンプリートを提供します。また、ベクターやカラーなどの組み込み型を使ったゲーム開発用のコードに最適化されています。

GDExtension を使用すると、エンジンを再コンパイルせずに、C、C++、Rust、D、Haxe、または Swifit などのコンパイル済み言語を使用して高性能コードを作成できることに留意してください。

3Dワークスペースには、2Dワークスペースほど多くのツールはありません。地形を編集したり、複雑なキャラクターをアニメーション化したりするには、外部プログラムやアドオンが必要です。Godotは、ゲームコードを使用してエディタの機能を拡張するための完全なAPIを提供しています。下の The Godot editor is a Godot game を参照してください。

オープンソース

Godotは MITライセンス に基づき、完全にオープンソースのコードベースを提供しています。つまり、ライセンスファイルがそのまま保持されている限り、誰でもコードベースを無料でダウンロードして使用したり、変更や共有をすることができます。

Godotに同梱されるすべてのテクノロジー（サードパーティ製ライブラリを含む）は、このオープンソースライセンスに法的に準拠している必要があります。そのため、Godotの大部分はコミュニティの貢献者によってゼロから開発されています。

誰でもプロジェクトのニーズに合わせて独自のツールを追加できます (それらは単にエンジンとともに配布されていないだけです)。これには Google AdMob や FMOD などが当てはまるでしょう。いずれもサードパーティー製のプラグインとして追加できます。

一方、コードベースがオープンであるということは、心ゆくまでエンジンの内部を学んだり、拡張することができます。またこれによりGodotは、エンジン自身のものも含めて、スタックトレース付きのエラーを表示できるので、ゲームのデバッグがより容易になります。

注釈

これはGodotで作られた作品にはなんら影響をおよぼしません。Godotエンジン自体にも、それで作られたものにも、使用条件が課されることはありません。

コミュニティ主導

Godotは、そのコミュニティによって、コミュニティのために、そしてすべてのゲームクリエイターのために作られています。コアアップデートを推進するのは、ユーザーのニーズとオープンな議論です。コア開発者が提供する新機能は、多くの場合、最も多くのユーザーにメリットをもたらすものに重点が置かれます。

つまり、フルタイムで働くコアの開発者はわずか数名ですが、このプロジェクトには現時点で数千名を超える貢献者がおります。善意のプログラマーの方々が自分自身の求める機能を追加していくので、メジャーリリースのたびにGodotエンジンのあらゆる点が改善されていくのです。

Godotエディタ自身がGodotのゲーム

Godotエディタもゲームエンジン上で動作しています。 エディタは、エンジン自身のUIシステムを使用しており、プロジェクトのテスト時にコードやシーンをホットリロードしたり、エディタ内でゲームコードを実行したりできます。つまり、ゲームと同じコードとシーンを使用したり、プラグインを構築してエディタを拡張することもできます。

これにより、エディター自体が強化されるため、信頼性が高く柔軟な UI システムが実現します。 @tool アノテーションを使用すると、エディターで任意のゲーム コードを実行できます。

../../_images/introduction_rpg_in_a_box.webp

RPG in a Boxは、Godotで作られたボクセルRPGエディタです。ノードベースプログラミングシステムとその他のインターフェースには、GodotのUIツールが使用されています。

GDScript ファイルの先頭に @tool アノテーションを追加すれば、エディタ内で動かせます。 これにより、プラグインのインポートとエクスポート、カスタム レベル エディターなどのプラグインの作成、プロジェクトで使用するものと同じノードと API を使用したスクリプトの作成が可能になります。

注釈

エディタは完全にC++で書かれており、静的にバイナリにコンパイルされています。つまり、 project.godot のファイルを持つような典型的なプロジェクトとしてインポートすることはできません。

2Dと3Dのエンジンを分割

Godotには2Dと3Dでそれぞれ別の描写エンジンを搭載しています。その結果、2Dシーンの基本単位はピクセルです。描写エンジンは分離していますが、3D内で2Dレンダーも、2D内で3Dレンダーも、3Dワールドの画面に2Dスプライトやインターフェースをオーバーレイすることもできます。