Up to date

This page is up to date for Godot 4.2. If you still find outdated information, please open an issue.

Godotの設計哲学

一通り学んだところで、Godotのデザインについて説明しましょう。

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

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

エンジンの機能の概要を知りたい場合は、YoutubeにあるDiscover Godot 3, the Free game engine(英語)をご覧ください。

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

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

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

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

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

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

image0

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

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

image1

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

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

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

image2

目標は、ゲームを作成するための完全なパッケージと、途切れないユーザー エクスペリエンスを提供することです。Godot で利用可能なインポート プラグインがある限り、外部プログラムを使用して作業できます。あるいは、 Tiled Map Importer のようなプラグインを作成するのもいいでしょう。

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

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

Note that with GDExtension, you can write high-performance code using compiled languages like C, C++, Rust, D, Haxe, or Swift without recompiling the engine.

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

image4

kubecz3k氏制作のGodot 2用プラグインであるステートマシン・エディタ。状態および遷移を視覚的に整理できます。

オープンソース

GodotのコードベースはMITライセンスのもとで完全にオープンソースとなっています。これはつまり、Godotエンジンに付属するコードは、フリー(自由)でなければならない、ということです。それらのコードはほとんどの場合、人々の貢献によって開発されたものです。

もしプロジェクトに必要とあれば、プロプライエタリ(非オープン)なプラグインを追加することは可能ですが、しかしエンジンに最初から付属はしていません。これにはGoogle AdMobやFMODなどが当てはまるでしょう。いずれもサードパーティーのプラグインとして追加できます。

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

注釈

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

コミュニティ主導

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

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

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

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

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

image5

Godot 2でつくられたボクセルRPGエディタ『RPG in a Box』。ノードベースのプログラミング・システムおよびユーザーインターフェースに、GodotのUIツールが使われています。

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

注釈

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

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

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