HOUSE DUCK · AUTOMATIC TRANSLATION
Making games with vibe coding, the reason I chose Godot instead of Unity | Quirky Ball
To start with the conclusion,
I did not choose Godot because it is unconditionally a better engine than Unity.
On the MacBook I own,
to make a game with AI by myself and continuously modify it,
Godot was the most realistic choice.
I am not a developer.
I majored in industrial design,
and worked as a game QA for about 3 years.
Now, in Germany,
I am making a mobile puzzle game called Quirky Ball.
I have also tried Unity and Unreal. But they felt heavy.
When I decided to make a game,
it was not that I did not know about Unity or Unreal.
I have touched both in the past.
There is plenty of information,
countless completed games exist,
and I do not need to prove that they are good engines.
The problem was my situation.
The equipment I have is an M2 MacBook Air.
It is neither a high-performance desktop,
nor was I making a large 3D game as a team.
I needed to request modifications from AI,
run it right away in the engine,
and repeat the process of fixing things if anything looked off, continuously throughout the day.
However, Unity and Unreal
felt quite heavy during this short iteration loop that I wanted.
If simply turning on the engine feels burdensome,
it starts to feel like you are serving the engine
rather than making a game.
Godot fit well with my MacBook and workflow.
The first thought I had when I opened Godot for the first time was
that there was surprisingly not much to it.
This sounds like a disadvantage,
but to me, it was actually an advantage.
Opening the project,
modifying,
running,
and checking the results was a fast workflow.
Quirky Ball is not a massive 3D open-world game.
It is a vertical-screen mobile puzzle game
where marbles are dropped and colliding movements and UI are continuously refined,
making it a 2D mobile puzzle game.
Therefore, rather than massive features I would never use,
checking the screen I just modified quickly was much more important.
Godot official documentation also explicitly states Apple Silicon on macOS as a supported target.
In reality, there was no major inconvenience in working between the editor and the game on the M2 MacBook Air.
Reference: https://docs.godotengine.org/en/4.7/about/system_requirements.html
System requirements
This page contains system requirements for the editor and exported projects. These specifications are given for informative purposes only, but they can be referred to if you're looking to buil...
docs.godotengine.org
Why vibe coding and Godot fit well together
The vibe coding I am talking about
is not a method of telling AI "Make me a game" and ending it there.
When Codex writes code,
I run the game myself.
I check if the buttons are awkward,
if the marble movement is unfun,
if the text is cut off,
and if a first-time player can understand the rules.
Then I have it modified specifically again.
If the AI took over a lot of the developer role,
I played the role of planner, designer,
and QA.
What was important in this process
was not receiving perfect code all at once.
It was the speed of making small modifications,
running quickly,
and checking with my eyes.
Godot made that repetition less exhausting.
The fact that it is free is also hard for a 1 developer to ignore.
Godot is a free, open-source engine under the MIT license.
It can be used commercially,
and the content and rights of the game I create remain with me.
Reference: https://godotengine.org/license/
License – Godot Engine
Godot Engine is free and open source software released under the permissive MIT license.
godotengine.org
Of course, being free does not mean it is unconditionally good.
However, for a developer who is still without revenue, being an 1 developer
not having to worry about engine costs or policy changes first
was definitely a reassuring aspect.
That money and attention
could be spent on fixing the game even just one more time.
That does not mean Godot was convenient in every aspect.
If I write only up to here,
I might look like some kind of Godot evangelist.
However, when actually trying to release a mobile game,
there were definitely inconvenient parts as well.
Ads,
in-app purchases,
login,
and native features of Android and iOS
were a completely different issue from making a single game screen.
Matching plugin versions,
checking separately on each platform,
and finding issues that are fine inside the engine but different on actual devices was repeated.
Compared to engines with vastly more users like Unity,
there were moments when it was difficult to find immediately matching materials when stuck.
Just because AI writes code instead
did not mean these kinds of problems disappeared like magic.
Rather, as code I do not understand increased rapidly,
QA of running and checking directly became even more important.
Still, if I were to make Quirky Ball again, would I choose Godot?
For this game, I think I would choose it again.
To be precise,
with a single M2 MacBook Air,
under the condition of quickly making and fixing an 2D mobile game together with AI, yes.
Conversely, for a large-scale 3D game,
or a project that requires attaching numerous specific commercial SDKs,
I too would compare other engines first.
Choosing an engine is not a religion.
It is closer to the issue of choosing an engine that I can finish building to the end,
rather than choosing a famous engine.
That answer was Godot for me.
And right now,
rather than the fact that I chose the engine,
actually releasing Quirky Ball is much more important.
Frequently Asked Questions
- Can you make games with Godot without knowing coding?
The entry barrier has lowered a lot with the help of AI.
However, this does not mean you never have to look at code.
The ability to explain what is wrong,
and run it directly to judge the results, is still necessary.
- Is Godot best for vibe coding?
It varies by project.
I chose Godot because of light 2D mobile games and fast iteration work.
If the asset ecosystem or a specific SDK is more important, Unity might be more convenient.
- Is Godot game development possible with an M2 MacBook Air?
An 2D mobile game like Quirky Ball was fully workable.
However, this is experience based on my project.
With heavy 3D graphics and a larger build scale, the results could differ.
In the next post,
I plan to write about why I, an industrial design major, did not make any game assets myself at all,
and yet through what method I completed the design of Quirky Ball.