Esta entrada pertenece a ActionScript 3 - Guía para Principiantes.
Y sí, lamentablemente y por falta de tiempo, tuve que prescindir de las imágenes para las cabeceras de cada capítulo.
Definición del Escenario
En previsión de lo que va a ser un aumento exponencial de las clases de nuestro juego, deberíamos comenzar a organizarlas de manera estructurada para que nuestro proyecto Flash no se acabe convirtiendo en una amalgama de código intratable.
Todo lo relacionado con los escenarios parece tener la suficiente importancia como para poder considerarlo como un bloque separado de Pong y Bola. Así, en nuestro proyecto de FlashDevelop, dentro de la carpeta "pong", vamos a añadir una subcarpeta (un nuevo paquete) a la que llamaremos "escenario". Y dentro de esta carpeta, creamos nuestra clase Escenario.
Antes de escribir código, vamos a pensar que representa esta clase Escenario y qué queremos hacer con ella.
Ya nombramos el encapsulamiento de la Programación Orientada a Objetos. Pero vamos a definirlo bien para que no nos perdamos.
¿Qué es el encapsulamiento?
En POO, es el proceso por el que ocultamos la implementación interna de una clase (o concepto) y sólo podemos acceder y modificar su estado por métodos definidos por la propia clase. Es decir, sabemos como interactuar con él y lo que podemos esperar que haga, pero no sabemos "cómo funciona por dentro".
Lo que queremos es encapsular el Escenario (bueno, el Escenario y muchas cosas más...) y que sea él quién se encargue de colocar los pongs, de controlar las colisiones y los marcadores y de otras muchas cosas que ya veremos. Y queremos que lo haga bien. Y queremos que desde cualquier otro sitio (la clase Main, por ahora), cuándo un objeto de la clase Escenario sea creado todo funcione correctamente. Creamos el Escenario y nos olvidamos.
Bien, pues pensemos qué tareas tendrá asignada nuestra maravillosa clase Escenario:
- Creación y colocación de los pongs, bolas y otros objetos.
- Control de colisiones.
- Control de puntuación.
Bueno, esto de momento.
Control de colisiones: Colisionadores y colisionables
Hasta ahora, el control de colisiones había sido muy sencillo. Le decíamos a la bola con que cosas podía colisionar y ella se encargaba de ver si chocaba o no. Esta información se le transmitíamos a la bola en su creación. Pero hacerlo así tiene una consecuencia: el número de objetos con los que la bola podía colsionar no puede aumentar ni disminuir. Y, aunque de momento esto no sucede, sucederá. Y en previsión de ello, en nuestro escenario vamos a definir dos tipos de objetos:
- Colisionadores: aquellos objetos que pueden lanzarse a la búsqueda del choque de otros objetos. Ej: la bola, misiles lanzados desde los pongs, etc.
- Colisionables: objetos que esperan ser embestidos por los objetos colisionadores. Ej: los pongs, los ítems que aparezcan en el escenario, etc.
Y ahora llega el gran problema: ¿cómo le decimos a ActionScript 3 que un pong es un colisionable y una bola un colisionador? Una solución factible podría ser definir dos clases: Colisionadores y Colisionables, y que cada una de las clases necesarias heredase de su respectiva clase padre.
Lamentablemente, esta solución no es viable debido a que ActionScript 3 no soporta la herencia múltiple (heredar de varias clases simultáneamente) como por ejemplo C++. Sin embargo existe una solución parecida, que nos servirá perfectamente para la realización de nuestro propósito: las interfaces.
¿Qué es una interfaz?
Simplificando mucho, una interfaz es un conjunto de métodos sin cuerpo (sin definición). Se dice que una clase implementa una interfaz cuándo define todas sus funciones.
Para concretizar un poco más, utilicemos un ejemplo. Por ejemplo, supongamos que tenemos una interfaz Volador. Y esta interfaz define los siguientes métodos: despegar, volar y aterrizar.
Y ahora tenemos dos clases: Pájaro y Avión. Nuestro propósito es crear una clase Cielo que contenga todo tipo de objetos voladores, pero a la clase Cielo no le interesa saber si esos objetos son pájaros o aviones. Sólo que son voladores. Y quiere tratarlos a todos de la misma manera. Por ello tendrá un conjunto de objetos que implementan la interfaz Volador.
Así, Pájaro tendrá sus propios métodos y atributos: comer, limpiarse, y además implementará la interfaz Volador, definiendo despegar, volar y aterrizar. Lo mismo sucederá con Avión, que tendrá sus métodos y atributos propios, pero que también definirá despegar, volar y aterrizar.
Y es importante destacar que la implmentación de despegar en Pájaro es distinta que la de Avión. Un pájaro despega de manera distinta a cómo lo hace un avión. Sí. Pero los dos pueden despegar, porque los dos son voladores. En este punto es dónde radica la potencia de las interfaces.
Definición de interfaces en ActionScript 3
public interface INombre
{
function metodo1([parámetros1]):tipo_devol1;
function metdoo2([parámetros2]):tipo_devol2;
...
}
Las interfaces no admiten atributos. Por una convención no escrita (o quizá sí) todas los nombres de nuestras interfaces comenzarán con "I", por aquello de Interfaz.
Pasemos, por fin, a escribir el código para nuestro escenario y vemos mejor, también, todo esto de las interfaces.
| Anterior | Índice | Siguiente |
