従来の MSIXVC 形式に固有のコンテンツ更新ガイダンスについては、コンテンツ更新のベスト プラクティス を参照してください。
MSIXVC2 のコンテンツ更新の仕組み
コンテンツ ベースのセグメント化
MSIXVC2 は、固定ブロック境界ではなく、実際のコンテンツに基づいてファイル データを可変サイズのセグメントに分割します。各セグメントは、その内容のハッシュによって識別されます。 このアプローチは以下を意味します。- チャンク間でファイルを移動しても再ダウンロードはトリガーされません。 ファイルのコンテンツ ハッシュは、どのチャンクに属していても同じままです。
- チャンク内でファイルを並べ替えても再ダウンロードはトリガーされません。 セグメント境界は位置ではなくコンテンツによって決定されます。
- チャンクを並べ替えても再ダウンロードはトリガーされません。 チャンク レイアウトは、データの物理的なセグメント化に影響しない論理的な概念です。
- データの挿入または削除がカスケードしません。 固定ブロック システムとは異なり、小さな挿入は後続のすべてのブロックをずらすことはなく、変更されていないコンテンツの再ダウンロードを強制しません。
アップロード時の重複排除
すべてのセグメントは、アップロード前にハッシュ化されます。アップロード プロセスは、以前のバージョンから既に存在するセグメントを判別するために CDN に問い合わせます。プレイヤーには新規または変更されたセグメントのみがアップロードされ配信されます。この重複排除は自動的に行われ、開発者のアクションは必要ありません。セグメントごとの暗号化と圧縮
各セグメントは独立して圧縮および暗号化されます。これにより、1 つのセグメントの更新が他のセグメントに影響しないことが保証されます。MSIXVC からの変更点
MSIXVC のコンテンツ更新における以下のアライメントとレイアウトの制約は、MSIXVC2 には 適用されません。更新サイズの比較
以下のデータは、同じタイトルのビルドについて MSIXVC と MSIXVC2 のコンテンツ更新サイズを比較しています。ゲームには変更を加えていません。同じアセット、同じビルド、異なるパッケージング形式です。
Game D で改善が小さいのは、タイトルが既に MSIXVC コンテンツ更新 (CUv3) 向けに手動で最適化されていたためです。この最適化作業を行っていないほとんどのタイトルでは、より大きな削減が見られます。MSIXVC2 では、この最適化作業は不要になります。
パッケージ オーバーヘッドの削減
すべての MSIXVC パッケージには、ゲームの全体サイズに応じて拡大する固定の最小ハッシュ ツリーが含まれます。このオーバーヘッドは、常に更新のたびに完全にダウンロードされます。大規模タイトルでは、このオーバーヘッドは重要です。
MSIXVC2 のオーバーヘッドは部分的にダウンロード可能でもあり、プレイヤーは更新に関連するメタデータの一部分のみを受け取ることを意味します。
ベース ゲーム サイズの改善
コンテンツ ベースのセグメント化と組み込みの圧縮は、ベース ゲームのダウンロード サイズも削減します。
圧縮されていないコンテンツを持つタイトル、またはチャンク間で重複するデータが多いタイトルでは、ベース サイズの削減が最大になります。すべてのコンテンツを既に圧縮しており、重複がないタイトル (Game D など) では、改善は小さくなりますが、依然として意味のあるものです。
タイトルにおける MSIXVC2 の評価
自分のタイトルのコンテンツ更新の改善を測定するには、次の手順に従います。- ゲームの連続する 2 つのビルド (例: リリース ビルドとその後のパッチ) を用意します。
makepkgを使用して両方のビルドをパッケージ化します。
- 結果として得られる更新サイズを、同等の MSIXVC (v1) ビルドと比較します。
- 比較結果を使用して、MSIXVC2 への移行を計画します。
MSIXVC2 パッケージは Partner Center 内の別のブランチ (例:
msixvc2) にアップロードしてください。同じブランチで MSIXVC2 と MSIXVC のパッケージを混在させないでください。ブランチを MSIXVC2 から MSIXVC に戻すには完全な再アップロードが必要で、そのブランチのプレイヤーに完全な再ダウンロードを強制します。詳細については、パッケージ ブランチのベスト プラクティス を参照してください。