5 reglas para mantener tu proyecto de Unity organizado

Uno de los mayores retos al que se enfrentan los programadores es mantener el proyecto organizado. En Unity, a medida que engordamos el proyecto con assets, recursos y scripts, aumentamos también el tiempo que dedicamos a navegar por nuestra maraña de carpetas y archivos. Esto puede disminuir de forma notable nuestro rendimiento y llegar a convertirse en un problema para el estudio.

Por eso quiero darte 5 consejos que te ayudarán a mantener organizado tu proyecto de Unity y mejorarán tu productividad.

1. Sigue unos principios de nomenclatura

Probablemente la regla más importante y en la que más insisto. Existen unos principios estándar de naming que nos conviene seguir a la hora de nombrar nuestros archivos y carpetas. Nombrar bien las cosas nos ayudará a encontrarlas rápidamente, intuir su nombre aún cuando no nos lo sepamos y a saber qué son sólo con ver su nombre. Siempre es mejor invertir unos segundos a pensar cómo vas a llamar cada cosa, que perderlos cada vez que tienes que encontrar algo.

Encontrarás un montón de webs que hablen de esto, pero la mayoría son demasiado extensas o confusas. A mí me encanta cómo lo sintetiza Glen Stevens en su blog (además incluye varios consejos de Unity que no tienen ningún desperdicio):

http://www.glenstevens.ca/unity3d-best-practices/#Naming_Standard_and_Folder_Structure

Nosotros tenemos una versión de una página en .pdf que mantenemos siempre a la vista de todo el equipo, y que quiero compartir con vosotros:

Descargar koron_studios_naming_standard

Quiero hacer hincapié en tres apartados:

  • Si quieres agrupar, utiliza carpetas. El nombre sirve para encontrar recursos y distinguir rápidamente lo que es.
  • Utiliza nombres descriptivos. No utilices siglas ni nombres generales que puedan significar cualquier cosa, y llama a un recurso por el rol que asume dentro del proyecto. Por ejemplo, al icono de Twitter llámalo «TwitterIcon», no lo llames «BlueBird», o tendrás que cambiar el nombre si después decides no utilizar el isotipo. Esta misma regla se puede aplicar, por ejemplo, a un elemento decorativo de la interfaz que pueda sustituirse por otro en un momento dado.
  • Si no está en el proyecto, sácalo del proyecto. Si lo necesitas dentro (por ejemplo, para hacer pruebas), utiliza doble guión bajo:  «__NombreRecurso». Es mucho más fácil distinguir lo que vale y lo que no, y muy rápido convertir un recurso que vale en uno de pruebas o viceversa (únicamente añadiendo o eliminando los underscores).

El naming es tu Dios. Un mandamiento nuevo os trae: que améis al naming por encima de todas las cosas y a tus compañeros como a ti mismo.

2. Separa tus cosas de los third party assets

Cada vez que te descargas un asset de Unity se crea, en el mejor de los casos, una carpeta nueva dentro de tu proyecto. Si añadimos las carpetas de nuestro proyecto directamente dentro de Assets, llegará un momento en que encontrar lo que queremos entre todos los directorios externos puede convertirse en un auténtico infierno.

Además, a medida que generemos tecnología, nuestros propios assets ocuparán espacio dentro de la carpeta de proyecto, por lo que también conviene separarlos

Mi recomendación es crear una carpeta del estudio y, dentro, añadiremos tanto la carpeta del proyecto como la de los assets que hayamos creado. Para encontrarlas rápidamente, yo añado un guión bajo delante, de modo que siempre que quedarán en la parte superior del directorio: _MyCompanyName / _MyProjectName.

  • Assets
    • _MyCompanyName
      • _MyProjectName
      • MySingletonAsset
      • MyUpdateSystem
    • AnotherThirdPartyAsset
    • OneThirdPartyAsset

3. Utiliza namespaces

Tiene mucho que ver con la estructura de carpetas, pero aplicado al código. Los namespaces evitarán que otros assets puedan generar conflictos en tu proyecto: ocurre muchas veces que una clase de nuestro proyecto tiene el mismo nombre que un asset externo, y no todos los desarrolladores que publican assets utilizan namespaces para evitar el conflicto.

La estructura clásica de los namespaces es: com.MyCompanyName.MyProjectName.

koron_studios_visual_studio_project
Escribir una leyendaScript C# con namespace y regiones

Si quieres ser más papista que el papa (o más purista que yo), cada subcarpeta o funcionalidad añadiría un elemento más al namespace (por ejemplo: com.MyCompanyName.MyProjectName.CombatSystem.Model). Yo esto no lo veo necesario (solo lo utilizo para el Editor), ya que pierdo tiempo buscando y añadiendo los «using», y a priori no le veo ninguna ventaja desde el punto de vista productivo.

4. Organiza tus carpetas por funcionalidad

La estructura de carpetas que siempre se recomienda en un proyecto es la siguiente:

  • _MyProjectName
    • Animations
    • Scenes
    • Scripts
    • Sprites
    • Editor

El problema de esta estructura es que, a medida que añadas funcionalidad, se convertirá en algo parecido a esto:

  • _MyProjectName
    • Animations
      • Backgrounds
      • Characters
    • Audio
    • Scenes
    • Scripts
      • Backgrounds
      • Characters
      • Weapons
    • Sprites
      • Backgrounds
      • Characters
      • Weapons
    • Editor
      • Backgrounds
      • Characters
      • Weapons
    • Resources
      • Backgrounds
      • Characters
      • Weapons

De modo que, cuando estás trabajando en una funcionalidad (por ejemplo, Characters), tienes que navegar por toda la estructura de carpetas del proyecto. Por eso, mi propuesta es dividir el proyecto en módulos individuales, con su propia estructura de directorios, de modo que podemos tener únicamente una carpeta abierta con todo lo que necesitamos para desarrollar dicha feature:

  • _MyProjectName
    • Characters
      • Animations
      • Editor
      • Scripts
        • __Test
        • Model
        • View
      • Sprites
    • Backgrounds
    • Scenes
    • Weapons

Mucho más cómodo, ¿verdad? Además, pensar en un juego como un conjunto de funcionalidades individuales te ayudará a crear una arquitectura mucho más escalable.

La única excepción a esta regla la aplico en Audio, y es para que Gerard, nuestro músico y diseñador de sonido, tenga lo que necesita para trabajar en una única carpeta. A la hora de estructurar los directorios debes pensar siempre en la forma en que cada miembro del equipo va a trabajar con Unity para que lo haga de la forma más productiva posible.

Como podéis ver, dentro de Scripts he añadido una carpeta de Model y otra de View. Eso es porque acostumbro a utilizar arquitecturas MVC en mis proyectos. Como los controladores son los componentes en los que más tiempo invierto, los sitúo directamente en la raíz de la carpeta Scripts (en lugar de crear una carpeta Controllers), y así me ahorro un paso en la navegación. Para los que no conozcáis MVC:

    • Model: Son scripts que contienen o acceden a los datos del proyecto. Los utilizo para almacenar las estructuras de SaveData o los modelos de datos de algún elemento del juego (por ejemplo, un Character.cs con la información de un tipo de personaje que utilizaré como modelo para crear los diferentes personajes del juego con ayuda de alguna herramienta del editor).
  • View: Controla la vista del juego. Aquí guardo los scripts referentes a interfaz o efectos. Todos los eventos de botones de la interfaz siempre llaman a un View que, a su vez, llamará al controlador que sea necesario. De este modo, podemos añadir el feedback que queramos en el view y separarlo completamente de la algoritmia.
  • Controllers: Son los scripts que controlan la funcionalidad interna del juego.

La carpeta __Test la utilizo para hacer pruebas unitarias. Como veis, añado dos guiones bajos que indican que lo que meta ahí se puede eliminar.

koron_studios_unity_project
Estructura de directorios en Unity de nuestro Clicker Generator

(https://docs.unity3d.com/Manual/SpecialFolders.html) Unity utiliza unas carpetas especiales que deben mantener su nombre. He visto que muchas veces se colocan fuera de los directorios del proyecto (especialmente Resources y Plugins). Sin embargo, estas carpetas funcionan aunque no estén directamente sobre la carpeta Assets, por lo que recomiendo añadirlas en el lugar que les corresponda dentro de nuestra estructura de carpetas.

5. ¡Involucra a todo el equipo en la organización!

Mantener el proyecto organizado en Unity no es una una tarea únicamente de los programadores, o de los usuarios de Unity. Todo el equipo se debe involucrar para que el proyecto se mantenga organizado de la forma más barata posible (en coste de tiempo), y esto empieza desde el departamento de diseño, continúa con el de arte, y debe estar supervisado desde producción. Hago una lista de las responsabilidades que debe asumir cada departamento:

Diseñadores

  • Define unos principios de naming (o utiliza los que te propongo) y úsalos en tus documentos.
  • Cada elemento debe tener un nombre y únicamente un nombre. Si en un documento se llama a un elemento Tesoro, no puede llamarse después Reliquia.
  • Dedica el tiempo que necesites para nombrar algo y evita tener que cambiarlo después. Si se decide cambiar un nombre, asegúrate de hacerlo en todos los documentos, consúltalo con todo el equipo y valora el impacto del cambio, pues los artistas y los programadores también deberán hacerlo.
  • Si el proyecto es grande, quizás te interese crear un Glosario de Términos.
  • Cuando crees listas de recursos (audio, personajes, animaciones, props, etc), añade una columna con el nombre del archivo o componente que se deberá generar.
  • Asegúrate de que todo el equipo llama a las cosas con el mismo nombre. No solo en los archivos, sino en el día a día.

Artistas

  • Utiliza los nombres que ha definido el equipo de diseño. Si alguno no está definido, consultaselo. Si tienes libertad para crearlo, utiliza los principios de nomenclatura definidos.
  • Separa de forma clara las cosas que valen de las que no. Es normal tener muchas versiones de un mismo archivo, pero invierte el tiempo que sea necesario en que siempre sepas cuál es el que vale, especialmente con las carpetas que vayas a compartir. No te limites a utilizar el doble underscore, si el 80% del proyecto son cosas que no vale, haz limpieza de vez en cuando o crea una carpeta Trash donde puedas tener tus cosas que no sirven.
  • Sé ordenado también con los archivos de proyecto (.psd, .ai, .max…). Organiza correctamente las capas y utiliza los mismos principios de naming. Nunca sabes cuándo va a necesitar utilizarlos otro miembro del equipo.

Programadores

  • Utiliza los nombres que ha definido el equipo de diseño. A la hora de nombrar funciones o clases, utiliza los principios de nomenclatura definidos.
  • Mantén limpio Unity. Es tu responsabilidad. Elimina las cosas que no sean necesarias y no tengas miedo a llamar la atención a quien no esté cumpliendo con su parte, pero sé comprensivo: por deformación profesional, los programadores tenemos una mentalidad muy estructurada y tenemos que entender que a otros perfiles les puede costar algo más ser organizado.

Productores

  • Asegúrate de que el equipo está siendo organizado e impón las medidas que sean necesarias para mejorar este aspecto.
  • No marques como completada una tarea que implique un recurso que no se llame como ha definido el equipo de diseño o que no cumpla con los principios de naming. ¡Ponte duro con esto!
  • Supervisa de vez en cuando las carpetas del proyecto. ¡Incluso los archivos del proyecto!
koron_studios_happy
Los desarrolladores de Koron Studios son felices porque todo el equipo respeta el naming 🙂

Ser organizado es una cuestión de acostumbrarse y de generar una rutina de trabajo. Si no eres organizado, invierte cada día el tiempo que necesites para serlo. Si ya lo eres, ayuda al resto del equipo a crear una rutina.

Un comentario sobre “5 reglas para mantener tu proyecto de Unity organizado

Agrega el tuyo

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

Crea un sitio web o blog en WordPress.com

Subir ↑

A %d blogueros les gusta esto: