ゲームのソースと公開ビルドを分けて管理する

プレイアブルなWebビルドだけを公開リポジトリへ置き、ソースと配布物を分離する運用について。

公開したいものと管理したいものは同じではない

ブラウザゲームのレビューでは、コードを読んでもらうことより、URLを開いてその場で触ってもらえることの方が重要な場面があります。その一方で、開発用のリポジトリには設定ファイル、制作途中のアセット、検証用コードなど、配布には不要なものが多く含まれます。

そこで、開発ソースと公開ビルドを別リポジトリに分けています。公開側はHTML、JavaScript、WebAssembly、アセットなど、実行に必要な成果物へ限定します。これにより、公開リポジトリの役割が『配信すること』に明確になります。

分離の利点は、非公開コードを守ることだけではありません。公開ビルド側の差分が小さくなり、いま配信されているものを追いやすくなります。また、GitHub Pagesのような静的ホスティングでは、成果物だけを置いた方が構成が単純です。

一方で、ソースと成果物の対応関係が分からなくなる問題もあります。そのため、公開時にコミットをまとめ、何を反映したビルドなのか追跡できる運用が必要です。単にコピーするのではなく、公開工程そのものを小さなリリース作業として扱います。

ゲームは画面だけ見ても操作感が分かりません。カメラ、入力、アニメーション、待ち時間、スマートフォンでの収まりは、実際に動かして初めて問題が見えます。完成後に公開するのではなく、判断できる状態になった時点で公開ビルドを作ると、レビューの速度が上がります。

公開URLをひとつのテスト環境として扱うことで、エディタ内では見えない配信上の問題も含めて確認できます。小さなプロトタイプほど、このサイクルを短く回す価値があります。