Mejores prácticas para organizar su proyecto de Unity

Aunque no hay una única forma de organizar un proyecto de Unity, aquí hay algunas recomendaciones clave:

• Documente sus convenciones de nomenclatura y estructura de carpetas. Una guía de estilo y/o plantilla de proyecto facilita la localización y organización de archivos. Elige lo que funcione para tu equipo y asegúrate de que todos estén de acuerdo con ello.
• Sé consistente con tus convenciones de nomenclatura. No te desvíes de tu guía de estilo o plantilla elegida. Si necesitas enmendar tus reglas de nomenclatura, analiza y renombra tus activos afectados de una vez. Si los cambios afectan a un gran número de archivos, considera automatizar la actualización usando un script.
• No uses espacios en los nombres de archivos y carpetas. Las herramientas de línea de comandos de Unity tienen problemas con los nombres de ruta que incluyen espacios. Usa CamelCase como alternativa a los espacios.
• Separa áreas de prueba o sandbox. Crea una carpeta separada para escenas no productivas y experimentación. Las subcarpetas con nombres de usuario pueden dividir tu área de trabajo por miembro del equipo.
• Evita carpetas adicionales en el nivel raíz. En general, almacena tus archivos de contenido dentro de la carpeta Assets. No crees carpetas adicionales en el nivel raíz del proyecto a menos que sea absolutamente necesario.
• Mantén tus activos internos separados de los de terceros. Si estás usando activos de la Asset Store u otros complementos, es probable que tengan su propia estructura de proyecto. Mantén tus propios activos separados.

Nota: Si te encuentras modificando un activo o complemento de terceros para tu proyecto, entonces el control de versiones puede ayudarte a obtener la última actualización del complemento. Una vez que la actualización se importe, puedes revisar el diff para ver dónde tus modificaciones podrían haber sido sobrescritas y reimplementarlas.

Aunque no hay una estructura de carpetas establecida, las siguientes dos secciones muestran ejemplos de cómo podrías configurar tu proyecto de Unity. Estas estructuras se basan en dividir tu proyecto por tipo de activo.

La Página del manual de Tipos de Activos describe los activos más comunes con mayor detalle. Puedes usar los proyectos de Plantilla o Aprendizaje para obtener más inspiración al organizar la estructura de tus carpetas. Aunque no estás limitado a estos nombres de carpetas, pueden proporcionarte un buen punto de partida.

Si descargas uno de los proyectos de Plantilla o de Inicio desde el Unity Hub, notarás que las subcarpetas están divididas por tipo de activo. Dependiendo de la plantilla elegida, deberías ver subcarpetas que representan varios activos comunes.

Definir una estructura de proyecto sólida desde el principio puede ayudarte a evitar problemas de control de versiones más adelante. Si mueves activos de una carpeta a otra, muchos VCS percibirán esto como simplemente eliminar un archivo y agregar otro, en lugar de que el archivo se haya movido. Esto pierde el historial del archivo original.

Plastic SCM puede manejar los movimientos de archivos dentro de Unity y preservar el historial de cualquier archivo que se haya movido. Sin embargo, es esencial que muevas archivos en el Editor para que el archivo .meta se mueva junto con el archivo de activo.

Una vez que hayas decidido sobre una estructura de carpetas para tus proyectos, usa un script de Editor para reutilizar la plantilla y crear la misma estructura de carpetas para todos los proyectos en el futuro. Cuando se coloca en una carpeta de Editor, el script a continuación creará una carpeta raíz en activos que coincida con la variable "NOMBRE_DEL_PROYECTO". Hacer esto mantiene tu propio trabajo separado de los paquetes de terceros.

Las carpetas vacías corren el riesgo de crear problemas en el control de versiones, así que intenta crear carpetas solo para lo que realmente necesitas. Con Git y Perforce, las carpetas vacías son ignoradas por defecto. Si se configuran tales carpetas de proyecto y alguien intenta confirmarlas, en realidad no funcionará hasta que se coloque algo en la carpeta.

Nota: Una solución común es colocar un archivo “.keep” dentro de una carpeta vacía. Esto es suficiente para que la carpeta sea luego confirmada en el repositorio.

Plastic SCM puede manejar carpetas vacías. Plastic SCM trata los directorios como entidades, cada uno con su propia historia de versiones adjunta.

Este es un punto a tener en cuenta al trabajar en Unity. Unity genera un archivo .meta para cada archivo en el proyecto, incluidas las carpetas. Con Git y Perforce, un usuario puede confirmar fácilmente el archivo .meta para una carpeta vacía, pero la carpeta en sí no estará bajo control de versiones. Cuando otro usuario obtiene los últimos cambios, habrá un archivo .meta para una carpeta que no existe en su máquina, y Unity luego eliminará el archivo .meta. Plastic SCM evita este problema por completo al incluir carpetas vacías bajo control de versiones.

Unity genera un archivo .meta para cada otro archivo dentro del proyecto, y aunque generalmente no se recomienda incluir archivos generados automáticamente en el control de versiones, el archivo .meta es un poco diferente. El modo de Archivos Meta Visibles debe estar activado en la ventana de Control de Versiones (a menos que estés usando los modos integrados de Plastic SCM o Perforce).

Aunque el archivo .meta es generado automáticamente, contiene mucha información sobre el archivo con el que está asociado. Esto es común para activos que tienen ajustes de importación, como texturas, mallas, clips de audio, etc. Cuando cambias los ajustes de importación en esos archivos, los cambios se escriben en el archivo .meta (en lugar del archivo del activo). Por eso confirmas los archivos .meta en tu repositorio, para que todos trabajen con los mismos ajustes de archivo.

Llegar a un acuerdo sobre estándares no se detiene en la estructura de carpetas del proyecto. Establecer un estándar de nomenclatura específico para todos tus activos de juego puede facilitar las cosas para tu equipo al trabajar en los archivos de los demás.

Aunque no hay un estándar de nomenclatura definitivo para los GameObjects, considera la tabla anterior.

Las escenas grandes y únicas de Unity no se prestan bien a la colaboración. Divide tus niveles en varias escenas más pequeñas para que los artistas y diseñadores puedan colaborar sin problemas en un solo nivel mientras minimizan el riesgo de conflictos.

En tiempo de ejecución, tu proyecto puede cargar escenas aditivamente usando SceneManager con LoadSceneAsync pasando el modo de parámetro LoadSceneMode.Additive.

Es una buena práctica dividir el trabajo en Prefabs siempre que sea posible y aprovechar el poder de los Prefabs anidados. Si necesitas hacer cambios más tarde, puedes cambiar el Prefab en lugar de la escena en la que se encuentra, para evitar conflictos con cualquier otra persona que esté trabajando en la escena. Los cambios en los Prefabs son a menudo más fáciles de leer al hacer un diff bajo control de versiones.

En caso de que termines con un conflicto de escena, Unity también tiene una herramienta YAML incorporada (un lenguaje de serialización de datos legible por humanos) utilizada para fusionar escenas y Prefabs. Para más información, consulta Fusión inteligente en la documentación de Unity.

Los ajustes preestablecidos te permiten personalizar el estado predeterminado de casi cualquier cosa en tu Inspector. Crear Ajustes preestablecidos te permite copiar la configuración de componentes o activos seleccionados, guardarlos como sus propios activos y luego aplicar esas mismas configuraciones a otros elementos más adelante.

Usa ajustes preestablecidos para hacer cumplir estándares o aplicar valores predeterminados razonables a nuevos activos. Pueden ayudar a garantizar estándares consistentes en tu equipo, para que configuraciones comúnmente pasadas por alto no impacten el rendimiento de tu proyecto.

Haz clic en el icono de ajuste preestablecido en la parte superior derecha del componente. Para guardar el ajuste preestablecido como un activo, haz clic en Guardar actual en… y luego selecciona uno de los ajustes preestablecidos disponibles para cargar un conjunto de valores.

Aquí hay algunas otras formas útiles de usar ajustes preestablecidos:

• Crea un GameObject con valores predeterminados: Arrastra y suelta un activo de ajuste preestablecido en la Jerarquía para crear un nuevo GameObject con un componente correspondiente que incluya valores de ajuste preestablecido.
• Asocia un tipo específico con un ajuste preestablecido: En el Administrador de ajustes preestablecidos (Configuración del proyecto > Administrador de ajustes preestablecidos), especifica uno o más ajustes preestablecidos por tipo. Crear un nuevo componente se ajustará entonces a los valores de ajuste preestablecido especificados.
• Consejo profesional: Crea múltiples ajustes por tipo y confía en el filtro para asociar el ajuste correcto por nombre.
• Guardar y cargar configuraciones del administrador: Usa ajustes para una ventana del administrador para que las configuraciones puedan ser reutilizadas. Por ejemplo, si planeas reaplicar las mismas etiquetas y capas o configuraciones de física, los ajustes pueden reducir el tiempo de configuración para tu próximo proyecto.

Los estándares de codificación mantienen el trabajo de tu equipo consistente, lo que facilita a los desarrolladores cambiar entre diferentes áreas de tu proyecto. Nuevamente, no hay reglas establecidas aquí. Necesitas decidir qué es lo mejor para tu equipo, pero una vez que hayas decidido, asegúrate de mantenerlo.

Como ejemplo, los espacios de nombres pueden organizar tu código de manera más precisa. Te permiten separar módulos dentro de tu proyecto y evitar conflictos con activos de terceros donde los nombres de clase podrían terminar repitiéndose.

Nota: Al usar espacios de nombres en tu código, divide tu estructura de carpetas por espacio de nombres para una mejor organización.

También se recomienda un encabezado estándar. Incluir un encabezado estándar en tu plantilla de código te ayuda a documentar el propósito de una clase, la fecha en que fue creada e incluso quién la creó; esencialmente, toda la información que podría perderse fácilmente en la larga historia de un proyecto, incluso al usar control de versiones.

Unity emplea una plantilla de script para leer cada vez que creas un nuevo MonoBehaviour en el proyecto. Cada vez que creas un nuevo script o shader, Unity utiliza una plantilla almacenada en %EDITOR_PATH%\Data\Resources\ScriptTemplates:

• Windows: C:\Program Files\Unity\Editor\Data\Resources\ScriptTemplates
• Mac: /Aplicaciones/Hub/Editor/[versión]/Unity/Unity.app/Contents/Resources/ScriptTemplates

La plantilla de MonoBehaviour predeterminada es esta: 81-C# Script-NewBehaviourScript.cs.txt

También hay plantillas para shaders, otros scripts de comportamiento y definiciones de ensamblaje.

Para plantillas de script específicas del proyecto, crea una carpeta Assets/ScriptTemplates, y copia las plantillas de script en esta carpeta para anular los valores predeterminados.

También puedes modificar las plantillas de script predeterminadas directamente para todos los proyectos, pero asegúrate de hacer una copia de seguridad de los originales antes de realizar cualquier cambio. Cada versión de Unity tiene su propia carpeta de plantillas, así que cuando actualices a una nueva versión, necesitarás reemplazar las plantillas nuevamente. El ejemplo de código a continuación muestra cómo se ve el archivo original 81-C# Script-NewBehaviourScript.cs.txt.

En el ejemplo a continuación, hay dos palabras clave que pueden ser útiles:

• #SCRIPTNAME# indica el nombre de archivo ingresado, o el nombre de archivo predeterminado (por ejemplo, NewBehaviourScript).
• #NOTRIM# asegura que los corchetes contengan una línea de espacio en blanco.

Puedes usar tus propias palabras clave y reemplazarlas con un script de editor para implementar el OnWillCreateAsset método.

Usa el encabezado en el siguiente ejemplo de script dentro de tu plantilla de script. De esta manera, cualquier nuevo script se creará con un encabezado que muestra su fecha, el usuario que lo creó y el proyecto al que originalmente pertenecía. Esto es útil para reutilizar el código en proyectos futuros.