¿Por qué usar files de manifiesto de activos?

A veces verá que la gente lo recomienda en lugar de usar files de charts / sonido / etc. Me gusta esto…

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

… debería usar un file de manifiesto como un nivel de indirección en su lugar:

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

¿Qué razones tendría para tomar este tipo de enfoque? Si no estoy usando un lenguaje comstackdo, ¿habría razones para hacerlo?

La mayoría de las veces, los files de manifiesto están asociados con algún tipo de formatting de file. Por ejemplo, un file JAR en Java es simplemente un file zip con un file de manifiesto que enumera los activos dentro del file comprimido y dónde encontrarlos. En ese caso, "path / to / image.png" no es una ruta real del sistema de files, sino información sobre cómo encontrar el object dentro de un file comprimido. Además de la ventaja del espacio de disco de la compression, el uso de un file de files puede mejorar el performance porque Windows tiene un momento muy difícil para manejar decenas de miles de files individuales en una pequeña cantidad de directorys.

Al usar un file de manifiesto de este tipo, puede abstraer por completo de dónde proviene un fragment dado de datos. Tal vez su file esté en un DVD, o transmitido a través de Internet, o dentro de un file comprimido. Tendrá que escribir un código adicional para tratar estos casos, pero al usar un file de manifiesto, su lógica de juego no tiene que importar en absoluto de dónde se carga algo.

Ahora, si está utilizando un lenguaje no comstackdo, este file de manifiesto podría ser un file fuente de C #, pero es agradable si puede modificar fácilmente qué file de manifiesto está utilizando en el momento de ejecución del cliente según una configuration de logging o algo similar. Por ejemplo, puede verificar durante la ejecución si existe una caching en la unidad de disco duro o si solo está disponible el DVD. Luego, puede cambiar qué manifiesto usar dependiendo de la configuration disponible.

Una razón: progtwigción impulsada por datos.

Es posible que su código solo desee saber que necesita una textura "LightWood" y permita que el administrador de resources use esta key para encontrar la ruta correcta al file. Aún más, en las secuencias de commands, las personas no quieren recordar las routes de files. Están desorderados, pueden ser incorrectos. Deje que el manifiesto funcione donde está el file, y permita que el ser humano sepa qué material necesita por su nombre, no por el nombre del file.

 <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> 

Como patrón de layout general, los manifiestos son útiles cuando desea recostackr toda la información sobre un set dispar de objects en un solo lugar. No tiene que ser sobre files / files empaquetados, o sobre indirección para permitir que las cosas se muevan sin recomstackr / actualizar references originales. De hecho, este último puede presentar más problemas de los que resuelve, por lo que solo lo haría si resolvía una necesidad particular que tenía.

La gran ventaja de los manifiestos es que actúan como un índice para una gran cantidad de datos en un solo lugar compacto. Como tales, mejoran el performance (porque simplemente puede cargar todo el manifiesto del disco y mantenerlo en la memory), especialmente en el caso donde necesite iterar sobre múltiples objects, pero no sabe de antemano cuáles serán esos objects . Si los objects están en el disco, especialmente si están en varios lugares, debe tocar el sistema de files cada vez que quiera iterar sobre los files. Para los filesystems basados ​​en discos, el time necesario para tocar el sistema de files es prohibitivo, por lo que iterar sobre los files en un directory es un costo enorme. Al prebuild un manifiesto de files en time de compilation (NB: no time de compilation), cambia ese costo por el uso de memory.

Los files de almacenamiento requieren el uso de manifiestos, simplemente porque la tabla de contenido del file es esencialmente un manifiesto en sí, para que pueda get el comportamiento de forma gratuita. Y si se requiere que use manifiestos para activos en un solo lugar, puede ser más limpio insistir en que todos los activos se mencionen a través de manifiestos; permitiéndole abstraer la location / mecanismo real de almacenamiento de los activos de las references a esos activos en código. De esta forma, puede tener un único tipo de reference de activo en su código, y no tener que hacer la distinción entre las routes de files, la ruta del file comprimido + desplazamiento o los subetatos.

Además de las otras respuestas, también hace que su código esté un poco más separado de sus activos. Podría, por ejemplo, permitir que un artista trabaje directamente con los files de manifiesto sin tener que hacer que un progtwigdor realice el cambio y cree una nueva compilation. Todo lo que se necesitaría es cambiar el file de manifiesto para apuntar a una nueva image y simplemente ejecutar el juego nuevamente.

Los files de manifiesto proporcionan una capa de direccionamiento indirecto entre el nombre del recurso y su location. Ofter capas adicionales de indirección es solo un signo de exceso de layout. Sin embargo, a veces esa capa adicional es solo lo que se necesita para build una solución elegante y eficiente.

Aquí hay un ejemplo concreto simple en el que la separación de nombre de recurso / location me ayudó. Durante el desarrollo, mis resources artísticos están en control de revisión con el código fuente. Es muy conveniente y me permite iterar rápidamente. Por lo general, el nombre del recurso refleja su location. El manifiesto de desarrollo es muy directo.

No quiero distribuir un juego con los activos dispersos. Entonces, cuando esté listo para distribuirlo, puedo comprimir fácilmente mis activos en un file de resources y crear un nuevo manifiesto.

Además, los atlas de textura son una excelente forma de sacar un poco más performance del sistema de charts. Los atlas son rápidos pero son un dolor para trabajar mientras el arte aún está en desarrollo. Mi solución es build el atlas al final cuando estoy optimizando el juego. Dado que estoy usando manifiestos, todo lo que necesito hacer es actualizar el manifiesto para apuntar a una location de atlas y listo, el juego ahora está usando atlas en lugar de files rectos.