UnityからGodot Engineへ¶
このガイドでは、Unityユーザーの観点からGodotエンジンの概要を説明し、既存のUnityエクスペリエンスをGodotの世界に移行する手助けをすることを目的としています。
注釈
この記事では、Unityの古いバージョンについて説明します。ネスト可能なプレハブ('Nested prefabs')がUnity 2018.3に追加されました。 ネスト可能なプレハブはGodotのシーンに似ており、シーンの編成に、よりGodotのようなアプローチを可能にします。
違い¶
| Unity | Godot | |
|---|---|---|
| ライセンス | 収益上限と使用制限を備えた、独自のクローズドライセンス、無料ライセンス | MITライセンス、自由で完全にオープンなソースを制限なし |
| OS(エディタ) | Windows、macOS、Linux | Windows、macOS、X11 (Linux, *BSD) |
| OS(エクスポート) |
|
|
| シーンシステム |
|
Scene tree and nodes 、シーンをネストしたり、他のシーンを継承したりできます |
| サードパーティ製ツール | Visual StudioまたはVisual Studio Code | |
| 注目すべき利点 |
|
|
エディタ¶
Godoエンジンは、ゲームの構築を可能にする豊富な機能を備えたエディタを提供します。以下の図は、両方のエディタのデフォルトのレイアウトを色付きのブロックで表示して、共通する機能を示しています。
両方のエディタは似ているように見えるかもしれませんが、表面の下には多くの違いがあります。どちらもファイルシステムを使用してプロジェクトを整理できますが、Godotのアプローチは、単一の構成ファイル、最小限のテキスト形式、メタデータなしでより簡単です。これにより、Git、Subversion、MercurialなどのVCSシステムでGodotがより使いやすくなります。
GodotのSceneパネルはUnityのHierarchyパネルに似ていますが、各ノードには特定の機能があるため、Godotで使用されるアプローチは視覚的にわかりやすくなっています。シーンが何をしているのかが一目でわかります。
Godotのインスペクタは最小限であり、プロパティのみを表示します。これにより、オブジェクトは、言語APIの機能を隠すことなく、より有用なパラメーターをユーザーに公開できます。さらに、Godotではこれらのプロパティを視覚的にアニメーション化できます。コードを記述する必要なく、色、テクスチャ、列挙、またはリソースへのリンクをリアルタイムで変更できます。
画面上部のツールバーは両方のエディタで似ており、プロジェクトの再生を制御できます。 Godotのプロジェクトは、エディター内ではなく、別のウィンドウで実行されます(ただし、ツリーとオブジェクトは、デバッガウィンドウで引き続きGodot内で探索できます)。
このアプローチにはいくつかの利点があります:
- プロジェクトの実行と終了は高速です (Unity は、プロジェクトを保存して実行し、プロジェクトを閉じてから、前の状態を再度読み込む必要があります)。
- ライブ編集は、エディタに加えた変更がゲーム内で直ちに有効になり、ゲームが閉じられても失われない(同期する必要がない)ため、はるかに便利です。これにより、プレイ中にレベルを作成するなどの素晴らしいワークフローが可能になります。
- ゲームは別のプロセスで実行されるため、エディタはより安定しています。
- エディタビューポートの「カメラの置き換え」ボタンをトグルすると、エディタビューとゲームカメラビューを切り替えることができ、実行中のゲームをさまざまな角度から探索することができます。
最後に、Godotの上部のツールバーには、リモートデバッグ用のメニューが含まれています。これらのオプションを使用すると、デバイス(HTML5を介して接続されたスマホ、タブレット、またはブラウザー)への展開、およびゲームのエクスポート後のデバッグ/ライブ編集が可能になります。
シーンシステム¶
これは、UnityとGodotの最も重要な違いであり、ほとんどのGodotユーザーのお気に入りの特徴です。
Unityの「レベル」で作業することは、通常、シーンにすべての必要なアセットを埋め込み、コンポーネントおよびスクリプトとリンクすることを意味します。
Godotのシーンシステムは、表面的にUnityに似ています。 「レベル」は、それぞれ独自の目的(スプライト、メッシュ、ライトなど)を持つノードのコレクションで構成されます。ただし、Godotでは、ノードはツリーに配置されます。各ノードは複数の子を持つことができ、それぞれがメインシーンのサブシーンになります。これは、異なるファイルに保存された異なるシーンでシーン全体を構成できることを意味します。
たとえば、プラットフォーマーレベルを考えてみましょう。複数の要素で構成します:
- レンガ
- コイン
- プレイヤー
- 敵
Unityでは、すべてのGameObjectをシーンに配置します:プレイヤー、敵の複数のインスタンス、レンガを至る所に配置してレベルの地面を形成し、次にレベル全体にコインの複数のインスタンスを配置します。次に、さまざまなコンポーネントを各要素に追加してそれらをリンクし、レベルにロジックを追加します。たとえば、BoxCollider2Dをシーンのすべての要素に追加して、それらが衝突できるようにします。この原則はGodotでは異なります。
Godotでは、シーン全体を3つの独立した小さなシーンに分割し、メインシーンでインスタンス化します。
- プレイヤーだけのシーン
プレイヤーを、異なる親シーン(たとえば、「レベル」シーン)で使用する要素として考えます。この場合、プレイヤー要素には少なくともAnimatedSpriteノードが必要です。このノードには、さまざまなアニメーション(歩行アニメーションなど)に必要なスプライトテクスチャが含まれています。
- 敵のシーン
敵は、いくつかのシーンで使用したい要素でもあります。プレイヤーノードとほぼ同じですが、唯一の違いは、そのスクリプト (敵の行動を生成するために AI ルーチンが必要) と、AnimatedSpriteノードで使用されるスプライトテクスチャです。
- レベルシーン
Levelシーンは、レンガ(プラットフォーム用)、コイン(プレイヤーが収集するため)、およびいくつかの敵シーンのインスタンスから構成されます。各インスタンスは、Levelシーンツリー内のノードです。これらのインスタンスは別々の敵であり、初期状態では敵シーンで定義された動作と外観を共有しています。敵のノードごとに、異なるプロパティを設定できます (たとえば、個々の色を変更するなど)。
4. A Main scene. The Main scene would be composed of one root node with 2 children: a Player instance node, and a Level instance node. The root node can be anything, generally a "root" type such as "Node" which is the most global type, or "Node2D" (root type of all 2D-related nodes), "Spatial" (root type of all 3D-related nodes) or "Control" (root type of all GUI-related nodes).
ご覧のとおり、すべてのシーンはツリーとして整理されています。ノードのプロパティについても同じことが言えます。コリジョンコンポーネントをノードに 追加 して、Unityのように衝突可能にしないでください。代わりに、このノードを衝突プロパティを持つ新しい特定のノードの 子 にします。 Godotには、使用法に応じてさまざまな衝突タイプのノードがあります( Physics introduction を参照)。
このシステムの利点は何ですか？このシステムはシーンツリーの深さを潜在的に増加させませんか？また、Unityではすでに、空のGameObjects内にGameObjectsを配置して、それを整理することを許可していませんか？
- Godotのシステムは、よく知られているオブジェクト指向のパラダイムにより近いものです。Godotは、明らかに「ゲームオブジェクト」ではない多くのノードを提供しますが、子には独自の機能を提供します:これは継承です。
- Godotでは、シーンのサブツリーを抽出して、それを独自のシーンにすることができます。そのため、シーンツリーが深くなりすぎると、より小さなサブツリーに分割できます。任意のサブツリーを任意のノードの子として含めることができるため、これは再利用性がより優れています。 Unityの空のGameObjectに複数のGameObjectを配置しても、同じ機能は提供されません。
プロジェクトの構成¶
完璧なプロジェクトアーキテクチャはありません。 UnityおよびGodotで動作するように、任意のアーキテクチャを作成できます。
ただし、Unityプロジェクトの一般的なアーキテクチャでは、ルートディレクトリにAssetsフォルダが1つあり、このフォルダ内に、オーディオ、グラフィック、モデル、マテリアル、スクリプト、シーンなど、アセットの種類ごとにさまざまなフォルダが含まれます。
Godotではシーンを小さなシーンに分割することができるため、各シーンとサブシーンはプロジェクト内のファイルとして存在します。そのため、プロジェクトを少し異なる方法で整理することをお勧めします。このwikiはこのためのページを提供します: プロジェクトの構成。
プレハブはどこですか?¶
Unityによって提供されるプレハブは、シーンの「テンプレート」要素です。これは再利用可能で、シーン内に存在するプレハブの各インスタンスはそれ自体の存在を持ちますが、それらのすべてがプレハブで定義されているものと同じプロパティを持ちます。
Godotはプレハブ自体を提供しませんが、同じ機能がシーンシステムによって提供されます。シーンシステムはツリーとして編成されます。 Godotでは、シーンのサブツリーをシーンファイルとして保存できます。この新しいシーンは、任意のノードの子として、何度でもインスタンス化できます。この新しい個別のシーンに加えた変更は、そのインスタンスに適用されます。ただし、インスタンスに加えた変更は、「テンプレート」シーンには影響しません。
正確には、インスペクタパネルでインスタンスのパラメーターを変更できます。このインスタンスを構成するノードは、最初はロックされています。必要に応じて、シーンツリーでインスタンスを右クリックし、メニューで[編集可能な子]を選択してロックを解除できます。このノードに 新しい 子ノードを追加するためにこれを行う必要はありません。新しい子は、ディスク上の「テンプレート」シーンではなく、インスタンスに属することに注意してください。 「テンプレート」シーンのすべてのインスタンスに新しい子を追加する場合は、「テンプレート」シーン自体に追加する必要があります。
用語集の対応¶
- GameObject(ゲームオブジェクト) -> Node(ノード)
- Add a component(コンポーネントの追加) -> Inheriting(インスタンス化)
- Prefab(プレハブ) -> Reusable Scene file(再利用可能なシーンファイル)
スクリプト: GDScript、C#、ビジュアルスクリプト¶
デザイン¶
Unity は C# をサポートしています。C# には Visual Studio と統合されているという利点があり、静的な型指定などの望ましい機能があります。
Godot は独自のスクリプト言語 GDScript と、 Visual Script および C# のサポートを提供します。GDScript は Python から構文を借用しましたが直接的な関連はありません。カスタム スクリプト言語について不明な点があれば、 GDScriptの基本 と よくある質問 ページをお読みください。GDScript は Godot API に強く結び付けられており、学習に時間はかかりません: 経験豊富なプログラマなら 1 晩から 1 週間で習得出来ます。
Unityでは、GameObjectにスクリプトをいくつでもアタッチできます。各スクリプトは、1個のビヘイビアーをGameObjectに追加します。たとえば、プレイヤーのコントロールに反応するためのスクリプトをアタッチし、そこに特定のゲームロジックを制御するスクリプトを追加できます。
Godotでは、ノードごとに1つのスクリプトのみをアタッチできます。外部GDScriptファイルを使用するか、スクリプトをノードに直接含めることができます。 1つのノードにさらにスクリプトをアタッチする必要がある場合、シーンと目的に応じて、2つの解決策を検討できます。
- ターゲットノードと現在の親ノードの間に新しいノードを追加し、この新しいノードにスクリプトを追加します。
- または、ターゲットノードを複数の子に分割し、それぞれに1つのスクリプトをアタッチできます。
ご覧のとおり、シーンツリーを混乱させるのは簡単です。複雑なシーンを複数の小さなブランチに分割することを検討してください。
接続:グループとシグナル¶
ノードを制御するには、スクリプトを使用してノードにアクセスし、ノードの組み込み関数またはユーザー定義関数を呼び出します。また、グループ内にノードを配置し、このグループ内のすべてのノードで関数を呼び出すこともできます。詳細については、 scripting documentation を参照してください。
ノードは、指定されたアクションが発生したときにシグナルを送信できます。シグナルは、任意の関数を呼び出すように設定できます。カスタムシグナルを定義して、トリガーされるタイミングを指定できます。詳細は、 signals documentation を参照してください。
スクリプトのシリアル化¶
Unityは、次の2つの方法でスクリプトのシリアル化を処理できます。
- 暗黙的:型がシリアル化可能な型である場合、クラス内のすべてのパブリックフィールドは自動的にシリアル化されます(
Dictionaryはシリアル化できません)。 - 明示的:非パブリックフィールドは
[SerializeField]属性を使用してシリアル化できます。
Godot にはスクリプトシリアル化システムも組み込まれていますが、明示的にしか動作しません。 export キーワードを使用して、シリアル化可能な型 (Array と Dictionary を含む built-in and various engine types)をシリアル化できます。詳細については、 exports documentation を参照してください。
Unityには、カスタムアセットオブジェクトのシリアル化に使用される ScriptableObject と呼ばれるデータ型もあります。Godotでの同等のものは、すべてのリソースの基本クラスです Resource。 Resource を継承するスクリプトを作成すると、カスタムのシリアライズ可能なオブジェクトを作成できます。リソースの詳細については、 こちら をご覧ください。