セーブデータ・ローカライズ・アセットパッケージの構成：今後の更新でゲーム全体を作り直さないために

更新可能なインタラクティブ映像ゲームでは、物語のロジック、プレイヤーのセーブデータ、ローカライズされたテキスト、メディアアセットを分離し、安定したIDとバージョンマニフェストで結び付ける必要があります。字幕の一部分を更新するためにすべての動画を再パッケージ化したり、動画を1本差し替えたことで古いセーブデータが使えなくなったり、言語の追加で分岐ロジック全体を複製したりする構成にすべきではありません。

ロジックパッケージにはノード、条件、選択肢、状態への効果を保存します。テキストパッケージにはUIテキスト、字幕、メタデータを言語別に保存します。メディアパッケージには動画、音声、画像を保存します。セーブデータにはプレイヤーの状態と必要なバージョン情報だけを保存し、コンテンツは複製しません。実行時には論理アセットIDを使って、現在の言語とプラットフォームに対応するファイルを探します。

境界が明確になれば、チームは字幕やエンコードを個別に更新できます。セリフのテキスト、ファイルパス、条件をすべて1つのスクリプトにハードコードすると、変更のたびに広範囲の回帰テストが必要になります。

セーブデータには schemaVersion、コンテンツのバージョン、現在のノード、確定した選択、関係、証拠、リソース、世界の状態、既読アセット、設定を記録します。ノードのタイトル、ファイル名、表示テキストは、翻訳や編集によって変わるため、ロジックの判定に使いません。

変数の名前、型、デフォルト値を変更するたびに、旧スキーマから新スキーマへの移行処理を作成します。たとえば、0–100の信頼値を3段階に変更するなら、各範囲をどの段階に対応させるかを明確にします。移行前にセーブデータをコピーして検証し、失敗した場合は元のセーブデータを保持して、理解できるメッセージを表示します。何も知らせずに進行状況を消去してはいけません。

各テキストに安定したキーを付け、ノード、話者、画面上の文脈、文字数制限、変数の説明、参考動画を添えます。文脈から切り離された「いい」「続ける」だけでは正しく翻訳できません。翻訳者には、それが同意なのか、満足の表現なのか、ボタン操作なのかを知らせる必要があります。選択肢にもプレイヤーの意図を説明し、翻訳によって約束の意味が変わらないようにします。

字幕はタイムコードを共有できますが、テキストの長さは異なるため、改行と細かなタイミング調整を可能にする必要があります。吹き替えは言語によって尺がさらに大きく変わるため、操作が表示されるタイミングを原語の音声の最終フレームだけに依存させてはいけません。疑似ローカライズで、テキストの伸長、文字セット、グリフの欠落、UIレイアウトを早い段階でテストします。

Steamはストアとゲームの言語対応に関するドキュメントを提供していますが、実際に公開できる言語、ストアでの言語表示、ビルド設定は、リリース時点の公式要件に従ってください。Steamローカライズドキュメント

一般的な分割の軸には、チャプター、言語、プラットフォーム、解像度があります。初期パッケージにはランタイム、冒頭部分、必要なUIを含め、後続のチャプターは必要に応じてダウンロードできるようにします。多言語の吹き替え音声は別パッケージにし、容量の小さい字幕は基本パッケージに含められます。細かく分けすぎると、マニフェスト、リクエスト、ディスクの断片化に伴うコストが増えます。

各パッケージにはバージョン、依存関係、サイズ、チェックサム、任意であることを示すフラグを持たせます。チャプターに入る前に、必要なパッケージが完全に揃っているかを検証します。中断したダウンロードは再開できるようにし、検証に失敗した場合は再取得します。キャッシュを削除してもセーブデータは削除せず、再ダウンロードできるコンテンツをUIで説明します。

ノードは VID_C03_N010_MAIN を参照し、アセットマニフェストがプラットフォーム、言語、品質に応じて実際のファイルへ解決します。新しいエンコードを公開するときは、マニフェストとパッケージだけを更新し、ノードは変更しません。更新が途中までしか適用されず、ロジックが存在しないファイルを指すことを防ぐため、マニフェスト自体にも署名または整合性検証が必要です。

更新失敗時にロールバックできるよう、古いマニフェストを一定期間保持します。クライアント起動時には、まずロジックパッケージ、アセットパッケージ、セーブデータのスキーマが一緒に動作できるか、互換性を判定します。不整合な組み合わせでゲームに入らせてはいけません。

コンテンツ更新が現在のチャプターを変更する場合は、メインメニュー、チャプター終了時、明確な通知後の再起動など、安全な時点で適用します。プレイヤーが視聴している途中でノードを差し替えてはいけません。ホットアップデート前にトランザクションのチェックポイントを保存し、更新後に移行処理を実行して、再現可能な位置から再開します。

公開済みの物語では、できるだけノードIDを再利用せず、過去の選択の意味もむやみに変えないようにします。再構成が必要な場合は旧ノードと新ノードの対応表を作り、あり得るすべてのセーブデータに対して自動テストを行います。

プラットフォーム、言語、画質、チャプターの組み合わせを列挙し、必ずテストする代表的な構成を指定します。基本ロジックは毎回、全面的な回帰テストを行います。メディアの差し替えでは参照、最初のフレーム、字幕を重点的に確認し、セーブデータの移行には過去バージョンのサンプルを使います。キーの欠落、孤立したアセット、IDの重複、誤った依存関係、パッケージ容量の異常な増加を自動でチェックします。

ユーザーからの報告を再現できるよう、実際に読み込んだマニフェスト、パッケージ、アセットのバージョンをログに記録します。段階的な配信やキャッシュによって異なる組み合わせが生じるため、「最新バージョン」という情報だけでは足りません。

主要コンテンツがダウンロードに依存する場合は、サーバーが利用できなくても購入済みのプレイヤーがダウンロード済みのチャプターに引き続きアクセスできるか、必要な認証をどうキャッシュするか、インストールパッケージを保管できるかを検討します。具体的な事業上の方針やプラットフォームの仕組みは異なりますが、このリスクはアーキテクチャ設計の段階で議論すべきです。サービス終了時になって、すべてのノードにオンラインのマニフェストが必要だと気付くようではいけません。

次のステップ：ロジック、テキスト、メディア、セーブデータの4層の依存関係図を描き、古いセーブデータを1つ使って「動画の差し替え＋言語の追加＋変数名の変更」という更新を試します。移行、ロールバック、オフライン復旧のすべてを完了できて初めて、保守可能なアーキテクチャと言えます。