Contents — 7 sections
ゲームを作る。
完成したらスクリーンショットを撮る。
動画を編集する。
投稿文を書く。
普通にやると、宣伝は最後にまとめて発生する。
RicochetTanksでは、この後工程を少し変えた。
宣伝素材を作る仕組み自体を、開発側へ入れた。
作ったものを、そのまま発信用素材へ変える
現在の素材には、
- 制作過程の画像
- 宣伝用サムネイル
- Promo動画
- X向けの短文案
- 検証数値から作った投稿案
がある。
これらを「完成後に記憶を頼りに作る」のではなく、開発ログや検証結果から生成する。
たとえば、
- 操作を3回作り直した
- NPC戦の8割が接敵前だった
- Gitの改行で1714 filesが変更扱いになった
といった出来事は、発生した時点で記事やPostの素材になる。
Evidenceと宣伝を別々に作らない
先にEvidenceを残しておくと、宣伝文を作るときにも強い。
「かなり改善しました」
ではなく、
「最初の1発まで平均12.5秒だった」
と書ける。
「大量の差分が出た」
ではなく、
「1714 filesだった」
と書ける。
宣伝のために数字を作るのではなく、
検証のために残した数字を、発信へ再利用する。
失敗もそのまま素材になる
このPipelineで面白かったのは、成功だけが素材にならないこと。
自動サムネイルを作ったら真っ暗だった。
結果板の文字がはみ出した。
Gitの改行変換で大量差分になった。
こういう失敗も、
- 何が起きたか
- 原因
- 修正
- 次からどうするか
が残っていれば、記事になる。
PicoTowaの「Failures」と相性が良い。
宣伝素材にもTestが必要になった
自動化した結果、別の問題も出た。
サムネイルはFileとして生成できたのに、画面が真っ暗。
Cameraが壁の中にいた。
つまり、
生成成功 = 宣伝素材として成功
ではなかった。
宣伝素材も開発Artifactとして扱うなら、
- 主役が見える
- 暗すぎない
- 文字が切れていない
- 個人情報が映っていない
といったAcceptanceが必要になる。
投稿文もEvidenceの種類を混ぜない
RicochetTanksでは、
- NPC Simulation
- Editor検査
- ClientSim
- Agent操作
- 人間の実機操作
を分けている。
投稿文を作るときも同じ。
NPCの勝率を「初心者の勝率」と書かない。
Unity Renderを「実VRChat映像」と書かない。
自動化すると大量に文章を作れるからこそ、Evidence labelを保つ必要がある。
開発と発信を別Projectにしすぎない
発信を完全に別工程にすると、
「何をやったか思い出す」
ところから始まる。
その時点でかなり情報が落ちる。
逆に開発中から、
- Screenshot候補
- 数字
- Failure
- Before / After
- 未検証
を残しておけば、そのまま記事へ育てられる。
いまの結論
宣伝素材生成を自動化した理由は、投稿数を増やすためだけではない。
開発中に残したEvidenceを、時間が経っても発信へ変換できるようにするため。
RicochetTanksで作った素材は、実際にPicoTowa Labの記事ストックにも流れ込んでいる。
開発ログと発信を同じPipelineの前後として扱う方が、少なくとも今はうまく回っている。
Signal / 観測記録
この記録への観測を送る
反証、