Vue d’ensemble
Vous pouvez mettre à jour des paquets de contenu après leur sortie en modifiant, en ajoutant ou en supprimant des données. Pour lancer une mise à jour, téléversez le paquet mis à jour complet vers Partner Center et publiez-le. Les futures installations numériques du contenu téléchargent directement le paquet mis à jour. La technologie de mise à jour de contenu du système modifie les installations existantes pour qu’elles reflètent le paquet mis à jour. Le contenu du Microsoft Game Development Kit (GDK) est empaqueté dans des paquets XVC ou MSIXVC fonctionnant à une granularité inférieure au fichier. Vous pouvez remplacer des données sur place. Vous pouvez également insérer ou supprimer des données d’un fichier par multiples de 4 kibioctets (Kio) (4 096 octets). Vous ne pouvez pas déplacer des données efficacement. Lorsqu’un utilisateur installe, à partir de son disque de jeu d’origine, un jeu qui a déjà une mise à jour de contenu, le processus d’installation extrait les données à la fois du disque et du nuage. Les parties inchangées du paquet sont installées à partir du disque, tandis que les données mises à jour sont téléchargées à partir du nuage par installation en streaming. Ce processus se comporte exactement comme une installation en streaming normale dans l’interface utilisateur du système et pour toutes les API du jeu. Lorsqu’une console ou un PC met à jour du contenu déjà installé, le processus modifie sur place le fichier de paquet XVC ou MSIXVC installé pour tenir compte des données nouvelles ou supprimées, puis télécharge les nouvelles données. Le jeu ne peut pas être exécuté entre le début et la fin de l’installation de la mise à jour.Créer des paquets efficacement
Les mises à jour de contenu tentent de ne pas nuire au processus de développement du jeu. Quelles que soient les modifications que vous apportez au contenu du jeu, vous pouvez mettre à jour un paquet correctement. Toutefois, le processus pourrait ne pas être efficace en matière de taille de téléchargement (ce qui correspond au temps pendant lequel les joueurs ne peuvent pas jouer) ou d’espace disque consommé. Les conseils suivants vous aident à empaqueter un jeu pour assurer la meilleure expérience utilisateur. Simple :- Si vous utilisez des fichiers pack pour regrouper plusieurs ressources dans un seul fichier, assurez-vous que le créateur de fichiers pack aligne le début de chaque ressource sur une limite de 4 Kio. Ce conseil est illustré dans l’exemple d’alignement simple.
- Si vous compressez des ressources, assurez-vous que la compression est déterministe et que chaque ressource est compressée indépendamment.
- Ne modifiez pas un ID de bloc et ne déplacez pas un fichier d’un ID de bloc à un autre.
- Ne réordonnez pas les blocs dans le paquet, les fichiers dans un bloc ou les ressources dans un fichier. Envisagez d’ordonner les ressources selon leur nom ou un autre identificateur stable.
-
Si vous utilisez des fichiers pack pour regrouper plusieurs ressources dans un seul fichier, assurez-vous que le créateur de fichiers pack aligne le début de chaque ressource de façon cohérente. Cette directive est une version avancée de l’alignement systématique sur le début d’une limite de 4 Kio.
Prenons l’exemple d’une ressource qui commence au décalage
PriorAssetOffsetdans le paquet précédent et au décalageAssetOffsetdans le paquet en cours de génération avec les mises à jour. Pour vous assurer que le créateur de fichiers pack aligne le début de chaque ressource sur une limite de 4 Kio, définissezPriorAssetOffset % 4096 == 0etAssetOffset % 4096 == 0. Cette condition satisfait toujoursPriorAssetOffset % 4096 == AssetOffset % 4096. Toute autre façon de satisfaire cette égalité fonctionne également. Cette condition peut permettre au créateur de fichiers pack d’utiliser moins de remplissage. Ce conseil est illustré dans l’exemple d’alignement avec état. - Si vous utilisez une compression non déterministe et que la ressource non compressée est inchangée, copiez ses données compressées à partir de l’empaquetage précédent afin que les données compressées soient également inchangées.
- Si les ressources sont ordonnées automatiquement pour correspondre à l’ordre de chargement prévu à l’exécution, envisagez de figer l’ordre automatique lors de la première sortie.
- Si un fichier pack contient de nombreuses petites ressources qui changent fréquemment lors des mises à jour, envisagez de les rendre adjacentes. Il est plus efficace de modifier 400 Kio que de modifier 4 Kio 100 fois.
Exemples de bon et de mauvais alignement dans les fichiers pack
Certains jeux combinent de nombreuses ressources dans de gros fichiers appelés fichiers pack. La mise à jour de contenu au niveau inférieur au fichier améliore considérablement l’efficacité de la taille de téléchargement et de l’espace disque lors du téléchargement des mises à jour de ces jeux. Pour tirer parti de cette technologie, il est important que l’outil de création de fichiers pack du jeu préserve l’alignement de 4 Kio des ressources dans le fichier. Cette section présente des exemples de bonnes et de mauvaises façons d’aligner les ressources dans un fichier pack. À titre d’illustration, chaque exemple est présenté sous la forme d’une série de cellules contenant une lettre. Chaque cellule représente 1 Kio dans le diagramme afin de simplifier l’illustration. Les lignes pleines entre les cellules représentent les limites de 4 Kio.Remplacement de données
Dans le diagramme suivant, une seule cellule est remplacée lors de la mise à jour. Le seul téléchargement est la page de 4 Kio contenant cette cellule.
Insertion
Dans le diagramme suivant, une seule cellule est insérée lors de la mise à jour. Par conséquent, chaque cellule après l’insertion est décalée d’une position. Ce décalage fait passer les cellules au-delà des limites de 4 Kio, de sorte qu’aucune des pages de 4 Kio n’est identique dans l’ancien et le nouveau paquet après l’insertion. Chaque page de 4 Kio après l’insertion est téléchargée.
Suppression
Dans le diagramme suivant, une seule cellule est supprimée lors de la mise à jour. Par conséquent, chaque cellule après la suppression est décalée d’une position. Ce décalage fait passer les cellules au-delà des limites de 4 Kio. Chaque page de 4 Kio après la suppression est téléchargée.
Alignement : simple
Le diagramme suivant montre six ressources. Chaque ressource est stockée dans un nombre arbitraire de cellules. Le début de chaque ressource se trouve sur une limite de 4 Kio. Par conséquent, vous pouvez ajouter, modifier (y compris augmenter ou diminuer la taille) ou supprimer des ressources de façon indépendante. Cet alignement est la façon la plus simple d’aligner les ressources dans un fichier pack.
Alignement : avancé sans état
Le diagramme suivant montre sept ressources. Chaque ressource est stockée dans un nombre arbitraire de cellules. Le début de chaque grande ressource est aligné sur une limite de 4 Kio, mais les petites ressources (la ressource 6 dans le diagramme) sont placées de façon contiguë à la ressource précédente, sans remplissage. Cette méthode d’alignement offre trois avantages :- Elle utilise moins d’espace pour le remplissage.
- Lorsque vous modifiez la ressource 5, le téléchargement de la ressource 6 est en fait gratuit.
- Lorsque vous modifiez la ressource 6, les 4 Kio complets sont téléchargés de toute façon. Peu importe qu’il s’agisse de remplissage ou de la fin de la ressource 5.
Alignement : avancé avec état
Le diagramme suivant montre sept ressources. Chaque ressource est stockée dans un nombre arbitraire de cellules. Dans le premier paquet, le début de chaque ressource est placé sans remplissage. Dans le nouveau paquet, chaque ressource commence au même décalage dans une page de 4 Kio que dans l’ancien paquet. Par exemple, la ressource 3 commençait une cellule après le début d’une page de 4 Kio dans l’ancien paquet. Dans le nouveau paquet, du remplissage a été ajouté avant la ressource 3 afin qu’elle commence également une cellule après le début d’une page de 4 Kio. Cette approche préserve l’alignement requis par la mise à jour de contenu tout en réduisant au minimum la quantité de remplissage. L’inconvénient de cette approche est qu’elle exige que l’outil de fichiers pack connaisse la disposition de l’ancien fichier pack afin de faire correspondre ses décalages.
Fragmentation
Pour les titres qui ont un long historique de mises à jour, avec de nombreuses modifications de fichiers existants au fil du temps, et pour les paquets qui comportent un nombre important de petites modifications à de gros fichiers, les algorithmes de mise à jour de contenu pourraient produire des tailles de mise à jour sous-optimales. Vous pouvez déceler des tailles de mise à jour sous-optimales de deux façons :- Examinez la sortie de
makepkg packlorsqu’il est exécuté avec/priorpackage. Elle affiche un avertissement : « More than # page-level XTS entries. Page-level update efficiency will be compromised for # pages. » - Examinez les rapports de comparaison produits par
makepkg packoupackageutil compare. Si ces rapports indiquent que des fichiers que vous savez inchangés sont téléchargés de nouveau à 100 %, cette situation peut être le symptôme d’un manque d’espace dans la structure de données des fragments de chiffrement du format de fichier XVC.
/maxencryptionfragments de makepkg pack pour générer un calcul delta plus optimal. Définir une valeur trop élevée augmente le risque d’erreurs de mémoire insuffisante lors du lancement du jeu ou du montage du DLC.
Lorsque vous insérez des données, la mise à jour de contenu entraîne une fragmentation des données du paquet sur le disque dur physique. La mise à jour de contenu tente de réduire cet effet en effectuant une défragmentation partielle du paquet pendant la mise à jour. Sous réserve de l’espace disque disponible, elle garantit que la somme des tailles de deux fragments adjacents est d’au moins 100 mébioctets (Mio). La mise à jour de contenu tente de faire en sorte que tous les fragments aient au moins 100 Mio.
Les itérations précédentes de la mise à jour de contenu pour l’ERA de la XBOX One n’effectuaient pas de défragmentation.
Utilisation des outils
makepkg /contentid GUID: Paramètre d’ID de contenu qui, avec le nom de famille de paquet, identifie un paquet d’une version à l’autre. Pour tester la mise à jour entre des paquets, créez les deux paquets en utilisant le même ID de contenu et le même nom de famille de paquet.packageutil compare: Cet outil génère un plan de mise à jour qui décrit comment passer d’un ancien paquet à un nouveau paquet. Il génère également un rapport qui énumère les fichiers et les plages de ces fichiers qui sont téléchargés pour effectuer la mise à jour. Utilisez ce rapport pour repérer les modifications inattendues.xbapp update(PC :wdapp update) : Cet outil met à jour, vers un nouveau paquet, un paquet déjà installé sur une console de développement ou un PC. Il utilise la même méthode que les consoles commerciales; vous pouvez donc l’utiliser pour tester l’expérience utilisateur et les performances d’E/S après la mise à jour.
Détails
Cette section décrit des détails d’implémentation sur le fonctionnement de la mise à jour de contenu. Ces détails peuvent changer. Elle s’adresse aux développeurs très intéressés qui veulent tout comprendre et tout optimiser. Que sont les plans de streaming de mise à jour? Les plans de streaming de mise à jour sont une évolution de la technologie XBOX FastStart. Content Update v3 utilise ces plans pour indiquer à la console XBOX et aux PC comment transformer un ancien paquet en nouveau paquet. Cette approche permet d’effectuer dans le nuage, au moment de la publication, une analyse plus approfondie que ce qu’une console ou un PC pourrait faire pendant le téléchargement. Pourquoi 4 Kio a-t-il été choisi comme multiple autorisé pour l’insertion ou la suppression? 4 Kio est la taille de cluster NTFS sur XBOX et sur les systèmes de fichiers PC pris en charge. Effectuer une insertion ou une suppression selon un multiple différent de la taille de cluster NTFS nécessiterait des E/S disque importantes pour installer la mise à jour. Les paquets de contenu sont chiffrés et leur intégrité est protégée par blocs de 4 Kio. Effectuer une insertion ou une suppression selon un multiple différent de la taille de bloc cryptographique nécessiterait de chiffrer de nouveau les données pour installer la mise à jour. Cette exigence empêcherait les mises à jour en arrière-plan dans les scénarios où aucune licence n’est disponible parce que l’utilisateur approprié n’est pas connecté ou que le disque de jeu n’est pas disponible. Grâce à cette exigence, les paquets peuvent être mis à jour efficacement, sans nécessiter une étape de décompression longue à la fin du processus de mise à jour. Que se passe-t-il pendant makepkg/packageutil par rapport à la publication? Le même traitement se produit dans les deux cas. Pendant la publication, le paquet est chiffré à l’aide des données du meilleur paquet précédent choisi par le nuage (l’équivalent de makepkg /priorpackage). Un plan de streaming de mise à jour à partir de nombreux anciens paquets est ensuite généré (l’équivalent de packageutil compare). Le paramètre /priorpackage spécifié dans makepkg a-t-il une incidence sur le paquet commercial? Non. Le processus de publication dans le nuage remplace toujours cette spécification. L’optionmakepkg est fournie uniquement pour permettre une estimation locale avant la publication.
Seules les données de jeu mises à jour sont-elles téléchargées?
Non. Les paquets contiennent d’importantes données système, notamment les hachages cryptographiques de toutes les pages de données, le Game OS (console seulement) et un système de fichiers NTFS intégré. Ces données sont téléchargées au besoin.
De plus, certaines données inchangées pourraient être téléchargées de nouveau afin de réduire la surcharge des requêtes HTTP. Actuellement, les données inchangées de moins de 64 Kio entourées de données modifiées peuvent être téléchargées de nouveau, mais cette configuration peut changer afin d’optimiser le temps de téléchargement.
Le rapport généré par packageutil compare tient compte des informations précédentes dans son estimation.