見出し画像

Godotエンジンのいいところ

NwSnKn

Godot Game Engineというゲームエンジンがあります。いいところを列挙します。みんなGodot使ってゲーム作ろうー


シンプル

Godotのいいところは、『シンプル』。これに尽きます。
特にこういう人に向いてます。

  • 一人で作っていて、アートもプログラムも自分でやる。
    チームを仲立ちする機能を必要としない人。

  • メインストリームから外れたジャンルのゲームを作っている。
    応用度の高い定番機能を使わない人。

  • 既存の大規模ゲームエンジンに疲れを感じている。

  • プロジェクトフォルダは、容量小さい方がいい。
    ゲーム本体も小さい方がいい。

エディタがシンプル

Godotはエディタからシンプルです。C#対応版と非対応版があるのですが、非対応版は100MBちょっとのexeが1個あるだけです。厳密にはコンソール起動用のexeがもう1個あります。何にせよインストール不要で、すぐ動きます。環境設定はユーザーフォルダに一括で入ってます。
ユーザー登録等も不要です。

機能がシンプル

Godotはあまり高レベルな機能を提供しません。いわゆるナビゲーション（経路探索）システムとか、ノードグラフを使ったアニメーションの遷移定義とか、それくらいは在るには在るのですが、それらを使用することを前提にした作りになってません。
前提にしていないというところが重要で、ローレベルから自分の実装を積み上げてもストレスがありません。

今後もシンプル

そしてGodotは今後も機能が肥大化しないと思います。Godotの歴史を少し辿って見てみると、互換性を維持することよりも、メンテナンス性を保つことを重視しているように思います。過去にレガシーをばっさり切って、現在のバージョンに至っているのです。例えば、前代のメジャーバージョン、Godot 3では、ビジュアルスクリプティングに対応していました。これは、Godot 4に移行するにあたって、削除する決断が成されています。

このエピソードから、Godot開発者たちの、Godotのシンプルさを維持し続けようとする堅い意志がうかがえます。

↑この記事『よくある質問』の、下記質問の回答も、プロジェクトを肥大化させないポリシーに基づいているように思います。

  • GDScriptを作った動機はどのようなものですか？

  • GodotがDirect3Dの代わりにVulkanやOpenGLを使うのはなぜですか？

  • なぜGodotはそのコア機能セットを小さいままにすることを目指しているのですか？

Blenderと相性がいい

個人的にイチオシなポイントです。

blendインポート可能

GodotはBlenderの.blendファイルを直接インポートできます。Unityと同様に、PCにインストールされているBlenderのexeを呼ぶことで実現しています。なので間に余計な汎用ファイルを経由する必要がありません。FBXに書き出さなくていいんです。
自分の作ったアニメーションに対して、エンジンへのインポート時に、キーフレームが足されたり消されたりするのを好まない人は居るはずです。意図を込めて打ったキーフレームは取り除いてほしくない。逆に補間のためにキーフレームがどばっと追加されるのは、心情的にもRAMやストレージの容量的にも歓迎できない。Godotにおけるインポートは、その点の心配があまりありません。FBXを介さないのでアニメーションが「ベイク」されることはありませんし、割と素直に読み込んでくれます。持ち込まれたキーフレームの状態はエディタ上で確認できます。

glTFインポート可能

また、GodotはOpenGLの流れをくむ、Vulkanを採用したグラフィックス設計なので、glTFにも対応しています。対応どころか、インポートしたモデルデータの保持方法がglTFなので、むしろglTFネイティブなエンジンです。Blenderの標準のglTFエクスポート機能は、特に変なクセも無かったように思います。

スケールが同じ

GodotはBlenderと同じで、長さ1.0を1メートルと想定しています。デフォルト設定で使って、大きさに変換がかかったりはしません。

素直なレンダラー

Vulkan採用

GodotはグラフィックスAPIにVulkan（とOpenGL）を採用しています。Windows向けビルドでもVulkanです。PCとスマホで動かすにはこれで十分です。軸足を一本化することでエンジンのメンテナンス性を保っています。

今こそForwardレンダリング

GodotはDefferedレンダリングではなく、Forwardレンダリングを採用しています。ただし、従来のForwardにおける多光源対応の弱点を克服した、Clustered Forward Renderingです。光源がめちゃ多くても軽い。半透明含め全部Forwardで描かれるのは、あまり中身を気にしなくていい安心感があります。
自作のシェーダーを複数組み合わせてアート系の絵作りをするなら、フォワード1本化の方が恩恵あるはずです。シンプル。

コードが楽

GDScriptが楽

GodotではGDScriptと呼ばれる専用の言語のスクリプトが使えます。エディタ内にスクリプトエディタが付属していて、そこで記述します。Python似だと思います。GDScriptは動的型付け言語ですが、型ヒントを使って静的にも書けます。オートコンプリートやサジェストが機能しますし、違反したらちゃんとワーニングを出してくれます。組み込みのクラスや関数も型ヒントを使って実装されているので、自分だけでコード書く限りは型間違いのバグで悩まされるはずは無いはずです。
GDScriptの役割や振る舞いについては、Unityのスクリプトの立場に似ているので、Unity使いの人はすぐ理解できるはずです。

あなたがGodotで別の言語(上記のサポートされるオプションのリストを参照してください) を使用したいということは理解します。とはいえ、GDScriptをまだ試していない人は、3日間だけ試してみてください。Godotと同じように、GDScriptがいかに強力であり、開発がいかに迅速になるかを見れば、気に入ってもらえるはずです。

https://docs.godotengine.org/ja/stable/about/faq.html#doc-faq-what-is-gdscript
Godot公式ドキュメントより

GDScriptはC#ほどキッチリ書ける言語ではないのですが、第三者のランタイム（.netやmono）やIDEを間に挟まない気楽さが、メリットとしてデメリットを上回っていたので、筆者は今のところGDScriptだけ使っています。

C#も使える

とはいえ、GodotはC#も使えます。この場合外部のIDEを使って記述するようです。

ネイティブコードも呼べる

ネイティブコードも呼べます。自作DLL呼べます。Steam対応とか楽なはずです。

我流に優しい

ゲームエンジンは、機能の提供だけでなく、ワークフローの提供という役割もあると思います。そしてワークフローの提供にどれだけ重きを置いているかは、エンジンによって結構違うように感じます。
ワークフローに重きを置いている場合、ゲームのジャンルや作り方をエンジン側がある程度想定していて、それに追従すると楽にゲームが作れるようにできています。なにより、誰がやっても似た作り方になるというのは、大規模ゲーム制作では重要なことなんだと思います。
一方でワークフローをあまり意識しないエンジンの場合、真っ白いキャンバスを渡されるようなもので、自由に作れます。我流の作り方をしたり、メインストリームから外れるジャンルのゲームを作っても、「回避」の必要が無く、あまり苦しまないで済みます。
Godotはどっちかというと後者です。比較的には。ソロ制作者は、後者の方が作りやすいのではないでしょうか。

とっつきやすい

GodotはUnityに似てます。Unity使いの人ならGodotはすんなり理解できるはずです。Unreal Engine的な側面もあります。なのでUEも触ったことあると、理解はもっと早いと思います。
例えばGodotのNodeは、Unityで言うなら「GameObject+コンポーネント」のことです。UEならばActorに相当します。

OSSならではのメリット

Godot Game Engineはオープンソースプロジェクトです。

無料

もちろん無料で使えます。ライセンス表記は必要ですが、特に縛りはありません。

ソースコードが見れる

GitHubでソースコードが公開されています。なので、エンジンの機能で「仕様がちょっとわからん」というときに、ソースコードである程度確認することができます。全容を把握できる行数ではないのですが、不明点をピンポイントで追っていけば疑問点が解けることがあります。

独立性が高い

商用のエンジンと違って、企業の利潤を追求していません。今後の仕様変更や新規機能が、オトナの都合に左右されにくいはずです。

改造できる

腕力のある人ならPCやスマホ以外にも、何にでも移植できます。コンソール移植の実績はあるっぽいです。

この記事が気に入ったらサポートをしてみませんか？