Aunque no existe una forma única 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 una plantilla de proyecto facilitan la localización y organización de los archivos. Elija lo que funcione para su equipo y asegúrese de que todos estén de acuerdo.
• Sea coherente con sus convenciones de nomenclatura. No te desvíes de la guía de estilo o plantilla elegida. Si necesita modificar sus reglas de nomenclatura, analice y cambie el nombre de todos los activos afectados a la vez. Si alguna vez los cambios afectan a una gran cantidad de archivos, considere automatizar la actualización mediante un script.
• No utilice espacios en los nombres de archivos y carpetas. Las herramientas de línea de comandos de Unity tienen problemas con los nombres de rutas que incluyen espacios. Utilice CamelCase como alternativa para espacios.
• Separe las áreas de prueba o de zona de pruebas. Cree una carpeta separada para escenas que no sean de producción y experimentación. Las subcarpetas con nombres de usuario pueden dividir su área de trabajo por miembro del equipo.
• Evite carpetas adicionales en el nivel raíz. En general, almacene sus archivos de contenido dentro de la carpeta Activos. No cree carpetas adicionales en el nivel raíz del proyecto a menos que sea absolutamente necesario.
• Mantenga sus activos internos separados de los de terceros. Si está utilizando activos de Asset Store u otros complementos, lo más probable es que tengan su propia estructura de proyecto. Mantenga sus propios bienes separados.

*NOTA*: Si se encuentra modificando un activo o complemento de terceros para su proyecto, el control de versiones puede ayudarlo a obtener la última actualización para el complemento. Una vez importada la actualización, puede revisar la diferencia para ver dónde se pueden haber sobrescrito sus modificaciones y volver a implementarlas.

Si bien no existe una estructura de carpetas establecida, las dos secciones siguientes muestran ejemplos de cómo puede configurar su proyecto de Unity. Ambas estructuras se basan en dividir su proyecto por tipo de activo.

La página del manual Tipos de activos describe los activos más comunes con mayor detalle. Puede utilizar la plantilla o los proyectos de aprendizaje para obtener más inspiración al organizar su estructura de carpetas. Si bien no está limitado a estos nombres de carpetas, pueden brindarle un buen punto de partida.

Si descarga una de las plantillas o proyectos iniciales de Unity Hub, notará que las subcarpetas están divididas por tipo de activo. Dependiendo de la plantilla elegida, debería ver subcarpetas que representan varios activos comunes.

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

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

Una vez que haya decidido una estructura de carpetas para sus proyectos, use una secuencia de comandos del 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 del Editor, la siguiente secuencia de comandos creará una carpeta raíz en los recursos que coincidan con la variable "PROJECT_NAME". Hacer esto mantiene su 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 intente crear sólo carpetas para lo que realmente necesita. Con Git y Perforce, las carpetas vacías se ignoran de forma predeterminada. Si se configuran dichas carpetas de proyectos 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 se envíe al repositorio.

Plastic SCM puede manejar carpetas vacías. Plastic SCM trata los directorios como entidades, cada uno con su propio historial de versiones adjunto.

Este es un punto a tener en cuenta cuando se trabaja en Unity. Unity genera un archivo .meta para cada archivo del proyecto, incluidas las carpetas. Con Git y Perforce, un usuario puede enviar fácilmente el archivo .meta para una carpeta vacía, pero la carpeta en sí no terminará bajo control de versiones. Cuando otro usuario obtenga 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 el control de versiones.

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

Si bien el archivo .meta se genera automáticamente, contiene mucha información sobre el archivo al que está asociado. Esto es común para recursos que tienen configuraciones de importación, como texturas, mallas, clips de audio, etc. Cuando cambia la configuración de importación en esos archivos, los cambios se escriben en el archivo .meta (en lugar del archivo de activos). Es por eso que envías los archivos .meta a tu repositorio, para que todos trabajen con la misma configuración de archivos.

Llegar a acuerdos sobre estándares no se limita a la estructura de carpetas del proyecto. Establecer un estándar de nomenclatura específico para todos los recursos de tu juego puede facilitarle las cosas a tu equipo cuando trabajan en los archivos de otros.

Aunque no existe un estándar de nomenclatura definitivo para GameObjects, considere 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 y minimizando el riesgo de conflictos.

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

Es una buena práctica dividir el trabajo en prefabricados siempre que sea posible y aprovechar el poder de los prefabricados anidados. Si necesita realizar cambios más adelante, puede cambiar la casa prefabricada en lugar de la escena en la que se encuentra, para evitar conflictos con cualquier otra persona que trabaje en la escena. Los cambios prefabricados suelen ser más fáciles de leer cuando se realizan diferencias bajo control de versiones.

En el caso de que termine con un conflicto de escena, Unity también tiene una herramienta YAML (un lenguaje de serialización de datos legible por humanos) incorporada que se utiliza para fusionar escenas y prefabricados. Para obtener más información, consulte Combinación inteligente en la documentación de Unity.

Los ajustes preestablecidos le permiten personalizar el estado predeterminado de casi cualquier cosa en su Inspector. La creación de ajustes preestablecidos le permite copiar la configuración de componentes o activos seleccionados, guardarlos como sus propios activos y luego aplicar esa misma configuración a otros elementos más adelante.

Utilice ajustes preestablecidos para hacer cumplir los estándares o aplicar valores predeterminados razonables a nuevos activos. Pueden ayudar a garantizar estándares consistentes en todo su equipo, de modo que las configuraciones que comúnmente se pasan por alto no afecten el rendimiento de su proyecto.

Haga clic en el icono Preestablecido en la parte superior derecha del componente. Para guardar el ajuste preestablecido como un activo, haga clic en Guardar actual en... luego seleccione uno de los ajustes preestablecidos disponibles para cargar un conjunto de valores.

A continuación se muestran otras formas útiles de utilizar ajustes preestablecidos:

• Crea un GameObject con valores predeterminados: Arrastre y suelte un activo preestablecido en la jerarquía para crear un nuevo GameObject con un componente correspondiente que incluya valores preestablecidos.
• Asociar un tipo específico con un Preset: En el Administrador de ajustes preestablecidos (Configuración del proyecto > Administrador de ajustes preestablecidos), especifique uno o más ajustes preestablecidos por tipo. La creación de un nuevo componente tendrá por defecto los valores preestablecidos especificados.
• Consejo profesional: Cree múltiples ajustes preestablecidos por tipo y confíe en el filtro para asociar el ajuste preestablecido correcto por nombre.
• Guarde y cargue la configuración del Administrador: Utilice ajustes preestablecidos para una ventana del Administrador para que se puedan reutilizar las configuraciones. Por ejemplo, si planea volver a aplicar las mismas etiquetas, capas o configuraciones físicas, los ajustes preestablecidos pueden reducir el tiempo de configuración para su próximo proyecto.

De manera similar, los estándares de codificación mantienen la coherencia del trabajo de su equipo, lo que facilita a los desarrolladores el intercambio entre diferentes áreas de su proyecto. Una vez más, aquí no hay reglas escritas en piedra. Debes decidir qué es lo mejor para tu equipo, pero una vez que lo hayas decidido, asegúrate de seguir adelante.

Por ejemplo, los espacios de nombres pueden organizar su código con mayor precisión. Le permiten separar módulos dentro de su proyecto y evitar conflictos con recursos de terceros donde los nombres de las clases podrían terminar repitiéndose.

*NOTA*: Cuando utilice espacios de nombres en su código, divida la 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 su plantilla de código le ayuda a documentar el propósito de una clase, la fecha en que se creó e incluso quién la creó; Básicamente, toda la información que podría perderse fácilmente en la larga historia de un proyecto, incluso cuando se utiliza el control de versiones.

Unity emplea una plantilla de script para leer cada vez que crea un nuevo MonoBehaviour en el proyecto. Cada vez que crea un nuevo script o sombreador, Unity usa 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 MonoBehaviour predeterminada es esta: 81-C# Script-NewBehaviourScript.cs.txt

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

Para plantillas de script específicas del proyecto, cree una carpeta Assets/ScriptTemplatesy copie las plantillas de script en esta carpeta para anular los valores predeterminados.

También puede modificar las plantillas de script predeterminadas directamente para todos los proyectos, pero asegúrese 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, por lo que cuando actualiza a una nueva versión, debe reemplazar las plantillas nuevamente. El siguiente ejemplo de código muestra cómo se ve el archivo 81-C# Script-NewBehaviourScript.cs.txt original.

En el siguiente ejemplo, hay dos palabras clave que pueden resultar útiles:

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

Puede utilizar sus propias palabras clave y reemplazarlas con un script del Editor para implementar el métodoOnWillCreateAsset .

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