Cómo crear escenas y prefabricados con un enfoque en el control de versiones
El objetivo de esta guía es proporcionar las mejores prácticas para crear contenido en Unity que funcione con control de versiones. Para obtener más información sobre el uso del control de versiones, consulte el blog Take on version control for strengthed collaborative de Unity o el libro electrónico Best practices for version control más detallado. Si bien ambos recursos contienen buena información general para trabajar con el control de versiones, el foco de este blog está en cómo se integra el contenido con el control de versiones y cómo evitar conflictos de fusión cuando muchos creadores trabajan en el mismo contenido o en contenido adyacente al mismo tiempo.
Hay mucha confusión en línea acerca de los archivos .meta y el control de versiones. Los archivos .meta siempre deben incluirse en el control de versiones. Contienen información importante, como el GUID del archivo que conecta todas las referencias entre activos. Deben mantenerse sincronizados con sus archivos de origen (tanto el nombre como la ubicación deben coincidir siempre con el archivo de origen asociado). Nunca mueva ni cambie el nombre de un archivo de activo fuera del Editor de Unity a menos que se hayan creado herramientas específicas para este propósito o se comprenda completamente la funcionalidad de los archivos .meta.
El modo de archivo .meta de control de versiones predeterminado es Archivos visibles, que muestra los archivos .meta en el disco en el sistema operativo, en lugar de ocultarlos. Si está utilizando Perforce, seleccione el modo Perforce.
Lo primero que debe hacer cualquier equipo cuando trabaja con Unity y control de versiones es configurar Smart Merge. De forma predeterminada, Unity almacena los archivos YAML como texto, lo que hace que puedan fusionarse en el control de versiones. Cambiar el modo de serialización de activos a binario eliminará la capacidad de fusionar estos archivos mediante el control de versiones.
Debido a que los archivos YAML de Unity están basados en texto, muchos programas de fusión de control de versiones intentarán fusionarlos utilizando texto o reglas de codificación. Smart Merge fue desarrollado por Unity para fusionarse teniendo en cuenta la estructura YAML. Recomendamos imponer el uso de Smart Merge como la herramienta de fusión predeterminada para todos los archivos YAML.
Smart Merge reducirá en gran medida la cantidad de trabajo perdido debido a conflictos de fusión, pero si su equipo tiene tolerancia cero ante posibles pérdidas de trabajo, también recomendamos utilizar el bloqueo de archivos y aplicar la resolución manual de conflictos de fusión para cualquier archivo YAML.
El bloqueo de archivos es una práctica común en estudios grandes donde varios creadores de contenido pueden trabajar en el mismo archivo binario (o archivo YAML) al mismo tiempo. El control de versiones de Unity evita que cualquiera pueda extraer un archivo bloqueado. Perforce impide que cualquier persona envíe un archivo bloqueado.
Git requiere que Git LFS se inicialice para admitir el bloqueo de archivos. Recomendamos utilizar Git LFS para cualquier proyecto que tenga archivos de contenido grandes y utilice Git para el control de versiones.
Los equipos exitosos a menudo tienen pautas estrictas con respecto a las convenciones de nomenclatura, las estructuras de carpetas, dónde deben ubicarse los activos y cómo deben editarse los activos. Como cada equipo es diferente, no existe un conjunto de pautas universales. Elegir el sistema adecuado para su equipo y mantenerlo mientras funcione es lo más importante.
Unas directrices específicas y estrictas hacen que el desarrollo de herramientas para verificar contenido sea más sencillo. Esto evita errores incluso antes de que entren en el juego. Validar contenido con código y herramientas se vuelve mucho más fácil cuando hay claridad en la ubicación y el nombre de los activos. Luego, puede aplicar más fácilmente los estándares de importación de Unity a través del posprocesamiento de activos y los ajustes preestablecidos.
Al crear contenido, es importante utilizar los principios de separación de preocupaciones . Pensar en cómo se debe dividir el contenido y dónde debe ubicarse mantendrá el proyecto limpio y evitará que la mayoría de los creadores de contenido se encuentren con conflictos de fusión. También puede ayudar con la capacidad de descubrimiento y la incorporación de expertos en funciones, donde las funciones individuales residen en subescenas o prefabricados específicos. Los principales bloques de construcción que se pueden utilizar para separar el contenido en archivos son Escenas, Prefabricadosy Subgráficos.
Las escenas son los bloques de construcción macro para cualquier aplicación de Unity. Cada escena se serializa (guarda) en un archivo, lo que significa que se pueden usar para organizar el contenido de una manera que sea amigable para el control de origen y la edición simultánea. La carga de escena aditiva se utiliza a menudo de manera eficaz para crear escenas muy grandes, contenido en streaming o incluso escenas muy simples que tienen múltiples componentes con intereses separados.
En general, recomendamos almacenar datos dependientes de la escena en escenas. Por ejemplo, en el caso de la iluminación horneada, las luces, los mapas de luz y las configuraciones del entorno, todos dependen de la escena en la que se encuentran. Casi todo lo demás se puede almacenar en Prefabs. Si una escena es pequeña y tiene contenido específico que solo se editará dentro de esa escena, podría tener sentido almacenar todos esos datos en una sola escena. Sin embargo, es importante tener en cuenta que si hay dos GameObjects en una escena, cualquier cambio en uno de esos objetos resultará en cambios en el archivo de escena.
Si bien Smart Merge debería manejar el escenario en el que dos creadores de contenido cambian dos objetos diferentes en la escena al mismo tiempo, cambios más elaborados pueden generar conflictos irresolubles. Recomendamos utilizar Prefabs para ayudar a mitigar este problema.
En términos de estructura de escena explícita, la demostración de Unity Netcode contiene un diagrama de flujo útil de un diseño de escena estándar para un proyecto simple que es similar a los que hemos visto en muchos escenarios.
Los prefabricados se pueden utilizar para crear contenido modular e independiente. Para obtener más información, consulte este tutorial sobre prefabricados y prefabricados anidados. La sección más importante de ese tutorial es la sección Mejores prácticas . No existen reglas explícitas sobre la creación de contenido con Prefabs. Cada equipo tendrá que decidir qué funciona mejor para ellos en función de su proyecto. Sin embargo, hay algunas buenas pautas a seguir:
- Piense en los prefabricados como los bloques de construcción de su casa o proyecto. Generalmente hay un Prefab raíz que representa la base de la casa. Dentro de esto se encuentran los Prefabs para cada componente reutilizable que compone el resto de la casa. Podrían ser tan granulares como el alféizar de una ventana o tan anchos como una pared con ventanas. El nivel de granularidad necesario dependerá de cómo los creadores de contenido quieran editar sus Prefabs.
- Los prefabricados se pueden anidar. Esto significa que en el ejemplo anterior, podría haber una casa prefabricada, con paredes, techo, ventanas y puertas prefabricadas que componen la casa. Una cosa importante a tener en cuenta con la anidación de Prefabs es que cuanto más profunda sea la jerarquía, más probable será que el proyecto encuentre problemas de rendimiento. Generalmente recomendamos mantener las jerarquías Prefab por debajo de 5-7 niveles de profundidad.
- Al anidar Prefabs, generalmente es una buena idea editarlos en Modo Prefab. Esto garantiza que las propiedades o anulaciones de Prefab se configuren en la ubicación adecuada. La edición de propiedades de Prefab en la vista de escena puede generar anulaciones que residan en el Prefab incorrecto o en la escena misma. Esto puede tener consecuencias no deseadas y provocar conflictos de fusión. A veces, es necesario anular una propiedad Prefab secundaria en un Prefab principal (de esta manera se pueden lograr variaciones sin afectar cada referencia a un Prefab específico). Este es un flujo de trabajo estándar, pero es importante tener cuidado al realizar cambios y aplicar modificaciones en el prefabricado o la escena adecuados.
- Todo lo que hay en un Prefab se cargará y se instanciará en la memoria en tiempo de ejecución cuando se carga y se instancia un Prefab. Esto significa que si hay efectos visuales u objetos adjuntos que no siempre están presentes dentro de un Prefab, esos objetos se instanciarán en la memoria. Esto puede generar una sobrecarga de memoria, ya que cada Prefab instanciado instanciará todo lo que esté dentro de él. Si los objetos tienen efectos visuales o modelos ocasionales adjuntos, es mejor tener un sistema de agrupación y un administrador de archivos adjuntos que agregue esos componentes en tiempo de ejecución. Por lo general, nada de lo que forma parte de un sistema de agrupamiento debe colocarse dentro de un prefabricado.
- No todo tiene que ser prefabricado. Los bloques de construcción más pequeños pueden ser GameObjects dentro de un Prefab o incluso una escena. Si un objeto es exclusivo de una escena o Prefab, no es necesario crear un Prefab para él.
- Las variantes prefabricadas deben utilizarse con cuidado. Generalmente, el mejor uso de una variante Prefab es cuando los componentes básicos de un objeto son idénticos con solo diferencias simples. Por ejemplo, podría ser útil utilizar una variante Prefab para un componente de juego que tenga funcionalidades idénticas, pero elementos visuales diferentes. En este escenario, cambiar la funcionalidad principal afectará la funcionalidad tanto del Prefab como de sus variantes, pero el elemento visual permanecerá anulado. Tenga cuidado al crear variantes de Prefab demasiado complejas, ya que los cambios en el Prefab raíz podrían tener consecuencias no deseadas en el Prefab anulado. Como regla general, algo como un sistema de variación de personajes o cualquier otro sistema complejo de diseño visual no debería basarse en variantes prefabricadas a menos que el sistema sea muy simple.
Recomendamos crear una estrategia consistente para determinar qué deben ser Prefabs y qué deben ser GameObjects dentro de Prefabs o escenas.
Si se crea un Prefab directamente a partir de un archivo FBX, se crea un tipo especial de Prefab llamado Prefab modelo . El resultado es una variante Prefab del archivo FBX. Cualquier adición o cambio se almacenará como anulación en el archivo Prefab. Sin embargo, debido a que la mayoría de los datos se almacenan en el archivo FBX, los cambios y las adiciones al Prefab no se pueden aplicar a los Prefabs del modelo. Si está utilizando el flujo de trabajo de la variante Prefab del modelo, es importante mantener los cambios estructurales al mínimo.
Hay dos flujos de trabajo alternativos que permiten estructuras menos acopladas entre el modelo FBX y el Prefab:
Agregar el archivo FBX directamente a una escena y luego agregar componentes o modificaciones estructurales a GameObjects en la escena. En este escenario, todos los cambios ahora se almacenan en el archivo de escena. Esto puede generar conflictos de fusión si muchas personas utilizan este flujo de trabajo en la misma escena. Solo recomendamos este flujo de trabajo si los cambios deben existir en la escena y los conflictos no son un problema.
Creación de un prefabricado de Unity estándar a partir del modelo explotado. En este método, el modelo FBX se arrastra a la escena y luego se descomprime por completo. Esto luego se usa para crear un Prefab. Esta metodología desacopla completamente el archivo FBX del Prefab. Esto es útil si se desea un acoplamiento muy flexible entre el archivo FBX y el Prefab. Ya no heredará ningún cambio estructural realizado en el archivo FBX original. El acoplamiento solo será entre los nombres de las mallas, materiales y animaciones. Todo lo demás residirá en el propio archivo Prefab. Esto puede ser útil para crear variantes completamente únicas de un modelo FBX. Por ejemplo, si dos personajes usan el mismo modelo, pero necesitan mallas, materiales o incluso jerarquías completamente diferentes, esta metodología puede ser mejor que crear múltiples archivos FBX que ocupan memoria y espacio en disco adicionales. Una cosa a tener en cuenta con este método es que cuando el nombre de una malla o material cambia en el archivo FBX original, el objeto no desaparece, sino que hace referencia a una malla o material faltante. Esto puede ser útil cuando se requieren configuraciones de componentes extremadamente complejas. En lugar de que el GameObject desaparezca y pierda todos los componentes, el objeto permanece y los componentes se pueden transferir al nuevo objeto, o la malla o el material renombrado se pueden volver a colocar en el GameObject que ahora hace referencia a una malla o material faltante.
En las dos imágenes a continuación, se realizan cambios en un archivo FBX y luego se vuelven a importar. Se elimina el círculo alrededor del logotipo de Unity en la pelota. Se cambia el nombre del soporte principal. El material de la bola principal se cambia de negro a verde y se introduce un nuevo padre sobre el logotipo del stand con transformaciones que lo elevan por encima del modelo.
Todo esto coincide estrechamente tanto en el archivo FBX como en el modelo Prefab. En el Prefab sin modelo, se conservan la jerarquía, los nombres y los materiales originales. La malla eliminada ahora es una malla faltante, pero el GameObject todavía está presente. La malla renombrada tampoco es visible porque hace referencia a un nombre de malla que ya no existe en el modelo. El material modificado no se actualiza porque GameObject todavía hace referencia al material original. Además, el cambio de jerarquía no se respeta y la malla permanece en el mismo lugar porque su padre no ha cambiado.
En las imágenes de antes y después que aparecen a continuación, se muestran los resultados de los cambios realizados anteriormente en la jerarquía de la escena. El archivo FBX al que se hace referencia directamente en la escena y el modelo estándar Prefab responden a cualquier cambio realizado en el archivo FBX original. El Prefab descomprimido conserva su jerarquía original y no responde a eliminaciones ni cambios de nombre.
Es importante tomar decisiones cuidadosas sobre qué metodología se utiliza en un escenario determinado. Si se desea un acoplamiento estrecho entre el Editor y los archivos FBX, entonces el modelo estándar Prefab es probablemente la mejor opción. Si se desea un acoplamiento muy flexible (por ejemplo, un sistema de caracteres muy flexible donde las mallas o los materiales se pueden intercambiar con frecuencia), entonces funcionará mejor la creación de Prefabs que no sean modelos con referencias suaves a los componentes del archivo FBX.
En el caso de herramientas gráficas como Shader Graph o Visual Effect Graph, los subgráficos de Shader Graph y los subgráficos de Visual Effect Graph se pueden usar para crear nodos funcionales reutilizables que residen en un archivo separado y se pueden editar sin causar conflictos en cada Shader Graph o Visual Effect Graph. Esto permite a los usuarios separar las preocupaciones de manera similar a los prefabricados y las escenas. Recomendamos crear una estrategia de reutilización aprovechando los subgráficos donde tenga más sentido.
Evitar jerarquías profundas es una declaración universal para el contenido relacionado con escenas, prefabricados, GameObjects, animación, UI y cualquier otra cosa. En general, las jerarquías profundas de cualquier tipo tienden a generar problemas de rendimiento. Las jerarquías de animación profundas en los personajes darán como resultado que se puedan dibujar menos personajes en la pantalla debido a problemas de rendimiento de la CPU. Debido a esto, recomendamos colocar todas las jerarquías animadas en el nodo raíz de la escena para ayudar con el rendimiento. Optar por jerarquías planas al utilizar UGUI y Canvases dará como resultado un mejor rendimiento debido a menos actualizaciones de diseño en cascada. Los prefabricados profundamente anidados pueden causar problemas de rendimiento y también generar confusión cuando las anulaciones no se gestionan con cuidado.
A menudo vemos que los equipos almacenan contenido de origen en una variedad de ubicaciones, desde unidades de red hasta máquinas locales. Recomendamos poner todo el contenido fuente importante bajo control de versiones de una forma u otra.
El método más común que vemos es colocar el contenido de origen en una carpeta en el control de versiones que está fuera de la carpeta Activos. Esto garantiza que Unity no intente importar ningún contenido directamente de los archivos de origen. Los archivos de Maya, 3ds Max, Blender y Photoshop se importarán automáticamente en modelos y texturas si se colocan en cualquier lugar de la carpeta de activos. Si bien Unity admite esto, no recomendamos esta práctica. Además, recomendamos reflejar el directorio de origen en el contenido del directorio Activos para que el seguimiento de los activos sea relativamente fácil.
El contenido fuente debe ser enmascarable para los usuarios, ya que la mayoría de ellos no lo necesitarán todo y el contenido fuente puede ser extremadamente grande en el disco (piense en terabytes). En algunos programas de control de versiones, crear máscaras de contenido es bastante simple. En el control de versiones de Unity, esto se logra con archivos enmascarados. En Perforce, las vistas se utilizan para enmascarar el contenido del cliente. Sin embargo, Git no está diseñado para funcionar de esta manera. Por este motivo, recomendamos crear un repositorio Git separado para el contenido fuente o un repositorio separado para cada tipo de contenido (por ejemplo, es posible que los artistas 3D nunca necesiten sincronizar la fuente de audio completa y viceversa).
Crear contenido que funcione con control de versiones y admita múltiples usuarios que trabajan en las mismas áreas es una tarea difícil. Sin embargo, Unity proporciona bloques de construcción que pueden usarse con un pensamiento y una planificación cuidadosos para crear contenido a gran escala que no genere conflictos de fusión irresolubles ni pérdida de trabajo.