Gamemaker Studio2からGodot Engineにエンジン移行しました
あれだけ好きだったGamemaker Studio2ですが、今回思い切ってGodot Engineに乗り換えました。
いろんな理由があるのですが、純粋にエンジン比較をしながら、自分なりの乗り換えに関する理由も書いていこうと思います。
あ、ちなみにGMS2のチュートリアルは残しておきますし、気が向いたら更新もします。
ひとまずいろんなゲームエンジンとの比較
Unity | Unreal Engine | Gamemaker Studio2 | Godot Engine | |
---|---|---|---|---|
ライセンス料 | 無料~16,500円/月(条件あり) | 無料(リリース後のロイヤリティ支払い) | 99ドル~1,500ドル/年 | 無料 |
日本語対応 | ◎ | ◎ | × | 〇 |
2D開発 | 〇 | 〇 | ◎ | ◎ |
3D開発 | ◎ | ◎ | △ | ◎ |
開発言語 | C# | C++ | GML | GDScript/C#/C++ |
PC対応 | Windows / Mac / Linux / HTML5 | Windows / Mac / Linux / HTML5 | Windows / Mac / Linux / HTML5 | Windows / Mac / Linux / HTML5 |
スマホ対応 | Android / iOS | Android / iOS | Android / iOS | Android / iOS |
ゲーム機対応 | ◎ | ◎ | ◎ | △(サードパーティーによる協力が必要) |
所感
Unreal EngineやUnityの仕様経験が長く、ライセンス料を気にしないのであれば、Godot Engineへの移行を検討する必要はないと思います。
Gamemaker Studio2の機能で十分満足であれば、これもまた検討する必要はないでしょう。
私の所感としては、Godot EngineはUnityやUnreal Engineの3Dに特化したエンジンと、2D特化のGMS2の中間に位置するエンジンだなと感じました。
正直に言うと、GMS2よりも高機能です。
ただし、2Dとは言えベースが3Dであるが故に、3Dの知識・理解がある事で、その能力が一段と引き出されるとも感じました。
Godot Engineの最大のメリットはオープンソースであり、完全に無償で使用ができる事です。
更に他のオープンソースとソフトウェアとの相性が抜群にいいです。
オープンソースが故にデメリットとして、コンソール(Nintendo SwitchやPS4)の出力がしにくい事です。
各プラットフォーマーのSDKは非公開になっているため、インテグレーションするためにはプラットフォーマーとの契約が必要です。
それも、個人では恐らくできないため企業を介す事になるのですが、この部分の役割をエンジンの運営会社が担っているのです。
しかし、オープンソースのGodot Engineは運営会社はありませんので、もしもコンソール向けに出したいのであれば、Godot Engineのインテグレーションを専門とするサードパーティーの協力が必須になります。
なぜGodot Engineを選んだのか
ちなみに呼称は「ゴドーエンジン」だそうです。
しかし、今もまだ「ゴドットエンジン」と呼ばれる事もあるようですね。
さて、私がGodot Engineを選んだ理由ですが、いくつかあります。
ざっくりと言ってしまうとこの1年開発してきた内容が一瞬で解決してしまったというのが大きな理由です。
私のGMS2での開発プロセスと共に、Godot Engineを選んだ理由を解説していきます。
2Dプラットフォーマー基盤
2Dプラットフォーマーのフレームワークを最初に着手しました。
これに関してはGMS2は早いです。 数時間あれば基本的な動きは作る事ができます。
しかし、少し深い実装をするとかなり頭を悩ます事になります。
例えば「スロープ(傾斜)の対応」に関しては、いくつも方法があるのですが、ピクセル単位で衝突判定を行い、左右移動時に判定して上へ押し上げる(または下に押し下げる)処理を行います。
この実装ではなく、もっとスマートに、傾斜から法線を取得してその方向に押し戻す処理をする事も出来ます。
法線での実装のメリットは、回転する足場などにも対応できるので便利なのですが、実はやってることはGMS2の物理エンジン機能(Physics)を使用するのとあまり変わりません。
Physicsを使用するとどうなるかというと、GMS2の標準の処理機能と全く別の物になるため、Physics機能と混在させるとバグが出ます。
例えば衝突判定のためのコリジョンマスクは、Physicsと標準機能では全く別の物になりますし、組み込み変数(特に座標系)も別の物になります。
対してGodot Engineに関しては、そもそもが物理エンジンで動かすことになります。(もちろん使用しない事も可能です)
座標系などの変数には影響はありません。
つまり、上記で例に挙げた「スロープ(傾斜)の対応」は一瞬で解決し、法線を使用する方法なので「回転する足場」なども対応が可能なわけです。
これだけで、私が費やした半年分くらいが一瞬で解決しました。
シェーダー関連
Godot Engineのいいところは、コードを書きながらリアルタイムにシェーダーがプレビューできる点です。
これは圧倒的にスピードが上がりました。
そしてGMS2でのBloomシェーダーはなかなか苦戦しました。
GMS2のシェーダーで対応する場合、surfaceを何度も使いまわして、輝度抽出とブラーを重ねて加算合成やスクリーン合成をして実装します。
Godot Engineの場合、Environmentノードのいくつかのプロパティのチェックボックスをオンにすれば実装完了です。
正直絶望しました。
2ヶ月ほど悩みぬいた処理を、わずか10秒でマウスを数回クリックするだけで終わるのです。
とは言えGMS2でやったからこそ、根本の知識が身についているというのは非常に心強いとも感じました。
GUIについて
GMS2でGUIを実装する場合、何らかの方法でコンポーネントをレイアウトをします。
多くの場合は、プログラムに直接座標を書いて、コンポーネントをレイアウトしていました。
UnityやUnreal Engineにはついている、レイアウト用の機能がGodot Engineにも存在します。
私はまだGUIにそれほど着手していなかったので、大きな影響はありませんでしたが、レイアウトをJSONで読み取る方法などは思考していました。
絵作りについて
私が開発しているゲームは、キャラモーション数も絵そのものも多く、どうやって対応するかすごく悩んでいました。
ドット絵で描いていくにはあまりにも量が多いため、Spineを使用して行う方法を検討したり、3Dプリレンダによる素材制作も検討しました。
更に背景に関しても、プロシージャル的に作る事ができないか模索していたのですが、2Dでは限界を感じていました。
もっと言うと、2Dカメラでは見せたいシーンによってパースを変えることは不可能なので、絵でどう表現するか、ずっと悩んでいました。
結論として「3Dで作った方がいいのでは…?」という所に行きついたのですが、最初にエンジン比較をしたように、GMS2は3D向きではありません。
たどり着いたGodot Engine
一番時間の掛かるリソース制作。
これを解決すべく、3Dで実装する手段に落ち着いた結果、Godot Engineを試してみる事にしました。
もしもGodot Engineが使いにくかったら、GMS2でどうにかできないか模索する、または使い慣れたUnreal Engineで作り直す という所まで考えていました。
私の予想は裏切られました。
Godot Engineは、想像を超えてはるかに使いやすいエンジンでした。
最初のエンジン比較で書いたように、デメリットはあります。
しかし、そのデメリットを超えて、私はエンジン移行に踏み切ったのでした。
今後の記事について
冒頭に述べたように、GMS2の記事やチュートリアルは残しておきますし、今後気が向いたら書きます。
しかし、基本的にはGodot Engineの記事になります。
GMS2と違って、本気のエンジン初心者なので備忘録と、自分のプロジェクトの進捗がほとんどだと思いますが、今後ともどうぞよろしくお願いします。