¿Cuál es el mejor enfoque para diseñar un AssestManager que contenga referencias a gráficos, sonidos, etc. de un juego?
¿Deberían almacenarse estos activos en un par de mapa clave / valor? Es decir, solicito un activo de "fondo" y el mapa devuelve el mapa de bits asociado ¿Hay una forma aún mejor?
Específicamente, estoy escribiendo un juego para Android / Java, pero las respuestas pueden ser genéricas.
Respuestas:
Depende del alcance de tu juego. Un administrador de activos es absolutamente esencial para títulos más grandes, menos para juegos más pequeños.
Para títulos más grandes, debe gestionar problemas como los siguientes:
Para títulos más pequeños, estas cosas son menos problemáticas, los marcos como XNA tienen administradores de activos dentro de ellos; no tiene mucho sentido reinventarlo.
Si necesita un administrador de activos, no existe una solución única para todos, pero he encontrado un mapa de hash con la clave como hash * del nombre de archivo (se bajan y los separadores están 'arreglados') funciona bien para los proyectos en los que he trabajado.
Por lo general, no es aconsejable codificar los nombres de archivo en su aplicación, por lo general es mejor tener otro formato de datos (como xml) que represente los nombres de archivo en 'ID'.
(Intentando evitar la discusión "no usar un administrador de activos" aquí, ya que lo considero fuera de tema).
Un mapa clave / valor es un enfoque muy útil.
Tenemos una implementación de ResourceManager donde las fábricas para diferentes tipos de recursos pueden registrarse.
El método "getResource" usa plantillas para encontrar la Fábrica correcta para el tipo de recurso deseado y devuelve un ResourceHandle específico (nuevamente usando la plantilla para devolver un SpecificResourceHandle).
ResourceManager vuelve a contar los recursos (dentro de ResourceHandle) y los libera cuando ya no los necesita.
El primer complemento que escribimos fue el método "reload (XYZ)", que nos permite cambiar los recursos desde fuera del motor en ejecución sin cambiar ningún código o recargar el juego. (Esto es esencial cuando los artistas trabajan en consolas;))
La mayoría de las veces solo tenemos una instancia del ResourceManager, pero a veces creamos una nueva instancia solo para un nivel o un mapa. De esta manera podemos simplemente llamar "apagado" en el levelResourceManager y asegurarnos de que nada se filtre.
// very abbreviated!
// this code would never survive our coding guidelines ;)
ResourceManager* pRm = new ResourceManager;
pRm->initialize( );
pRm->registerFactory( new TextureFactory );
// [...]
TextureHandle tex = pRm->getResource<Texture>( "test.otx" ); // in real code we use some macro magic here to use CRCs for filenames
tex->storeToHardware( 0 ); // channel 0
pRm->releaseResource( pRm );
// [...]
pRm->shutdown(); // will log any leaked resourceLas clases dedicadas de Gerente casi nunca son la herramienta de ingeniería adecuada. Si solo necesita el activo una vez (como un fondo o mapa), solo debe solicitarlo una vez y dejar que muera normalmente cuando haya terminado con él. Si necesita almacenar en caché un tipo particular de objeto, debe usar una fábrica que primero verifica un caché y, de lo contrario, carga algo, lo coloca en el caché y luego lo devuelve, y esa fábrica puede ser una función estática que accede a una variable estática , no un tipo propio.
Steve Yegge (entre muchos, muchos otros) ha escrito una buena historia sobre cómo las clases de manager inútiles, a través del patrón singleton, terminan siendo http://sites.google.com/site/steveyegge2/singleton-considered-stupid
Siempre he pensado que un buen administrador de activos debería tener varios modos de operación. Es muy probable que estos modos sean módulos fuente separados que se adhieran a una interfaz común. Los dos modos básicos de operación serían:
Necesitaría una herramienta que pueda tomar todas las evaluaciones de la base de datos compartida y crear el conjunto de datos de producción.
En mis años como desarrollador, nunca he visto algo así, aunque solo he trabajado para un puñado de empresas, por lo que mi punto de vista no es realmente representativo.
Actualizar
OK, algunos votos negativos. Ampliaré este diseño.
En primer lugar, realmente no necesitas clases de fábrica porque si tienes:
TextureHandle tex = pRm->getResource<Texture>( "test.otx" );sabes el tipo, así que solo hazlo:
TextureHandle tex = new TextureHandle ("test.otx");pero luego, lo que estaba tratando de decir anteriormente es que no usarías nombres de archivo explícitos de todos modos, la textura para cargar estaría especificada por el modelo en el que se usa la textura, por lo que no necesitas un nombre legible por humanos, podría ser un valor entero de 32 bits, que es mucho más fácil de manejar para la CPU. Entonces, en el constructor de TextureHandle tendrías:
if (texture already loaded)
update texture reference count
else
asset_stream = new AssetStream (resource_id)
asset_stream->ReadBytes
create texture
set texture ref count to 1AssetStream usa el parámetro resource_id para encontrar la ubicación de los datos. La forma en que lo hizo dependería del entorno en el que se esté ejecutando:
En Desarrollo: la secuencia busca la ID en una base de datos (usando SQL, por ejemplo) para obtener un nombre de archivo y luego abre el archivo, el archivo podría almacenarse en caché localmente o extraerse de un servidor si el archivo local no existe o es fuera de plazo.
En la versión: la secuencia busca la ID en una tabla de clave / valor para obtener un desplazamiento / tamaño en un archivo grande y empaquetado (como el archivo WAD de Doom).
Lo que me gusta hacer por los activos es configurar un administrador global . Inspirados en el motor Doom, los grumos son datos que contienen activos, almacenados en un archivo de grumos que declara los nombres, las longitudes, el tipo (mapa de bits, sonido, sombreador, etc.) y el tipo de contenido (archivo, otro bulto, dentro el archivo global). Al inicio, estos grumos se ingresan en un árbol binario, pero aún no se cargan. Cada mapa (que también es un bulto) tiene una lista de dependencias, que son simplemente los nombres de grumos que el mapa necesita para funcionar. Estos grumos, a menos que ya se hayan cargado, se cargan en el momento en que se carga el mapa. Además, los bultos de los mapas contiguos del mapa se cargan, no solo al mismo tiempo, sino cuando el motor está inactivo por algún motivo. Esto puede hacer que los mapas sean fluidos, y no hay pantalla de carga.
Mi método es perfecto para mapas de mundo abierto, pero un juego basado en niveles no se beneficiará de la fluidez de este método. ¡Espero que esto ayude!