Estas mejores prácticas provienen de nuestro libro electrónico gratuito, Control de versiones y mejores prácticas de organización de proyectos para desarrolladores de juegoss, creado para ayudar a los equipos con miembros tanto técnicos como no técnicos a tomar decisiones inteligentes sobre cómo configurar un sistema de control de versiones y planificar una colaboración fluida.
Aunque no hay una única forma de organizar un proyecto de Unity, aquí hay algunas recomendaciones clave:
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:
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:
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:
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.
Si encontraste esto útil, consulta otro recurso sobre mejores prácticas para organizar tus proyectos o nuestro libro electrónico gratuito sobre control de versiones.
