Godotの設計哲学

手が濡れたところで、Godotのデザインについて説明しましょう。

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

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

エンジンの機能の概要をお探しの場合は、YoutubeにあるDiscover Godot 3, the Free game engineをご覧ください。

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

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

一つには、Godotはあなたがシーンを構成または集約することを可能にします。入れ子になったプレハブのようなものです。BlinkingLightシーンと、BlinkingLightを使用するBrokenLanternシーンを作成できます。次に、BrokenLanternsでいっぱいの街を作成します。 BlinkingLightの色を変更して保存すると、市内のすべてのBrokenLantersが即座に更新されます。

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

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

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

image0

また、Godotにはノードと呼ばれるさまざまなタイプのオブジェクトがあり、それぞれに特定の目的があります。ノードはツリーの一部であり、常に親からNodeクラスまで継承します。エンジンには衝突シェイプなどのコンポーネントがありますが、これは例外であり、標準ではありません。

image1

SpriteはNode2D、CanvasItem、Nodeです。トランスフォームや、カスタムシェイプを描画してカスタムシェーダでレンダリングする機能など、3つの親クラスのすべてのプロパティと機能を備えています。

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

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

image2

目標は、ゲームを作成するための完全なパッケージと継続的なユーザーエクスペリエンスを提供することです。外部プログラム用のインポートプラグインがある場合は、外部プログラムで作業できます。または、Tiled Map Importerのように作成することもできます。

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

GDScriptはPythonに似た文法で、コードがシンプルになりますが、型を検出でき、静的言語クオリティの自動補完を実現しています。さらにVectorやColorのような組み込み型により、ゲームプレイ用コードの性能は最適化されます。

GDNativeを使用すると、エンジンを再コンパイルすることなく、C、C ++、Rust、またはPython(Cythonコンパイラを使用)などのコンパイル済み言語を使用して高性能コードを作成できます。

image3

VisualScriptは、エディタにうまく統合されたノードベースのプログラミング言語です。ノードまたはリソースをグラフにドラッグアンドドロップして、新しいコードブロックを作成できます。

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のように使えるスクリプトなどが作れます。

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

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