Godotの開発者が、すべての依存ライブラリをプロジェクトのリポジトリ内で管理せずに、CやC++のライブラリをゲームに組み込むための新たなパッケージ利用手段を得た。ConanはConanCenterでgodot-cpp 10を公開した。これにより、依存関係管理ツールのConanを通じて、ゲームエンジンの公式C++バインディングをほかのネイティブパッケージと一緒に解決できるようになる。

GodotのプロジェクトはGDScriptで書かれることが多いが、シミュレーション、ネットワーク処理、データベース、機械学習の実行環境などの用途では、ネイティブライブラリも有用だ。GodotのGDExtensionインターフェースを使えば、エンジン自体を再ビルドせずに、コンパイル済みコードをエンジンに読み込める。godot-cppのバインディングは、この低水準のインターフェースを包み、公開するプロパティも含め、C++のクラスをエディター上でエンジンのクラスとして表示できるようにする。

従来、より複雑だったのはビルドの手順だ。プロジェクトは、配布を予定する各OS、アーキテクチャ、ビルドターゲットに対応したバインディングをコンパイルする必要がある。サードパーティーのライブラリにも、それぞれに対応するビルドとフラグが必要になる。Godotのドキュメントで定着しているサブモジュールとSConsを組み合わせる方法は機能するが、プロジェクトごとにgodot-cppを個別にコンパイルし、すべてのネイティブ依存関係を別々に管理することになりかねない。

ConanCenterのレシピは、godot-cppをAPIバージョンやターゲットのオプションを選択できる標準パッケージにする。Conanの技術ガイドによると、godot-cpp 10はGodot 4.3以降に対応している。開発者は、対応が必要な最も古いAPIを選べる。Godot 4.3向けにビルドした拡張は、それより新しい互換性のあるリリースでは読み込めるが、それより古いバージョンでは読み込めない。Conanはパッケージの構成ごとにキャッシュを保存し、複数のプロジェクトで再利用できる。

Conanは、エンティティ・コンポーネント・システムのライブラリであるflecsを使い、独自のSwarmノードを登録するGodot拡張でこの手順を実演した。このサンプルは10万個の粒子をシミュレートし、flecsで位置を更新する。粒子ごとに個別のGodotノードを作るのではなく、MultiMeshを通じて描画する。共有ライブラリとして作成する拡張には、バインディングとflecsを静的にリンクするため、サンプルプロジェクトが読み込むネイティブライブラリは1つになる。

このサンプルによってプラットフォームごとの作業がなくなるわけではない。開発者は依然として、予定するすべてのエクスポート先に対応するプロファイルとビルドを用意する必要があり、拡張の記述ファイルではGodotのフィーチャータグを正しいバイナリに対応付けなければならない。実務上の変化は、依存関係のバージョンとコンパイラー設定を一元管理する点にある。パッケージの再利用によって、複数の拡張で繰り返すビルドを短縮できる可能性もある。オプションを明示すれば、選択したエンジンAPIとビルドターゲットが依存関係の設定上で分かるようになる。この手順は引き続きネイティブのツールチェーンに習熟した開発者を対象としており、GDScriptだけを使うGodotプロジェクトには変化をもたらさない。すでにConanを利用しているチームは、GodotのバインディングとConanCenterの1,900以上のライブラリを、プロジェクト内に個別に取り込んでビルドするものの集合ではなく、再現可能な1つのネイティブ依存関係グラフとして扱えるようになる。