宣伝サムネを自動生成したら真っ暗だった。カメラが壁の中にいた

RicochetTanksでは、ゲーム本体だけでなく宣伝素材もできるだけ自動で作るようにしている。

画像、動画、投稿文。

毎回手で作るより、開発の出力から生成できる方が速い。

そこでサムネイルも自動撮影するようにした。

最初に出てきた画像は、ほぼ真っ暗だった。

原因はかなり単純だった。

カメラが壁の中に埋まっていた。

自動化すると、人間が普段やっている確認が消える

手でスクリーンショットを撮るなら、

• 画面が真っ暗
• 主役が映っていない
• 壁しか見えない
• 構図が変

なら、その場で気づく。

でも自動撮影では違う。

処理としては、

1. カメラを置く
2. Renderする
3. Fileへ保存する

まで正常に終わる。

PNGができた。

Exit codeも0。

それでも宣伝画像としては失敗している。

「画像が生成できた」を成功条件にしない

今回の問題で必要になったのは、画像生成処理の成否ではなく、画像内容側の検査だった。

最低限、

• カメラ位置が壁の内側ではない
• 対象の戦車が見える位置にいる
• 主要オブジェクトが画角から完全に外れていない

を確認してから撮るようにした。

最終的には、上から見下ろす構図へ寄せた。

RicochetTanksは壁と反射経路が重要なので、Top-downの方がゲーム内容も伝わりやすかった。

コンテンツ生成もSoftware Outputだった

最初は宣伝画像を、

「開発が終わった後に作る付属物」

くらいに考えやすい。

でも自動生成へ入れた瞬間、それは別のSoftware Outputになる。

入力があって、

ロジックがあって、

Artifactが出る。

なら当然、失敗もする。

今回なら、

ファイル生成成功 = サムネイル品質成功

ではなかった。

これはBuildでも同じ。

Artifactができたことと、使えることは別。

自動化率を上げるほど、見た目の検査が必要になる

宣伝素材の自動化はかなり便利だった。

ただ、人間が途中で見なくなるほど、

• Camera collision
• framing
• text overflow
• 暗さ
• UI被り
• 想定外のScene状態

のような問題を機械側で拾う必要が出る。

今回は「壁の中か」「対象が見えるか」だった。

もっと進めるなら、画像のbrightness、object visibility、safe areaまで検査できる。

いまの結論

宣伝素材の自動生成で最初に失敗したのは、画像生成コードではなく構図だった。

でも自動化している以上、構図もPipelineの責任になる。

ゲーム本体にTestを書くなら、宣伝素材にも最低限のAcceptanceを置く。

RicochetTanksでは、そこまで含めて開発工程へ入れることにした。