¿Las herramientas de canalización de contenido deberían estar integradas en el motor?

10

¿Qué tan mínimo debe ser un motor de juegos? ¿Cuánto de la canalización de contenido debe incrustarse en el motor?

Algunos casos de uso donde el súper motor podría ser útil:

  • Al cargar el contenido del usuario, el usuario no está obligado a empaquetar sus texturas, el motor lo hará en el momento de la carga.

  • Un script solicita una fuente de un tamaño mucho mayor que el que se generó previamente, el motor podría analizar el archivo ttf y crear un nuevo atlas de texturas.

  • Halo forge .

Nada de esto es gratis, por supuesto. Esto requiere que sus herramientas de canalización de contenido estén escritas en C ++. Las bibliotecas de soporte que usa en la tubería deben compilarse para su uso en el dispositivo. Requiere que la generación de contenido no tenga errores. Y generalmente hace que su motor sea más grande y difícil de manejar.
¿Cuáles son algunos otros pros y contras?
¿Los profesionales superan a los contras?

Algunas preguntas específicas:

  • ¿Debería el motor ser capaz de cargar varios formatos de imagen? Un cargador solo TGA es bastante fácil de manejar.

  • ¿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?

  • ¿Debería ser capaz el motor de análisis dinámico TTF y generación de atlas?

  • Embalaje de textura.

código_deft
fuente

Respuestas:

11

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.

leander
fuente
Grandes cosas gracias. Nunca había considerado construir mi propio formato de imagen fácil de cargar. ¿Existe una biblioteca de carga de textura mínima ya construida? Por otra parte, es básicamente una secuencia de bytes con un ancho, alto y codificación (es decir, GL_RGB555).
deft_code el
1
No cree tanto su propio formato de imagen como obtenga la imagen en el formato exacto que DirectX, GL o lo que sea que esté usando desee. =) En cuanto a las bibliotecas: hay un montón por ahí. Para las herramientas, tiendo a usar solo las cosas de la biblioteca ImageMagick ( imagemagick.org/script/index.php ) o incluso los programas ... El código de ImageMagick es de la vieja escuela y un poco feo, pero bastante rápido, flexible y sencillo. -probado. Estoy seguro de que otros tendrán muchas otras sugerencias; si está utilizando, por ejemplo, C # para su cadena de herramientas, muchas de estas cosas ya estarán integradas en las
bibliotecas de
1
"Estoy seguro de que otros tendrán muchas otras sugerencias" ¡MFC! :) O tal vez OpenIL. Creo que uno de los puntos importantes sobre cómo hornear activos en formatos específicos de plataforma es que a medida que agrega más formatos de origen y más plataformas, la cantidad de combinaciones explotará. La conversión de los activos de origen en un formato intermedio y luego la conversión en formatos específicos de la plataforma reducirá la cantidad de rutas de conversión. Agregue otro formato fuente, simplemente escriba un convertidor al formato intermedio. Agregue otra plataforma, agregue un panadero al formato de destino de esa plataforma.
Chris Howe
1
Agregaría que mantener la complejidad fuera del motor no necesariamente significa que la funcionalidad no esté disponible para el motor. Sin embargo, mantenerlo separado para que se separe fácilmente del motor es clave. No puedo enfatizar lo suficiente lo útil que es soportar la carga en caliente de activos, es decir, recargar cosas sobre la marcha. Sin embargo, esto también puede aportar mucha complejidad a su sistema, por lo que querrá asegurarse de que esté construido de tal manera que el juego no necesite preocuparse de dónde provienen los activos.
dash-tom-bang
3

Sus preguntas suenan muy subjetivas y dependen en gran medida de quién es su público objetivo.

Tomemos su pregunta de análisis de fuente / ttf. Si está planeando que los modders agreguen su propia fuente, entonces probablemente desee hacer que el proceso de importación tenga la menor cantidad de pasos posible. Si está agregando muchas fuentes / tamaños de fuente al juego internamente, tal vez desee una herramienta algo sofisticada que un artista pueda usar con un poco de entrenamiento. Si lo va a hacer una vez internamente, entonces el tiempo que dedica a hacer un importador adecuado probablemente será menor que tomarse el tiempo para escribir herramientas para los casos anteriores.

Es realmente una cuestión de escala con todo lo demás. Las herramientas integradas valen la pena cuando estás haciendo algo muchas veces y quieres reducir la complejidad / errores que resultan de ello. Cada calificador adicional que agregue (es decir, texturas TGA solo en lugar de importar, por ejemplo, PSD) genera más tiempo para el usuario final.

Recuerde que las herramientas de contenido suelen ser utilizadas por personas con menos inclinación técnica (léase: artistas) Personalmente, me gusta mucho la forma en que funciona Unity, donde puedes arrastrar un archivo fuente (psd, 3ds, ttf, mp3, jpg, mov, lo que sea) y lo convertirá automáticamente a su formato interno. El formato interno está mayormente oculto para el usuario final. También se convertirá automáticamente cuando detecte el cambio del archivo fuente. Pero eso es mucho trabajo.

Tétrada
fuente