UI

Una de las cosas más tediosas de manejar poco tiempo para un proyecto es dejar features grandes para el final por error. La UI usualmente es un digno candidato, y muchas veces se presenta el peor escenario… ¿cómo integro esto en algo que ya está súper formado?

Una posible solución viene presentada por el uso de Action<>. Action es un tipo especial en C#, se trata de una referencia a un método void, es un tipo genérico donde sus parámetros de tipo son los tipos que contiene la firma del método en particular. Es decir, si queremos referirnos al método StartWait(float seconds) como un action tendríamos que definirlo como Action<float> waitAction. O quizás queremos referir una acción que opere en un vector: MultiplyAndFlatten(Vector3 first, Vector2 second) entonces tendríamos que referenciar esta acción como Action<Vector3, Vector2> vectorAction.

Sí es confuso, no se preocupen, en este ejemplo quedará más claro. La idea es que nuestros elementos de juego son volátiles, propensos a cambios, destrucciones, instanciamientos, mientras que la UI es más estática. Entonces qué tal si, en vez de obligar a que los elementos tengan referencia a la UI directo, estos tengan referencia a las operaciones de actualización de UI, es decir, que puedan ser vinculados, sin conocer la instancia.

En el siguiente ejemplo el juego tiene 2 modos de visualización, uno es el modo Táctico y el otro es el modo Acción. En una partida el jugador puede cambiar entre uno y otro, y según la unidad seleccionada, al cambiar al modo acción la UI debería mostrar los datos de la misma.

(a) => { }; es una función anónima vacía, es decir, es una función que no hace nada pero existe.

La alternativa a esta solución es que el bind le pase la instancia del panel entera al actor, ¡perfecto!, ahora el problema es; ¿qué pasa cuando el actor hace una acción (como perder vida) y no es el seleccionado? Tendríamos que hacer un chequeo para ver si es el seleccionado y llamar al método del panel si lo es, agregando más instrucciones a algo que seguramente ya está lleno de responsabilidades.

Esta solución es un poco más complicada de entender porque rompe el paradigma de referencias de instancia. En este caso estamos referenciando un método de una instancia, y no una instancia. La flexibilidad de usar Action<> es gigantesca, ya que podemos vincular comportamientos a otros comportamientos sin tener que filtrar de manera imperativa. También es sumamente importante romper la dependencia estricta de objetos de juego con UI.