Why I Switched from Godot to Ebitengine

I've been switching from Godot to Ebitengine, so I'll organize my reasons and impressions here.

Introduction
Why I Switched from Godot to Ebitengine
Conclusion

Introduction

I've been working with Ebitengine for a while now.

Ebitengine is a simple 2D game engine written in Go.

I originally preferred using Godot Engine (though I've also dabbled with Unity, Unreal Engine, and pygame), but now I'm leaning toward using Ebitengine as my main tool.

Here are my personal thoughts on what I've come to appreciate about Ebitengine.

Note: This article was translated from my original post.

Why I Switched from Godot to Ebitengine

Learning Tools vs. Building from Scratch

In Godot, you typically build games using pre-made elements like Nodes as your foundation.

In contrast, Ebitengine provides only a minimal, simple API. Whatever you want to achieve, you basically write code from scratch to implement it.

Which philosophy suits you better depends on what you're building and your background. For me, I preferred the development experience with Ebitengine.

Here's what often happens when developing with Godot:

I want to implement something
Research what features/Nodes are available for that
Try implementing the feature using them
→ It doesn't work well
Investigate the feature/Node specifications in detail
Realize what I wanted to do isn't quite supported
→ Return to step 2 or think of a workaround

When things go badly, you end up spending more time and effort investigating "what are the specifications of this existing feature" rather than "how should I implement this." It was stressful for me. You start thinking, "What am I even fighting against here?"

I'm not part of the professional game development community, so I don't have much knowledge about existing features and best practices built into game engines. The games I want to make are simple 2D games, nothing complex. I realized that it's often faster to figure things out myself than to struggle while researching existing features.

When implementing things yourself, you make plenty of mistakes, and there are times when something that would have been instant in Godot takes longer. However, the sense that you're "in control" of the game is exceptional.

For someone like me who didn't have enough existing knowledge to fully utilize an engine and didn't need complex features, I realized that a simple mechanism was all I really needed. It reminds me of the satirical "tree swing cartoon".

Tree swing cartoon | Reference: How IT-Projects really work

Better for Leveraging AI Coding

With the emergence of LLMs, my everyday development experience has changed dramatically. I write code through pair programming with AI.

When that's the case, compatibility with AI—whether AI pair programming is easy and whether you can benefit from AI—becomes an important consideration.

In that sense, Ebitengine has good compatibility with AI.

Ebitengine has no GUI, and development is completed entirely with code and commands. There's minimal reliance on custom languages or specifications, and you can write in Go, which is widely used in the world. To explain the project overview to AI, you just need to provide the package tree structure or simply the tree output, and since implementation is entirely in the code world, it's well-suited for AI pair programming, which is fundamentally text-based. Of course, they're also well-versed in Go.

The situation changes somewhat with Godot. Because there are many GUI elements, you sometimes have exchanges like "please change this setting value in the XX tab," which can be quite difficult. You often end up searching around the GUI editor only to find yourself thinking, "I can't find it anywhere..."

Also, while Godot uses a custom language called GDScript, AI assistants aren't that familiar with it. This might partly be because there's simply less training data compared to general-purpose languages, but the bigger impact is that they can't keep up with recent language specification changes. Not keeping up with recent language specification changes applies to Go as well (due to AI training timing), but GDScript, where language specs change quite a bit between versions, makes you feel this pain more acutely.

So the fact that Ebitengine has better compatibility with AI pair programming compared to Godot was a welcome advantage.

Moving Forward in Small Steps

I think the worst situation in indie development isn't creating something low-quality or taking a long time to develop—it's "giving up on development" or "losing interest."

To avoid such situations, continuing development in small steps is effective.

For those who started developing with a popular game engine but got stuck because they didn't understand it, or threw in the towel out of frustration, why not try Ebitengine with its simple philosophy?

For the reasons mentioned above, Ebitengine has been effective for me in a good development rhythm.