こんにちは、 Ebitengine 作者です。他の優れたゲームエンジンがあるにも関わらず、なぜ、ゲームエンジンをわざわざ自分が作っているのかについては、いくつか理由があります。

自分の美的感覚の追求だから

Ebitengine の基本コンセプトは「全ては矩形画像である」です。 Ebitengine の API は「矩形画像から矩形画像へコピーする」というアイデアから基本的に成り立っています。自分はこの「全ては○○である」というアイデアが好きです。他には例えば「全てはファイルである (UNIX)」「全てはリソースである (HTTP)」などがありますね。

この小さい概念で実用的なゲームを作れるか、の概念実証として Ebitengine を作っています。実際 Ebitengine で作られたゲームはいくつかあります。最近ですと例えば「メグとばけもの」がそこそこヒットし、それなりに遊ばれております。 2D に限って言えば、概念実証は成功したと言えましょう。

この美的感覚の追求について、より詳しくは自分が以前書いた記事「ゲームエンジンはアートである - 8 年以上自作ゲームエンジンをメンテし続けている話」をご参照ください。

自分が作ったわけではない問題を解きたくないから

自分は、自分のコントロール外で発生した問題を解くのを苦痛に感じます。これは問題の難易度はあまり関係ありません。高難易度でも自分のコントロール内で発生した問題はそこまで苦痛に感じません。逆に、問題が簡単だったとしても、自分のコントロール外で発生した問題を解くのは苦痛です。

たとえば他者のゲームエンジンを使ってゲームを作ったとします。「ゲームエンジンをアップデートしたらゲームが動かなくなってしまった」ということはしょっちゅう起こりえます。こういうのがまさに「自分のコントロール外で発生した問題」であり、「自分が作ったわけでもない問題」です。

ゲームエンジンを作っている以上、依存ライブラリがゼロというわけにはもちろん行きません。ですが、低レイヤーの OS API や OpenGL などは安定しているため、自分の預かり知らぬところでの問題は発生しにくいです。もちろん「特定のマシンでしか再現しない謎の現象」などの問題は発生することはあり、問題として難易度が高いことがよくあります。ですが、これは自分にとっては「他者のゲームエンジンで発生したよくわからない問題」よりは遥かに精神面でマシです。これも厳密に言えば自分のコントロール外の出来事なので不思議なものです。現実的に依存不可避な低レイヤーで発生する問題は、そういうものだと受け入れられるようです。また、他者のゲームエンジンというコントロールの効きにくいレイヤーがない分、そういった問題に対する試行錯誤やワークアラウンド作成がむしろやりやすいというのはあります。

既存のゲームエンジンはオーバーキルだから

自分は 2D ゲームが好きです。 Unity や Unreal Engine でも 2D ゲームを作ることは可能ですが、自分にとっては機能が過剰です。

これは先程の項目と若干被るところがあります。機能が過剰だと、その機能の存在によって問題が発生しえます。それを解決しなければならないのは自分にとっては苦痛です。

ただ一般的に IDE は非常に便利であり、ある程度の規模のゲームを作るならば必須です。これは IDE を持たない Ebitengine にとっての課題であります。

Go のツールチェーンが便利だから

Go の言語仕様は賛否両論ありますが、自分にとっては 100 点中 80-90 点くらいです。ところが Go のツールチェーンは極めてよくできており、これが自分にとって 120 点くらいです。自分が気に入っている点は、基本的にスタンドアローンなバイナリを吐くこと、非常に高速にコンパイルすること、環境変数を指定するだけで簡単にクロスコンパイル出来ること、依存ライブラリのバージョンが決定的に定まること、などです。

実際 Go でゲームエンジンを作ったところ、様々なプラットフォームへの展開が非常に容易であることが分かりました。ブラウザ向けコンパイルもワンコマンドで済みます。他のゲームエンジンでここまでクロスプラットフォーム向け出力が簡単なのは、自分が知る限り存在しません。 Nintendo Switch へのコンパイルは公式サポートされていないので自分でなんとかする必要がありましたが、幸いなんとかなってよかったです。

以上、この回答がご参考になれば幸いです。