ビジュアルノベルは、画面上でほとんど動きがなくても高い負荷がかかることがあります。大きなキャラクターのポートレート、背景、動画クリップ、音声はいずれも、ダウンロード時間、ストレージ容量、デコード、メモリ使用量に影響します。リアルタイムのシーンでは、アニメーション、ライティング、レンダリングの処理も加わります。静止したシーンにも予算は必要です。
承認済みの見た目と、対象端末向けの予算を出発点にします。ブラウザーのエミュレーションでレイアウトの問題を見つけることはできますが、実機の性能を確認するには実機テストが必要です。性能について何かを述べる際は、その都度、端末、ブラウザーまたは実行環境、ビルド、テスト条件を記録し、結果を再現できるようにします。
代表的なシーンと端末を選ぶ
動きの少ないシーン、大きなアセットが複数あるシーン、切り替えが頻繁に起こる一連の場面、そして動画やリアルタイム処理を含むすべての区間を選びます。サポート対象の最低仕様の端末と、一般的な端末を指定します。プレイヤーがテキストを読み、選択肢を選べる必要がある最小の画面も含めてください。
コールドスタート、再度の起動、シーンの切り替え、継続的な操作を測定します。アセットの初回ダウンロードは、キャッシュを使用する実行とは分けて扱います。テクスチャの欠落、デコードの遅さ、入力の遅延、再読み込みは、それぞれ独立した不具合として記録します。平均フレームレートだけでは、こうした問題が見えなくなることがあります。
配信するアセットの予算を測定する
出荷するすべてのアセットについて、書き出し時の寸法、ファイルサイズ、同時にメモリ上に保持される可能性があるアセットの数を記録します。ダウンロードサイズからは、デコード後の画像が占有するメモリ量は分かりません。圧縮によってファイルが大幅に小さくなることがあるためです。編集可能なソースファイルは、プレイヤーに配信する書き出し済みファイルとは分けて保管します。
アセットが実際に画面上でどう表示されるかに合わせて、書き出しサイズを調整します。ライブラリ全体を変換する前に、候補となる形式を対象の実行環境で比較し、透明部分の輪郭、グラデーション、テキスト、顔を承認済みのアートワークと照合します。圧縮でキャラクターのクローズアップが台無しになれば、ファイルが小さくなってもあまり慰めにはなりません。
動画を独立した負荷として扱う
予算内に動画専用の項目を設けます。解像度、長さ、エンコード、ビットレート、音声、各クリップを事前読み込みするかどうかを記録します。対象端末で、再生開始、ループ、一時停止、代替表示をテストします。デスクトップのエディターで再生できても、ブラウザーやパッケージ化したモバイルビルドでの動作が確認できたことにはなりません。
すべての差分を一度に読み込むのではなく、そのシーンに必要な差分を読み込みます。設計上可能であれば、ポスター画像や静止画による代替表示を用意し、プレイヤーが再生を操作できるようにします。デコードや同時に表示されるアートワークも含め、切り替え全体を測定します。書き出したクリップのファイルサイズが示すのは、負荷の一部にすぎません。
操作の応答性を維持する
テキストを読みやすくし、操作部分を十分な大きさにします。素早い画面移動、サイズや向きの変更、再生中の設定変更、バックグラウンドからの復帰をテストします。処理が完了していない間は、入力が一度だけ受け付けられ、同じ操作が重複して実行されないことを確認します。
ブラウザーゲームでは、必要な箇所でキーボード、タッチ、フォーカスの挙動を確認します。シーンが滑らかでも、オーバーレイが次の選択肢を隠したり、切り替え中に何の表示もなく入力が受け付けられなくなったりすると、不具合があるように感じられます。目に見えるフィードバックと、操作部分にアクセスできることも応答性の一部として扱います。
最適化の候補を個別にテストする
関連するアセットやレンダリング条件を一度に一つだけ変更し、基準と比較します。性能の測定結果とともに、見た目の合否も記録します。3Dの作業では、同じシーン、同じカメラでLOD、テクスチャ、ライティングの変更を比較します。
直接比較できるよう、元のものを残しておきます。配信するデータ量が減っただけでは、性能が改善したとは言えません。圧縮によってデコードやアップロードのコストが変わることがあり、レンダラーの変更によって見た目が変わることもあります。修正しようとしている不具合に関連する指標を測定します。
リリース予算を設定し、遵守する
バーティカルスライスでの観察結果を使い、対象端末での配信サイズ、切り替えの遅延、メモリに関する不具合、入力応答性について、実用的な上限を設定します。新しい章やアセットの種類によって負荷が増えたら、再確認します。予算は、そのビルドと端末が無理なく処理できる範囲を反映させる必要があります。
端末レポートを候補ビルドとともに保管し、未テストの端末は未検証と明記します。承認済みの表現を維持し、再現可能な条件のもとで意図した体験を改善する最適化を採用します。
重要な決定事項
- ダウンロードサイズ、デコード後のメモリ使用量、レンダリングコストを別々に追跡します。
- 代表的なシーンを対象端末の実機で測定します。
- 一つの変更候補を、承認済みの基準と比較します。
- レイアウトの確認にはエミュレーションを使い、性能についての主張には実機テストを使います。
ガイドのファイル
アセット台帳 ↓端末テストマトリクス ↓外部のモデル関連コミュニティやコンテンツ公開サイトには、露骨な表現を含むコンテンツが掲載されている場合があります。出典へのリンクは新しいタブで開きます。このガイドでは、リンク先のプレビューを読み込みません。