Arquitectura Unity para jams VI

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.

2018-08-22 00_27_54-Window
El controlador del modo Acción almacenará las referencias a los métodos de actualización.
2018-08-22 00_28_08-Window
También tendrá los métodos de vinculación y desvinculación.

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

2018-08-22 00_28_37-Window
Al cambiar de modo, vinculamos la UI al actor seleccionado.

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.

2018-08-22 00_37_59-Window
En este caso, siempre que se haga una acción, se va a llamar al método de actualización, pero como el vínculo es responsabilidad de otro objeto, a la hora de hacer esta acción se va a llamar a un método vacío si este actor no está seleccionado.

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.

One thought on “Arquitectura Unity para jams VI

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 )

Google+ photo

Estás comentando usando tu cuenta de Google+. 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 )

Conectando a %s