BioErrorLog Tech Blog

試行錯誤の記録

GodotからEbitengineに乗り換えた理由を整理する | Devlog #4

ゲーム開発記録その4。

GodotからEbitengineに乗り換えていたので、その理由と所感を整理します。

前回はこちら:

www.bioerrorlog.work

はじめに

ここしばらく、Ebitengineを触っていました。

Ebitengineは、Go製のシンプルな2Dゲームエンジンです。

過去のDevlogの通り、私はもともとGodot Engineを好んで使っていたのですが (一応UnityやUnreal Engine, pygameなども触っていたことはある)、今はEbitengineをメインに使っていこうかな、という気持ちになっています。

Ebitengineのどこが好きになれたのか、個人的な所感を残します。

GodotからEbitengineに乗り換えた理由

ツールに詳しくなる vs 自分で実装する

Godotでは、基本的にはあらかじめ用意された要素(Node等)をベースにゲームを実装していきます。

一方、Ebitengineには最小限のシンプルなAPIしかありません。 実現したいことは、基本自分でコードを書いて実装することになります。

どちらの思想が合うかは、作りたいものの特性や利用者のバックグラウンドによるでしょう。 私の場合は、Ebitengineを使った開発体験の方が好きでした。

Godotでの開発体験では、しばしばこのようなことが起こります:

  1. こんな実装をしたい
  2. それを実装するのに使える機能/Nodeはどんなのがあるのか調べる
  3. それを使って機能を実装する
  4. -> 上手く実装できない
  5. 機能/Nodeの仕様を詳しく調べる
  6. やりたかったことが微妙にサポートされていないことに気が付く
  7. -> 2.に戻る or 回避策を考える

巡り合わせが悪いと、「どう実装すれば良いか」よりも「この既存機能はどのような仕様なのか」を調べていじくりまわす時間と労力の方が長くなってしまうのです。 これが個人的にはストレスでした。 自分は何と戦ってるんだろう..?という気持ちになってくるんですね。

私はゲーム開発を本業とする界隈人ではないので、ゲームエンジンに備わる既存機能やプラクティスに対する知識も大してありません。 作りたいゲームは、決して複雑ではない2Dゲームです。 既存機能を調べながら悩むよりも、自分で考えた方が早いことも少なくないことに気づきました。

自前で実装してると失敗も多くしますし、Godotだったら一瞬でできたのに、みたいなこともあります。 しかし、ゲームを「コントロールできてる感」は格別です。

エンジンをフル活用できる程の既存知識もなく、複雑な機能を必要としてなかった私にとっては、シンプルな仕組みさえあれば良かったのだな、と感じました。 さながら、「顧客が本当に必要だったもの」の風刺画を思い出します。

「顧客が本当に必要だったもの」 | 画像はこちらから引用

AIの恩恵を受けやすい

ChatGPTをはじめとするLLMの登場により、私の普段の開発体験は大きく変わりました。 ChatGPTとのペアプロによってコードを書いています。

そうなった時に、これらAIとの相性 - AIペアプロがやりやすいか、AIの恩恵を受けやすいか、というのも一つの観点として重要です。

その意味で、EbitengineはAIとの相性が良いです。

EbitengineにはGUIがなく、コードとコマンドで開発が完結します。 独自言語/独自仕様に依る部分も少なく、世間的にも広い領域で使われているGo言語で書けます。 プロジェクトの全体像をAIに教えるのにはパッケージのツリー構成や単にtree結果を渡せば済みますし、実装も完全にコードの世界で完結するので、テキストでのやり取りを基本とするAIペアプロに向いています。 もちろん彼らはGo言語にも詳しいです。

これがGodotだと少し事情が変わってきます。 GUI要素が多くあるので、例えば「XXタブを開いたところにあるこの設定値を変更してください」みたいなやり取りが発生することがあるのですが、これがなかなか難しい。 GUIエディタ内を探し回った挙句、いやどこにも見つからないんだけど...みたいなことがよく起きるんですね。

GodotのGUIエディタの様子

また、GodotではGDScriptという独自言語を使いますが、彼らAIはこれにそこまで詳しくありません。 純粋に学習量が一般的な汎用言語に比較して少ないということもあるかも知れませんが、シンプルに最近の言語仕様の変更に追随できていないことの影響が大きいです。 最近の言語仕様の変更に追随できてない、というのは(AIの学習タイミングの関係上)もちろんGoにも同じことが言えるのですが、バージョンで言語仕様が結構変わるGDScriptは、比較してそのつらみをよく感じます。

ということで、Godotと比べてEbitengineがAIペアプロとの相性が良い、というのは嬉しかったポイントです。

小さい歩幅で前進する

個人開発における最悪の状況というのは、質の悪いものを作ってしまうことでも開発に時間がかかることでもなく、「開発をやめてしまうこと」や「飽きてしまうこと」だと思っています。

そのような状況を回避するためには、小さい歩幅でも開発し続けることが効果的です。

有名どころのゲームエンジンを使って開発を始めたはいいものの、よく分からなくて詰まってしまった、とか、イライラして開発を投げてしまった、という方は、シンプルな思想のEbitengineを使ってみてはいかがでしょうか。

上に挙げたような理由から、私には「リズムよく開発を続ける」ことにEbitengineが効果的でした。

おわりに

GodotからEbitengineに乗り換えた理由を現時点の所感から整理しました。

最近のUnityの動向に伴ってUnity代替としてのGodot Engineの注目度が高まる中で逆行ではあるかもしれませんが、現時点の考えとして書き残しておきます。

以上、どなたかの参考になれば幸いです。

[関連記事]

www.bioerrorlog.work

www.bioerrorlog.work

www.bioerrorlog.work