Hola amigos! Quiero compartir con vosotros el último artículo que escribí en mi blog sobre "Consejos y buenas prácticas en Unity". En él, como su título indica, hablo sobre varios consejos y técnicas útiles para optimizar nuestro trabajo diario con Unity: organización del proyecto, control de versiones, personalización del editor, etc.
 
Espero que os resulte interesante!
 
LINK: https://histeriagamedev.wordpress.com/2017/06/11/consejos-y-buenas-practicas-en-unity/
 
Saludos!

Excelente muy buen articulo, eso de las plantillas de scripts no lo sabia y es muuuy util, ya estaba candado de borrar el "Use this for initialization" y el "Update is called once per frame", muchas gracias
 
 

Cita de: lightbug date=1497268965Excelente muy buen articulo, eso de las plantillas de scripts no lo sabia y es muuuy util, ya estaba candado de borrar el "Use this for initialization" y el "Update is called once per frame", muchas gracias
   
   
       
   

Sí, aunque sea solamente por borrar esos 2 comentarios... jajaja!

Muchas gracias por la entrada y la ayuda que das con ella. 
 
Me has dejado helado con "EVITA EL ACCESO A COMPONENTES MEDIANTE EL INSPECTOR" básicamente porque así lo hacía yo (soy programador y lo veo más claro) pero el docente del curso que estoy haciendo me "echó la bronca" porque debería usar el inspector y no acceder por código.  
 
 
 
Nuevamente mil gracias por tus consejos. 

Cita de: Ufita date=1497274934Me has dejado helado con "EVITA EL ACCESO A COMPONENTES MEDIANTE EL INSPECTOR" básicamente porque así lo hacía yo (soy programador y lo veo más claro) pero el docente del curso que estoy haciendo me "echó la bronca" porque debería usar el inspector y no acceder por código.
   

¿En serio un docente te corrigió eso?, ¿y no te dio los motivos? Aunque el uso del inspector pueda darnos cierta comodidad para acceder a componentes, en la mayoría de los casos es bastante peligroso para el mantenimiento de nuestro proyecto. Creo que son más que evidentes las ventajas de acceder a componentes en tiempo de ejecución, mediante código ;-)

Cita de: Santi Andrade date=1497275675¿En serio un docente te corrigió eso?, ¿y no te dio los motivos? Aunque el uso del inspector pueda darnos cierta comodidad para acceder a componentes, en la mayoría de los casos es bastante peligroso para el mantenimiento de nuestro proyecto. Creo que son más que evidentes las ventajas de acceder a componentes en tiempo de ejecución, mediante código ;-)
   

Si, en serio, me dijo que: "en Unity se hace así", "debes usar las facilidades del motor". 

Al discutirle/comentarle del uso de recursos en variables publicas vs privadas, me comento que podía serializarla. Pero que siempre era mejor usarla desde el editor. 
 
Obviamente como estudiante y un poco (bastante) nuevo en esto acepté sus correcciones como validas.  
 
Son evidentes las ventajas, es más en algún que otro momento me he liado con variables sin "asignar". Para hacer algo rápido un ejercicio rapidillo de una entrega lo veo fácil, pero soy más del código y ahora me has dado una razón de mayor peso para seguir por ese lado. 
 
 
 
Gracias nuevamente. 

Hay de todo un poco. Por ejemplo:
 

• 
     Debería estar totalmente prohibido inicializar con parámetros inline un componente, sobretodo si hace referencia a un login, o una cuenta dónde tengamos alojado un servicio. El Inspector está para alojar esos valores. Si eres un inepto y no guardas los .meta, pues es tu problema...
  


• 
     Las ayuditas éstas tipo Playmaker, etc, que visualizan nodos para crear la lógica de Gameobjects acaban por desorganizar y romper prácticamente todo proyecto a largo plazo. Aconsejo no abusar de ellas, más que para ciertas cosas que os de mucho palo hacer por código.
  

Cita de: pioj date=1497276087Hay de todo un poco. Por ejemplo:
   
   

• 
           Debería estar totalmente prohibido inicializar con parámetros inline un componente, sobretodo si hace referencia a un login, o una cuenta dónde tengamos alojado un servicio. El Inspector está para alojar esos valores. Si eres un inepto y no guardas los .meta, pues es tu problema...
        

      
• 
           Las ayuditas éstas tipo Playmaker, etc, que visualizan nodos para crear la lógica de Gameobjects acaban por desorganizar y romper prácticamente todo proyecto a largo plazo. Aconsejo no abusar de ellas, más que para ciertas cosas que os de mucho palo hacer por código.
        

   

UPsss, me suena que el punto 1 lo uso.. bueno en realidad concateno varios valores, pero si.. mmm, echaré un ojo. 


Gracias @pioj

Gracias a ti, @Ufita
 

Cita de: pioj date=1497276087

• 
           Debería estar totalmente prohibido inicializar con parámetros inline un componente, sobretodo si hace referencia a un login, o una cuenta dónde tengamos alojado un servicio. El Inspector está para alojar esos valores. Si eres un inepto y no guardas los .meta, pues es tu problema...
        

      
• 
           Las ayuditas éstas tipo Playmaker, etc, que visualizan nodos para crear la lógica de Gameobjects acaban por desorganizar y romper prácticamente todo proyecto a largo plazo. Aconsejo no abusar de ellas, más que para ciertas cosas que os de mucho palo hacer por código.
        

   

Respecto al primer punto que comentas, efectivamente, hardcodear parámetros de inicialización de un componente debería estar prohibido, pero pasarlos por inspector no es el único método para hacerlo. De hecho, si se trata de logins y contraseñas, yo optaría por almacenar dichos datos de una manera más segura. Imagina que en mitad de nuestro desarrollo queremos refactorizar el código del script que emite esas variables de logueo al inspector y, por ejemplo, le cambiamos el nombre de dichas variables... en ese caso el inspector ve que no coinciden los nombres de las variables viejas con las nuevas y directamente se carga los valores que tuvieras metidos. Eso es un problema.
 
Sobre el segundo punto... totalmente de acuerdo ;-)

Cita de: Ufita date=1497274934Muchas gracias por la entrada y la ayuda que das con ella. 
   
   
      Me has dejado helado con "EVITA EL ACCESO A COMPONENTES MEDIANTE EL INSPECTOR" básicamente porque así lo hacía yo (soy programador y lo veo más claro) pero el docente del curso que estoy haciendo me "echó la bronca" porque debería usar el inspector y no acceder por código.  
   
   
       
   
   
      Nuevamente mil gracias por tus consejos. 
   

El uso del inspector tiene sus pro/contras, por ejemplo un componente tiene como principio el activar o destruir algo, entonces tiene sentido dar la opcion en el inspector, pero si estas haciendo algo que podes buscar las referencias en los mismos hijos/padres, o quizas instanciar prefabs como recursos es mucho mas facil hacerlo por codigo, te volves independiente de la escena.

Ojo... que no defiendo este método para TODOS los casos. Es obvio que si queremos exponer una variable en el inspector a modo de que dicha variable acepte, de manera dinámica, diferentes objetos de la escena en función de nuestras necesidades en cada momento, entonces sí que el método inspector es el más adecuado. Todo depende de lo que necesitemos.

Cita de: Santi Andrade date=1497279618Incluso en ese caso que comentas, sigo viéndole más ventajas a acceder al componente mediante código que mediante inspector. Vuelvo al ejemplo de antes: ¿qué pasa si, por ejemplo, en mitad del desarrollo refactorizamos código y cambiamos nombres de variables? Perderemos los valores en el inspector.
   
   
      Al final siempre va a ser más seguro acceder desde código.
   

Concuerdo que es mas seguro hacer todo lo posible por codigo, el mundo seria un mejor lugar si hubiera mas codigo jajaj ... pero hay ciertas cosas, aunque muy pocas que no podes acceder por codigo (debatible), el ejemplo mas apropiado es un evento de escenario, por ejemplo prender una o varias luces cuando el personaje pasa por tal trigger, si tuviera un trigger que activa una/varias luces, a no ser que dichas luces sean referenciables via jerarquia con el mismo activador/personaje (desprolijo) ...o por tag, layer, nombres, etc, pero hay muchas mas luces en la escena con el mismo tag, layer, nombre... yo quiero solo esas. Encima no podes encontrar el id de ninguna luz porque cambia en cada play que das. Me queda muchisimo mas facil arrastrar el conjunto al inspector, es hasta mas intuitivo y orientado al diseño.
 
Para mi lo mejor es tener cero referencias en el inspector si es posible (salvo en eventos como te puse arriba), todo el resto de busqueda de Recursos, prefabs, sonidos, sprites, etc lo hago desde un scriptable object, una vez y listo. Cada objeto que use el SCO lo puede buscar como un recurso desde codigo y los inspectores quedan casi vacios.
 
Es cierto, cada vez que cambias el nombre de variables perdes todo, aunque no creo que sea algo que pase muy frecuentemente. Yo en lo personal con el tema de la nomenclatura soy medianamente exigente de entrada, nada de poner "prueba_float_velocidad_Test" o cosas asi, todo en ingles, si es una interfaz arranca con "I", si es un miembro de una clase arranca con "m_" , la primer letra es siempre minuscula y el resto son mayusculas , es mas Unity lo reconoce y en el inspector te lo pone bien, por ejemplo "m_healthPotion" te pone "Health Potion", muy lindo detalle jajaj.
 
 

@lightbug sí, tienes razón en ese caso que pones como ejemplo. En casos complejos como ese es mejor acceder mediante inspector. Por eso al final edité mi mensaje anterior para dar a entender que hay que evitar el acceso mediante inspector en la medida de lo posible, pero que todo depende de nuestras necesidades :-) Gracias! ;-)

Cita de: Santi Andrade date=1497281731@lightbug sí, tienes razón en ese caso que pones como ejemplo. En casos complejos como ese es mejor acceder mediante inspector. Por eso al final edité mi mensaje anterior para dar a entender que hay que evitar el acceso mediante inspector en la medida de lo posible, pero que todo depende de nuestras necesidades :-) Gracias! ;-)
   

Totalmente de acuerdo, ahora vi la edicion, llegue tarde jajaj