Pourquoi utiliser des fichiers de manifeste d'actif?

Parfois, vous verrez que les gens recommandent cela plutôt que d'utiliser des graphiques / fichiers audio / etc. comme ça...

// Game code
Image myImage = new Image("path/to/image.png");

... vous devez plutôt utiliser un fichier manifeste comme niveau d'indirection:

// Manifest file
MY_IMAGE: path/to/image.png

// Game code
Manifest myManifest = new Manifest("path/to/manifest");
Image myImage = myManifest.getImage("MY_IMAGE");

Quelles raisons aurais-je pour adopter ce type d'approche? Si je n'utilise pas un langage compilé, y aurait-il encore des raisons de le faire?

La plupart du temps, les fichiers manifestes sont associés à une sorte de format de fichier d'archive. Par exemple, un fichier JAR en java est simplement un fichier zip avec un fichier manifeste qui répertorie les actifs dans le fichier zip et où les trouver. Dans ce cas, le "chemin / vers / image.png" n'est pas un véritable chemin d'accès au système de fichiers mais plutôt des informations sur la façon de trouver l'objet dans une archive compressée. En plus de l'avantage de l'espace disque de la compression, l'utilisation d'une archive de fichiers peut améliorer les performances car Windows a du mal à gérer des dizaines de milliers de fichiers individuels dans un petit nombre de répertoires.

En utilisant un fichier manifeste de ce type, vous pouvez complètement résumer la provenance d'un bloc de données donné. Peut-être que votre fichier est sur un DVD, ou diffusé en continu sur Internet, ou à l'intérieur d'un fichier zip. Vous devrez écrire du code supplémentaire pour faire face à ces cas, mais en utilisant un fichier manifeste, votre logique de jeu n'a pas à se soucier du tout d'où quelque chose est chargé.

Maintenant, si vous utilisez un langage non compilé, ce fichier manifeste pourrait certainement être un fichier source C #, mais c'est bien si vous pouvez facilement modifier le fichier manifeste que vous utilisez au moment de l'exécution du client en fonction d'un paramètre de registre ou quelque chose de similaire. Par exemple, vous pouvez vérifier pendant l'exécution pour voir s'il existe un cache sur le disque dur ou si seul le DVD est disponible. Vous pouvez ensuite changer le manifeste à utiliser en fonction de la configuration disponible.

Une raison: la programmation pilotée par les données.

Votre code peut vouloir seulement savoir qu'il a besoin d'une texture "LightWood" et laisser le gestionnaire de ressources utiliser cette clé pour trouver le bon chemin vers le fichier. De plus, dans les scripts, les gens ne veulent pas se souvenir des chemins de fichiers. Ils sont en désordre, ils peuvent être incorrects. Laissez le manifeste déterminer où se trouve le fichier et laissez l'homme déterminer le matériel dont il a besoin par son nom, pas par le nom du fichier.

<material name="wood">
  <diffuse color="1,1,1,1">environment.zip/wood_diffuse.jpg</diffuse>
  <normals>environment.zip/wood_normals.jpg</normals>
  <shader>environment.zip/wood.fx</shader>
  <specular color="1,1,1,1" power="0.5" flat="yes" />
</material>

En tant que modèle de conception général, les manifestes sont utiles lorsque vous souhaitez collecter toutes les informations sur un ensemble disparate d'objets en un seul endroit. Il ne doit pas nécessairement s'agir d'archives / fichiers compressés, ni d'indirection pour permettre le déplacement des éléments sans recompilation / mise à jour des références d'origine. En effet, ce dernier peut introduire plus de problèmes qu'il n'en résout, vous ne le feriez donc que s'il répondait à un besoin particulier que vous aviez.

Le grand avantage des manifestes est qu'ils agissent comme un index d'une grande quantité de données dans un seul endroit compact. En tant que tels, ils améliorent les performances (car vous pouvez simplement charger le manifeste entier à partir du disque et le conserver en mémoire), en particulier dans le cas où vous devez parcourir plusieurs objets, mais vous ne savez pas à l'avance quels seront ces objets . Si les objets sont sur le disque, en particulier s'ils se trouvent à plusieurs endroits, vous devez toucher le système de fichiers chaque fois que vous souhaitez parcourir les fichiers. Pour les systèmes de fichiers sur disque, le temps nécessaire pour toucher le système de fichiers est prohibitif, donc itérer sur les fichiers d'un répertoire est un coût énorme. En pré-construisant un manifeste de fichiers au moment de la construction (NB: pas de temps de compilation), vous échangez ce coût pour l'utilisation de la mémoire.

Les fichiers d'archive nécessitent l'utilisation de manifestes, simplement parce que la table des matières de l'archive est essentiellement un manifeste lui-même, vous obtenez donc le comportement gratuitement. Et si vous devez utiliser des manifestes pour les actifs en un seul endroit, il peut être plus simple d'insister pour que tous les actifs soient référencés via les manifestes; vous permettant d'abstraire l'emplacement / le mécanisme de stockage réel des actifs des références à ces actifs dans le code. De cette façon, vous pouvez avoir un seul type de référence d'actif dans votre code et ne pas avoir à faire de distinction entre les chemins de fichier, le chemin du fichier d'archive + décalage ou les sous-actifs.

En plus des autres réponses, cela rend également votre code un peu plus séparé de vos actifs. Vous pouvez, par exemple, permettre à un artiste de travailler directement avec les fichiers manifestes sans avoir à faire effectuer une modification par un programmeur et une nouvelle construction. Tout ce qu'il faudrait, c'est changer le fichier manifeste pour pointer vers une nouvelle image et simplement relancer le jeu.

Les fichiers manifestes fournissent une couche d'indirection entre le nom de la ressource et son emplacement. Après des couches supplémentaires d'indirection, ce n'est qu'un signe de sur-conception. Cependant, parfois, cette couche supplémentaire est juste ce qui est nécessaire pour construire une solution élégante et efficace.

Voici un exemple concret simple où la séparation nom / emplacement de la ressource m'a aidé. Pendant le développement, mes ressources artistiques sont sous contrôle de révision avec le code source. C'est très pratique et me permet d'itérer rapidement. Habituellement, le nom de la ressource reflète son emplacement. Le manifeste de développement est très simple.

Je ne veux pas distribuer un jeu avec les actifs dispersés. Ainsi, lorsque je suis prêt à le distribuer, je peux facilement compresser mes actifs dans un fichier de ressources et créer un nouveau manifeste.

Les atlas de texture sont également un excellent moyen d'extraire un peu plus de performances du système graphique. Les atlas sont rapides mais ils sont difficiles à travailler pendant que l'art est encore en développement. Ma solution est de ne construire l'atlas à la fin que lorsque j'optimise le jeu. Puisque j'utilise des manifestes, tout ce que je dois faire est de mettre à jour le manifeste pour pointer vers un emplacement d'atlas et voilà, le jeu utilise maintenant des atlas au lieu de fichiers simples.