El blog Juegos de Dentro de Noel Llopis tocó esto recientemente en la publicación "Edición remota de juegos" . El primer párrafo:
Durante mucho tiempo he sido fanático de los tiempos de ejecución mínimos del juego. Cualquier cosa que se pueda hacer sin conexión o en una herramienta separada, debe estar fuera del tiempo de ejecución. Eso deja la arquitectura y el código del juego muy delgados y simples .
(El artículo es una lectura muy recomendable, como con la mayoría de las cosas de Noel, si estás de acuerdo al 100% o no).
Creo que la clave aquí es mantener la complejidad fuera del motor. Todavía puede tener flexibilidad, pero es flexibilidad en la canalización de contenido. Y obtiene un mejor rendimiento al no perder tiempo convirtiendo y moviendo datos.
Curiosamente, un mejor rendimiento puede traducirse en un menor tiempo de iteración, a pesar de perder algunas de las habilidades de edición en el motor: es más fácil probar algo si puedes cargar el juego en un segundo.
Adoptar algunos de los principios de la " filosofía de Unix " lo ayudará a mantener flexible su cadena de herramientas: una pequeña tubería modular.
Mi filosofía personal: hornear la mayor cantidad de datos posible fuera de línea, pero proporcionar soporte del motor para recibir nuevos datos horneados en cualquier momento. (Tenga en cuenta que esta nueva información no necesita entrar en juego hasta un punto conveniente: se presiona el botón "actualizar", comienza el siguiente nivel, se pasa a una nueva área, lo que sea. La clave es encontrar el punto óptimo que minimice tiempo de iteración con mínima complejidad de código y esfuerzo de codificación).
En nuestra empresa, la mayoría de nuestras herramientas para artistas / diseñadores se centran en problemas de interfaz de usuario: facilidad de manipulación de activos individuales o lotes de los mismos, etc. A veces son solo herramientas de terceros como Photoshop o 3DS Max. Estas herramientas se exportan a un formato intermedio (a menudo xml que hace referencia a datos binarios de origen, pero no siempre). El formato intermedio es recogido por una herramienta de "creación de datos" de back-end, que lo convierte en algo útil y de carga rápida para la plataforma de destino.
La portabilidad se logra al agregar herramientas de creación de datos de back-end adicionales o al expandir las herramientas de creación de datos de back-end existentes, lo que tiene la ventaja adicional de ser invisible para los creadores de contenido.
Ahora, con una marca de datos incremental adecuada, puede tener cambios en el formato horneado en segundos; su motor puede ser araña, o una herramienta puede ser araña, y luego aparecerán en su sistema de recursos, listos para recargar cuando sea conveniente.
Las herramientas, especialmente las herramientas de creación de datos de back-end, son a menudo más descuidadas y con errores que el código del motor. Esto está bien, porque son más fáciles de refactorizar / reescribir, extender y probar; tienes especificaciones para su comportamiento y es bastante fácil probarlas en comparación con algún código de motor.
Mis opiniones sobre tus preguntas:
¿Debería el motor ser capaz de cargar varios formatos de imagen? Un cargador solo TGA es bastante fácil de manejar.
(Aparte: incluso si usa un decodificador TGA en el motor, no lo codifique a mano. Solo está buscando problemas: hay muchas sutilezas con la mayoría de los formatos de imagen y muchas herramientas que no se adhieren exactamente al formato probablemente poco especificado. Es mejor que encuentre el código de biblioteca bien probado para el procesamiento de imágenes).
Aquí la herramienta convertiría de TGA a cualquier formato de textura interna, más metadatos.
¿Qué pasa con los formatos de audio? ¿Es factible solo admitir la carga de archivos wav? ¿Qué pasa con los archivos de música ambiental que a menudo son enormes?
Aquí utilizamos tres formatos: música rastreada (.xm), ADPCM (.wav) y Speex (.spx). Esto se debe principalmente a que estamos en dispositivos portátiles, y estos formatos son muy livianos para decodificar.
¿Debería ser capaz el motor de análisis dinámico TTF y generación de atlas? Embalaje de textura.
El atlas es un problema difícil: vea las respuestas de su pregunta reciente . Casi siempre vale la pena hacerlo sin conexión.
Además, puede convertir los metadatos por carácter en una estructura horneada de código de carga casi cero.
Para terminar, puedes limpiar y empaquetar esta tubería con tu juego, para la comunidad mod. Siempre puede agregar más formatos de origen. Y no hay nada que le impida cerrar la brecha entre las herramientas de creación de contenido y el motor en casos específicos; es de esperar que su código de horneado de datos y el código de araña / transferencia puedan ser refactorizados en bibliotecas que eventualmente podrían ser utilizadas directamente por las herramientas de creación de contenido en algunos casos. Pero no lo convertiría en mi primer objetivo, necesariamente ... Solo tenga en cuenta que será un objetivo eventual y deje que eso influya un poco en su diseño, y vaya primero por la fruta baja.
Como actualización, puede considerar usar el formato de archivo KTX para texturas. Tiene la ventaja de ser principalmente "leído structy listo" para la mayoría de los casos de uso de GL (y de sus comentarios parece que estaba apuntando a GL) sin dejar de ser flexible y bien definido.
La sobrecarga del encabezado KTX puede ser un poco alta para los datos totalmente horneados, dependiendo de su objetivo, y es posible que desee renunciar al soporte de intercambio endian, dependiendo de su caso de uso ... pero definitivamente vale la pena considerar las consideraciones de diseño.