Arquitectura Unity para jams IV

Independencia de scripts

Siguiendo un poco el ejemplo del desacople en el Movimiento, teniendo en cuenta lo que se mencionó, si evaluamos bien el caso, nos damos cuenta que perfectamente el Movimiento puede ser implementado sin el Input y vice versa.

Para lograr esto tenemos que conocer la mecánica que vamos a implementar, por ejemplo, digamos que estamos con las armas y daño, realmente no es necesario implementar armas y proyectiles para implementar daño. Recibir daño no debería ser responsabilidad de la clase de entidad, si no que debería ser responsabilidad propia, es decir un componente de Salud quizás. Sabemos que si la salud está expresada en enteros, entonces el daño que recibamos va a estar también expresada en enteros. Por ende con toda la confianza del mundo, sin haber implementado armas, podemos implementar la función “TakeDamage(int damage)” sin ningún impedimento.

El objetivo de esta práctica es justamente hablar el mismo idioma entre los programadores, tratar los scripts como entidades del tipo Entrada-Salida. Es un ejercicio muy interesante ponerse de acuerdo entre los programadores sobre sus entradas y salidas de datos antes de empezar a implementar funcionalidades por separado.

 

 

Interfaces

El uso de interfaces en las jamás está muy subestimado. Digamos un escenario donde hay diferentes tipos de enemigos, los proyectiles del jugador afectan a todos, pero a cada enemigo de manera diferente.

Instintivamente tomaríamos uno de dos caminos:

  • El proyectil contiene un script donde se discrimina contra que tipo de enemigo colisiono y llama al efecto adecuado.
  •  Todos los enemigos tienen un script en común que reacciona al proyectil según el tipo de enemigo que es.

Al usar interfaces podemos proponer esto, el proyectil simplemente llama a other.GetComponent<Health>().TakeDamage(dmgValue) donde Health es una interfaz y existen varias implementaciones de dicha interfaz, podrían ser HeavyEnemyHealth : Health, SmallEnemyHealth : Health. Al llamar a get component de una interfaz, automáticamente encuentra el componente que implemente esa interfaz y llama al método. Esto nos ahorra hacer la discriminación de manera manual y más aún, es súper escalable, si queremos agregar un nuevo enemigo solo tenemos que hacer la implementación para ese enemigo, no necesitamos tocar un script maestro ni el proyectil.

 

2018-08-21 23_48_23-Window
Interfaz base.
2018-08-21 23_49_55-Window
Implementación del jugador.
2018-08-21 23_50_27-Window
Implementación del enemigo pequeño.
2018-08-21 23_50_46-Window
Implementación del enemigo grande.
2018-08-21 23_50_56-Window
Proyectil, solo busca algún componente que implemente la interfaz Health, el proyectil no discrimina.

El uso de interfaces nos ahorra un montón de tiempo a la hora de agregar nuevo contenido a nuestro juego en un marco de tiempo reducido y orienta el código a un paradigma más de juego, primero se definen las reglas y luego se agrega el contenido.

One thought on “Arquitectura Unity para jams IV

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