63秒から60秒へ。ゲームトレイラーの尺をコードと動画で照合する

短いゲームトレイラーでも、タイトル、戦闘、強化、ボス、公開先を順に入れると尺が埋まります。最後に数秒削るだけでは、最初に伝わる内容は変わりません。

VOLT NOMADの履歴には、63秒を指定した初版と、60秒へ組み直した第2版が残っています。変わったのは総時間だけでなく、戦闘を最初へ置いたことでした。この記事では、各区間をコードで定義した構成と、実際の動画ファイルを照合します。

確認日は2026年9月11日です。固定コミットのコードとGit内のMP4を読みました。動画を作り直したり、視聴維持率を測ったりした記録ではありません。

初版の戦闘は13秒から、第2版は最初から

初版のbf5c7e7にある撮影コードは、冒頭を次の順にしています。

指定区間	初版の内容
0.0〜3.5秒	キービジュアル
3.5〜8.0秒	タイトル画面
8.0〜13.0秒	ルート選択
13.0〜22.0秒	戦闘

第2版を含むf074703の撮影コードは、最初に強化前の戦闘、その次に強化後の戦闘を置いています。

指定区間	第2版の内容
0.0〜4.5秒	最初の戦闘、クリック・ダメージ・CHARGE
4.5〜10.0秒	強化後の戦闘
10.0〜16.0秒	ギアツリー
16.0〜21.0秒	ルート選択

コードの順番から、「どの操作が何につながるか」を冒頭へ持ってきた変更は確認できます。これによって視聴者の理解や再生数が改善したかは測定していません。

尺を詰めるときの判断として持ち帰れるのは、各素材を少しずつ短くする前に、最初に見せたい操作を決め直せることです。

区間表を撮影処理にも使う

第2版のbeats配列には、開始、終了、場面ID、字幕などが入っています。実行時は経過時間から区間を選びます。

func beat_index_at(time: float) -> int:
	for index in range(beats.size()):
		if time < float(beats[index].end):
			return index
	return beats.size() - 1

場面が切り替わると、ゲーム状態や表示を撮影用に設定します。最後はDURATIONへ達した時点で終了します。

この実装では終了時刻から区間を選ぶため、表の開始時刻を別途使って空白時間を作る仕組みではありません。開始値と前の終了値がずれていると、表の説明と実行の解釈が食い違います。

今回の検証では11区間について、最初の開始が0、前の終了と次の開始が一致、最後が60であることをassertしました。さらに、この関数を変更せずGodotへ抜き出し、境界の直前と境界ちょうどで前後の区間が選ばれることを確認しました。開始・終端も含め22個のassertionが成功しています。表の重複や空白と、切替位置を確認するための試験です。

ゲーム画面を使うことと、通常プレイの録画は違う

撮影用のノードは、実際のChargeClickerを生成しています。一方で、進行を早めるための設定変更や、一定間隔での攻撃呼び出しも撮影コードが行っています。

保存は無効、表示言語は英語、撮影中の音はミュートに設定されています。実際のゲームの描画を使いますが、人が最初から最後まで通常操作したプレイ動画ではありません。

第2版では、ゲームノードを隠す場面がprime_artとfinalです。その二つを除いた区間を足すと51.5秒でした。

区間の分類	コード上の合計
ゲームノードを表示する区間	51.5秒
シネマティック画像	3.5秒
最後のタイトル・公開先	5.0秒
全体	60.0秒

これは撮影コードの区間合計です。完成動画の全フレームを目視し、ゲームが見える秒数を測り直した結果ではありません。制作紹介でこの数字を使うなら、何から算出したかも残します。

音楽を合わせた最終ファイルを別に確認する

制作READMEには、Godotで出力した映像へ選定した音楽を合わせる手順があります。A案の静かな部分と強い部分が場面転換に合うため採用した、と記録されています。今回その二案を聴き比べたわけではありません。

合成スクリプトは、映像を1920×1080へ変換し、30 fps、60秒のMP4へ出力します。音声にはvolume=0.63と、59.2秒から0.8秒のフェードアウトを指定しています。

FFmpegのvolume仕様では、この値は入力に掛ける倍率です。0.63は約-4 dBに相当します。目標ラウドネスへ自動で揃える処理ではないので、最終動画のLUFSを測った値とは区別します。

スクリプトには、出力先が既に存在した場合に上書きを拒否する処理もあります。初版を残したまま第2版を比較できる運用と相性のよい条件です。今回このスクリプト自体は再実行していません。

指定63秒と、ファイルの63.033333秒

Git内のMP4を一時ファイルへ取り出し、ffprobe 9.0.1でメタデータを確認しました。

対象	解像度	フレームレート	format.duration
初版	1280×720	30/1	63.033333秒
第2版	1920×1080	30/1	60.000000秒

両方とも映像はH.264、音声はAAC、48 kHzのステレオでした。初版のコードが指定する63秒と、実ファイルのdurationは完全には一致していません。差の発生箇所を今回のメタデータ確認だけで断定しません。

同様に、READMEの区間表には秒単位に丸めた時刻があります。フレームを基準に字幕やカットを直す際は、説明文の「00:04」ではなく、撮影コードの4.5秒と実際の映像を確認します。

再現スクリプトと確認結果に、区間表、ファイルのハッシュ、ffprobeの出力を残しました。元動画や公開先は変更していません。

区間表は伝える順序を決めるために使い、完成ファイルはその順序と尺が反映されたかを確かめるために使います。コードの指定値と完成ファイルの時間は、別の確認結果として残します。