HOUSE DUCK · AUTOMATIC TRANSLATION
バイブコーディングでゲーム制作、私がユニティの代わりにGodotを選んだ理由 | Quirky Ball
結論から言うと、
Godotがユニティより無条件に優れたエンジンだから選んだわけではない。
私が持っているマックブックで、
一人でAIとゲームを作り、修正し続けるには
Godotが最も現実的だったからだ。
私は開発者ではない。
インダストリアルデザインを専攻し、
ゲームQAとして3年ほど働いた。
そして現在はドイツで
Quirky Ballというモバイルパズルゲームを作っている。
ユニティやアンリアルも使ってみた。しかし、重かった。
ゲームを作ろうと決心した時、
ユニティやアンリアルを知らなかったわけではない。
どちらも以前触ったことがある。
情報も多く、
完成したゲームも数え切れないほどあり、
優れたエンジンであるという事実をわざわざ私が証明する必要もない。
問題は私の状況だった。
私が持っているデバイスはM2のマックブックエアーだ。
高性能デスクトップでもなく、
チーム単位で大規模な3Dゲームを作るわけでもなかった。
AIに修正を依頼し、
エンジンで即座に実行し、
おかしければ再び修正する作業を、一日に何度も何度も繰り返さなければならなかった。
しかし、ユニティやアンリアルは
私が求めているこの短い繰り返しにおいて、かなり重く感じられた。
エンジンを起動すること自体が負担に感じられたら、
ゲームを作っているのではなく、
エンジンに仕えているような気分になり始める。
Godotは私のマックブックと作業スタイルによく合っていた。
Godotを最初に開いたときに一番最初に思ったのは、
意外と何もないということだった。
これは欠点のように聞こえるが、
私にとってはむしろ利点だった。
プロジェクトを開き、
修正し、
実行し、
結果を確認する流れが速かった。
Quirky Ballは巨大な3Dオープンワールドゲームではない。
縦画面でボールを落とし、
ぶつかる動きやUIをひたすらブラッシュアップする
2Dモバイルパズルゲームだ。
だから、私が使わないような巨大な機能よりも、
今直した画面を素早く確認する方がはるかに重要だった。
Godotの公式ドキュメントでもマックOSのアップルシリコンをサポート対象として明記している。
実際にM2のマックブックエアーでエディタとゲームを行き来しながら作業するのに大きな不便はなかった。
参考: https://docs.godotengine.org/en/4.7/about/system_requirements.html
システム要件
このページには、エディターおよびエクスポートされたプロジェクトのシステム要件が含まれています。これらの仕様は情報提供のみを目的としていますが、構築を検討している場合に参照できます...
docs.godotengine.org
バイブコーディングとGodotがうまく噛み合った理由
私が言うバイブコーディングとは、
AIに「ゲームを一つ作って」と言って終わりにする方式ではない。
コードックスがコードを書くと、
私は自分でゲームを実行してみる。
ボタンがおかしくないか、
ボールの動きが面白くないか、
文字が切れていないか、
初めてプレイする人がルールを理解できるかを確認する。
そして再び具体的に修正させる。
開発者の役割をAIが多く引き受けたとするなら、
私は企画者とデザイナー、
そしてQAの役割を果たしたことになる。
このプロセスにおいて重要なのは、
一度に完璧なコードを受け取ることではなかった。
小さく修正し、
素早く実行し、
目で確認する速度だった。
Godotはその繰り返しをあまり疲れないものにしてくれた。
無料であるという点も、1人の開発者にとっては無視し難い。
GodotはMITライセンスの無料オープンソースエンジンだ。
商用利用が可能であり、
私が作ったゲームのコンテンツと権利は私の方に残る。
参考: https://godotengine.org/license/
ライセンス – Godotエンジン
Godot Engineは、寛大なMITライセンスのもとで公開されている無料のオープンソースソフトウェアです。
godotengine.org
もちろん、無料だからといって無条件に良いというわけではない。
しかし、まだ収益のない1人の開発者にとって、
エンジンの費用や方針の変更を先回りして心配しなくてもよいというのは、
確実に気持ちが楽になる部分だった。
そのお金と労力を、
ゲームを一度でも多く修正することに使えるからだ。
だからといって、Godotがすべての面で気楽だったわけではない。
ここまで書くと、
まるでGodotの伝道師のように見えるかもしれない。
しかし、モバイルゲームを実際にリリースしようとすると、
不便な部分も確かにあった。
広告、
アプリ内課金、
ログイン、
AndroidとiOSのネイティブ機能は、
ゲーム画面を一つ作るのとは全く異なる問題だった。
プラグインのバージョンを合わせ、
各プラットフォームで個別に確認し、
エンジン内では問題ないのに実際の実機では異なる不具合を探す作業が繰り返された。
Unityのようにユーザーがはるかに多いエンジンと比べると、
詰まったときにすぐ合致する資料を見つけにくい瞬間もあった。
AIがコードを代わりに書いてくれるからといって、
こうした問題まで魔法のように消え去るわけではなかった。
むしろ自分の知らないコードが急速に増えていく分、
実際に実行して確かめるQAがより重要になった。
それでも再びQuirky Ballを作るならGodotを選ぶだろうか？
このゲームであれば、また選ぶと思う。
正確には、
M2 MacBook Air一台で、
AIと共に2Dのモバイルゲームを素早く作り、修正する条件であればそうだ。
逆に、大規模な3Dゲームや、
特定の商用SDKを山ほど組み込まなければならないプロジェクトであれば、
私も別のエンジンを真っ先に比較検討するだろう。
エンジンの選択は宗教ではない。
有名なエンジンを選ぶ問題ではなく、
自分が最後まで作り上げられるエンジンを選ぶ問題に近い。
自分にとってその答えがGodotだった。
そして今は、
エンジンを選んだという事実よりも、
Quirky Ballを実際にリリースすることの方がはるかに重要だ。
よくある質問
- コーディングを知らなくてもGodotでゲームを作れますか？
AIの助けにより、開始のハードルは大きく下がった。
ただし、コードを一切見なくてもよいという意味ではない。
何が間違っているかを説明し、
自分で実行して結果を判断する能力は依然として必要である。
- バイブコーディングにはGodotが一番良いですか？
プロジェクトによって異なる。
私は軽量な2Dモバイルゲームと素早い反復作業のためにGodotを選んだ。
アセット生態系や特定のSDKがより重要であれば、Unityの方が楽な場合もある。
- M2 MacBook AirでGodotのゲーム開発は可能ですか？
Quirky Ballのような2Dモバイルゲームなら十分に作業できた。
ただ、これは私のプロジェクト基準での経験だ。
重い3Dグラフィックやビルド規模が大きくなると、結果は変わる可能性がある。
次の記事では、
インダストリアルデザイン専攻の私がなぜゲームアセットを一つも自分で作らなかったのか、
それにもかかわらずどのような方法でQuirky Ballのデザインを完成させていったのかについて書こうと思う。