Inicializando variables

Saber cuándo y dónde inicializar tus variables en Unity puede marcar la diferencia entre un proyecto flexible y uno lleno de errores difíciles de rastrear. Aquí se exploran tres enfoques: usar Start, usar Reset y usar propiedades con getters, cada uno con ventajas y desventajas claras que todo desarrollador de juegos debería conocer.

¿Por qué no deberías usar GetComponent en el Update?

Uno de los errores más comunes al empezar con Unity es llamar a GetComponent dentro del Update [1:52]. Este método recorre todos los componentes del GameObject para encontrar el que necesitas, y hacerlo en cada frame es costoso en rendimiento. La solución es inicializar la referencia una sola vez y reutilizarla.

Para eso, se crea una variable que almacene el componente y se le asigna valor en un momento específico del ciclo de vida del script. La pregunta es: ¿en cuál?

¿Cómo funciona la inicialización en el Start?

El enfoque más conocido es inicializar variables en el método Start [2:15]. Se declara una variable, por ejemplo areaDeEfecto de tipo Collider, y en el Start se le asigna el resultado de GetComponent<Collider>(). Así, en el Update solo se accede a la variable ya inicializada.

• Funciona bien cuando el componente está en el mismo GameObject.
• Se ejecuta automáticamente al dar play.
• El valor se asigna una sola vez al inicio del juego.

El problema aparece cuando el Collider no está en la raíz del objeto sino en un hijo o en otro lugar de la jerarquía [3:22]. Si mueves el componente a un objeto hijo, el GetComponent del Start no lo encuentra y la variable queda nula. Para corregirlo, tendrías que cambiar el código a GetComponentInChildren o GetComponentInParent, y cada variación de bomba podría necesitar una versión distinta [4:38].

¿Qué ventajas ofrece el método Reset?

El método Reset no se ejecuta durante el juego, sino en el editor [0:42]. Se activa al hacer clic derecho sobre un componente y seleccionar "Reset". Esto significa que puedes configurar las referencias antes de dar play y verificar visualmente en el Inspector si algo falta.

• Si el componente no se encuentra, la propiedad se queda nula en el Inspector, lo que da una pista visual inmediata de que algo anda mal [1:05].
• La referencia se mantiene aunque muevas el objeto en la jerarquía [5:42].
• No se sobreescribe al dar play, a diferencia del Start.
• Es flexible: puedes asignar manualmente un Collider que esté fuera del objeto y no se borrará [6:05].

La desventaja principal es que solo funciona en el editor [1:16]. En una build final, el Reset no se ejecuta, así que dependes de que la configuración se haya hecho correctamente durante el desarrollo.

¿Cuándo conviene usar propiedades con getters en lugar del Start?

Para valores que dependen de otros y que pueden cambiar durante la ejecución, las propiedades con getters son la mejor opción [1:25]. Una propiedad se escribe con la primera letra mayúscula por convención de C#, no lleva paréntesis al invocarse y ejecuta código internamente cada vez que se consulta.

El ejemplo presentado es JumpVelocity, un valor calculado a partir de jumpHeight usando las leyes de la física. Si se inicializa en el Reset y luego el programador cambia jumpHeight, el JumpVelocity no se actualiza porque ya fue calculado [1:30]. En cambio, con un getter, el cálculo se realiza cada vez que se accede a la propiedad.

• Se obtiene el single source of truth: no hay duplicación de datos ni necesidad de sincronizar variables manualmente [1:44].
• Es legible: se usa como una variable normal, sin paréntesis.
• El contra es el costo computacional: si el cálculo es pesado, como Math.Sqrt, se ejecuta en cada acceso [1:50].
• Otra limitación es que no aparece en el Inspector, lo que dificulta la depuración visual.

¿Qué papel juega el Is Trigger en los colliders?

Durante la demostración, la bomba no destruía a los enemigos a pesar de que el Collider se activaba correctamente [6:22]. El problema era que la casilla Is Trigger no estaba habilitada. Sin ella, Unity usa OnCollisionEnter en lugar de OnTriggerEnter, y el código estaba escuchando solo este último. Activar esa casilla resolvió el problema de inmediato [6:50].

Este tipo de errores con colliders son frecuentes y difíciles de detectar, por lo que siempre conviene verificar la configuración del componente en el Inspector.

Cada enfoque tiene su lugar. El Reset brilla por su flexibilidad y su capacidad de mostrar problemas antes de ejecutar el juego. El Start es confiable para inicializaciones que no cambian. Y las propiedades con getters son ideales para valores derivados que necesitan estar siempre actualizados. ¿Cuál prefieres usar en tus proyectos? Compártelo en los comentarios.