横画面か縦画面か、PCかWebか：公開形態を決めてから脚本を書く
公開形態は、脚本を書き終えた後に選ぶパッケージングの選択肢ではない。横画面か縦画面かで俳優の立ち位置と字幕のスペースが決まり、PCかWebかで入力方法、動画の保存、読み込み戦略、配信経路が決まる。遅くとも3分間のプロトタイプを作る前に、チームは主となる画面比率とプラットフォームを一つずつ決めるべきだ。
はじめに
公開形態は、脚本を書き終えた後に選ぶパッケージングの選択肢ではない。横画面か縦画面かで俳優の立ち位置と字幕のスペースが決まり、PCかWebかで入力方法、動画の保存、読み込み戦略、配信経路が決まる。遅くとも3分間のプロトタイプを作る前に、チームは主となる画面比率とプラットフォームを一つずつ決めるべきだ。
この記事は企画立ち上げ時の意思決定の枠組みを示すものであり、すべてのプロジェクトが一つのプラットフォームでしか公開してはいけないという意味ではない。主なプラットフォームを先に選ぶのは、初版の技術条件と視聴条件を検証できるようにするためだ。移植はコア体験が安定してから行うべきである。
横画面と縦画面で変わるのは構図だけではない
横画面は、複数人が同じフレームに入る場面、環境内の手がかり、監視映像、従来のPC・コンソールでの視聴に向いている。プレイヤーはより広い範囲に視線を動かすことができ、字幕や選択肢も画面の下部や側面に配置しやすい。
縦画面はスマートフォンを片手で持って見る使い方に近く、人物の顔や人間関係の対立を画面の中心に据えやすいが、環境情報に使えるスペースは少ない。字幕、選択肢、カウントダウン、システム通知が同じ領域を取り合う。撮影時にセーフエリアを確保していなければ、後工程では演技を覆い隠すか、文字を小さくするしかない。
横画面用と縦画面用をそれぞれ一式撮影することを前提にしてはいけない。横画面の素材を縦画面に切り抜くと人物関係や手がかりが失われ、縦画面の素材を横画面に入れると大きな余白が生じる。二つの画面比率に対応するには、構図の組み直し、字幕の確認、素材の書き出し、インターフェースのテストが必要であり、独立したコストとして計算すべきだ。
PC、Web、モバイルにはそれぞれ主要な制約がある
PCクライアントは、大容量の動画パッケージ、キーボード・マウスやコントローラーによる入力、オフラインのセーブ、Steamでの配信に向いている。その代わり、インストール、ビルド、プラットフォーム審査、より多くの機器差への対応が必要になる。
Web版は利用開始のハードルが低く、プロトタイプを共有しやすいが、ブラウザーの自動再生ルール、通信の変動、キャッシュ、デコード能力、タブの切り替えがすべて動画体験に影響する。開発用マシンの高速回線が実際の利用環境を代表していると考えてはいけない。
モバイルは縦画面や短時間の体験に向いているが、タッチ領域、システムによる中断、バックグラウンドからの復帰、ストレージ容量、異なる画面比率、ストアの規則に対応する必要がある。また、ユーザーは音を消して見る可能性が高いため、字幕と音に頼らないフィードバックは初版から設計すべきだ。
チームの好みではなく、プレイヤーの課題に基づいて選ぶ
中心となる課題が複数の監視映像を比較して細部を探すことなら、通常は横画面のPCが自然だ。中心となる課題が短編ドラマの対立場面で素早く態度を示すことなら、縦画面のモバイルが実際の利用状況に近い。主な目的が、見込みユーザーにインストールなしで3分間のプロトタイプを体験してもらうことなら、Webを検証用プラットフォームにできる。
《零点回拨》の完全版には、カスタマーサポートのインターフェース、通話記録、監視映像と証拠の比較が含まれるため、横画面のPCに向いている。一方、ユーザー獲得用の3分間のバージョンはWebで制作し、着信に対する一度の判断と一つの明確な結果を残すことができる。両者は単に書き出し先を変えたものではなく、完全な製品と検証用に切り出した一部分である。
プラットフォームが動画の組み込み方を決める
動画を「再生」できることは最低限の要件にすぎない。インタラクティブ映像ゲームでは、次の動画を事前に準備し、選択後に素早く切り替え、一時停止と再開を処理し、低スペックの機器でも映像と音声を安定させる必要がある。
UnityのVideoPlayer.Prepareは再生前のリソース準備に使われる。Unreal EngineのMedia Frameworkはローカルファイル、ストリーミングメディア、音声・映像トラック、BlueprintとUMGとの連携に対応している。GodotのVideoStreamPlayerにも独自の形式上の制約とWebでの性能上の制約がある。撮影後にすべての素材を変換する必要があると気づくのではなく、エンジンを選ぶ前に対象プラットフォームとエンコードを確認すべきだ。
公開形態の意思決定表を作る
各候補を1～5点で評価する。
| 評価項目 | 確認すべき事実 |
|---|---|
| プレイヤーとの適合性 | 対象ユーザーが実際にその機器と場面で利用するか |
| インタラクションとの適合性 | 入力、文字、手がかり、時間的プレッシャーが自然か |
| 視聴覚との適合性 | 画面比率が人物、字幕、選択肢を収められるか |
| 技術リスク | 動画、キャッシュ、セーブ、機器差を管理できるか |
| 配信コスト | アカウント、審査、素材、バージョン保守の量 |
| ユーザー獲得経路 | プレイヤーがどこで作品を見つけ、利用を始めるか |
| チームの能力 | 対応するテスト機器と開発経験があるか |
点数が自動的に答えを出すわけではない。「プレイヤーとの適合性」または「技術リスク」が3点未満の案は、総合点の平均で問題を埋め合わせるのではなく、まずその問題に絞ったプロトタイプを作るべきだ。
企画立ち上げ文書に三つの文を明記する
一つ目は、初版の主な画面比率とプラットフォームは何か。二つ目は、それが対象プレイヤーと中心となる課題に最も適している理由。三つ目は、当面対応しないプラットフォームと、再評価する条件だ。
公開形態が決まって初めて、脚本では一つの区間をどのくらい続けられるか、プレイヤーが同時にどれだけの情報を見られるか、選択肢をどう表示すべきかを把握できる。次の段階では、これらの制約をコアループに落とし込む。
作業開始前の公開形態チェック
実際に進める際は、対象機器、画面比率、1回の体験時間、入力方法、通信条件を同じ仕様カードに記載する。そのうえで、台詞、選択、字幕、動画の切り替えを含む最小限の区間を使い、横画面と縦画面の両方をテストする。構図、操作領域、素材コストがいずれも成立するとチームが確認してから、脚本全体の制作段階に進む。
