GodotでC#を採用してみた所感
前回の記事でも言及した新アプリ『うさぎとぷーぷベビー』は、ゲームエンジンにGodot Engineを、プログラミング言語にC#を採用した。今回の制作を通していろいろと知見が得られたのでまとめておく。
GDScript
まず、Godotのデフォルト言語はGDScriptという、Pythonに似た構文の独自言語である。前作の『うさぎとぷーぷ』ではこれを採用している。
今作はスピンオフなので、前作と共用できるロジックも多く、普通に考えれば言語を統一したほうが楽である。それなのになぜ、わざわざ言語を変えてみようと思ったのか？
GDScriptは型が頼りない
GDScriptは、最近のプログラミング言語にしては型の表現力が弱いと感じていた。例えば以下のコード例のように、厳密な型を書けない場面があり、型情報が失われてしまう。
# これはできない
var dict: Dictionary[String, Array[String]]
# これならOKだけど…
var dict: Dictionary[String, Array]もうひとつ、例えば型なしの Array を型あり Array[String] の変数に代入するのは、実行前には何のエラーも警告も出てこないが、実行時に落ちる。
# 型なしArray
var ary: Array = ["foo", "bar"]
# 型ありArrayへの代入
# アプリの起動はできるが、ここへ到達した瞬間に落ちる
var ary_str: Array[String] = aryコードを手で書くことが少なくなってきたいまこそ、なるべく手前の工程でエラーを防げる仕組みが重要になってくるのだが…。このあたりの弱さは、GDScriptが動的型づけ言語であって、型づけの機能があとから拡充されたことによるものだろう。
GDScriptは潰しが効かない
GDScriptは、独自言語であるがゆえに潰しが効かない。将来性は不安だし、ここで身につけたノウハウは他のどこでも活かせない。 マイナー言語ゆえコーディングエージェントの理解も浅く、文法ミスレベルの間違いをたびたび起こしていた。
もうひとつの選択肢：C#
Godotでゲームを作る際、もうひとつの言語の選択肢としてC#が用意されている。
C#は天下のMicrosoft製で、20年以上の歴史をもつ言語である。型表現はGDScriptよりしっかりしているし、型検査もビルド時にすべてなされる。
より著名なゲームエンジンであるUnityがC#を採用しているのもポイントで、仮にゲームエンジンを乗り換えたくなったときにも移行しやすそうな点は魅力的だった。
C#を採用してみた所感
そういった経緯で今回はC#を採用してみたのだが、先に結論だけ書いてしまうと、小規模の個人開発ならばデメリットのほうが大きいかもな…といった感触であった。C#に慣れ親しんできたとか、既存のコード資産があるとか、そういった理由があるなら採用を検討してもよいかもしれない。
ビルド時間が少し長め
C#はGDScriptと違って実行前に全体をビルドする。これは先に書いた型エラー検出の問題を解決する一方で、ビルドの時間が長くなるデメリットも同時に生み出している。
普段開発に使用しているのはMacBook Air M1 (2020)で、開発機としては恵まれているものではないが、それでも我慢できるレベルに収まっており、思ったほどのビルド時間ではなかった。
ホットリロードが効かない
ホットリロードとは、デバッグビルドの実行中にファイルを変更したとき、それが即座に反映される機能のこと。再ビルド・再実行にかかる時間が節約できるので、パラメーター調整やバグの追跡調査に威力を発揮する。
シーンの変更は即座に反映されるが、C#のコード変更は反映されない。GDScriptならば（すべてではないが）コードの変更も反映されるので、ここはC#が劣るといってよいだろう。
ファイルサイズが大きい
今回一番気になったのが、エクスポート後のアプリのファイルサイズである。1作目と2作目のコード規模はだいたい2:1程度なので、本来であれば1作目のほうが大きくなるのが自然であるが、結果は…：
| プラットフォーム | GDScript（1作目） | C#（2作目） |
|---|---|---|
| macOS | 131MB | 291MB |
| Windows | 65MB | 168MB |
C#のほうが圧倒的にファイルサイズが大きい。というのも、C#をビルドしたあとの中間コードを動かすのに必要なランタイムが同梱されており、それが容量の多くを占めているのである。
ファイルサイズが嵩むことは想定していたが、ちょっとしたツールを使ってもらうためだけに300MB弱を消費するのはさすがに気が引ける。今回のプロジェクトでいえば、大人しくGDScriptを採用するのがよかったかもしれないな、という感想に落ちついた。
移行の手間はほぼ無視できる時代に
今回の制作で一番収穫だったのは、AIは言語の読み替えが想像以上に得意であるという知見が得られたこと。GDScriptとC#はまったく性質の異なる言語であるが、ほとんど問題なく言語を超えた移植をやってのけた。
自分はもともと設計には気を遣うほうで、普段からオブジェクトごとの責務分離を意識したり、Godot依存部分を極力切り離すようにしていたりしたとはいえ、それでも本業の片手間の数時間で共通処理を移植し終えてしまう馬力には恐怖すら感じた。（こいつが人類からコードを書く楽しみを奪ったのだ…！）
この調子なら今後、ゲームエンジンの乗り換えも採用言語の選択も、もっと気軽に考えていけそうだ。こういった決断は、いままでは将来を左右する重いものであったが、その重荷から解放されるのはありがたい。
まとめ
以上、ゲーム制作でGodot EngineとC#の組み合わせを採用してみた話であった。特にアプリのファイルサイズが大きいなどのデメリットを受け、小規模の個人開発ならばGDScriptも悪くない選択肢であるという感触が得られた。次回作はC#で作りはじめていたが、もしかするとGDScriptに戻すかもしれない。
そんな『うさぎとぷーぷベビー』は、日本向けにはBOOTH、海外向けにはitch.ioにて好評配信中である。
お知らせ：お仕事を募集しています
ちょうど大きなプロジェクトがひと段落したため、週2〜3程度の規模でお仕事を募集しております。
大小さまざまなプロジェクト規模での経験や、デザインから開発・広報までの幅広い知見をもとに、Webサービスやモバイルアプリの制作をお手伝いしています。詳細についてはAboutをご覧ください。
お問い合わせはお気軽に、X/TwitterのDMやメール cocopon at me.com までお願いいたします。Godotを使った2Dゲーム開発ももちろんお手伝いできます！
