 |  |
 |  |
|
|
Artículo realizado por
En este artículo vamos a echar un vistazo a una de las técnicas más interesantes para la construcción de escenarios; la técnica de los "tiles" ó "baldosas". Seguro que muchos de vosotros os habréis preguntado, al ver un juego típico de estrategia o aventura en 2D, cómo poder almacenar escenarios de tan grandes proporciones sin pedir, como requerimientos mínimos, cantidades ingentes de memoria RAM. La técnica de los "tiles" permite construir escenarios utilizando pequeñas porciones de distintas texturas que, poniéndolas de forma adyacente (unas al lado de otras), encajan a la perfección dando la sensación de que todo lo que vemos es un gráfico de una sola pieza. Así pues, los "tiles" permiten construir escenarios o mapas mediante la utilización inteligente de pequeñas porciones gráficas que se identifican por sus diferentes texturas. Así, podemos crear un escenario de grandes proporciones que simule un prado mediante la unión de "tiles" que tengan la misma textura. En este caso, la textura debería de simular ese color propio de un terrero verde. La utilización de "tiles" ha sido muy provechosa para la creación de escenarios en juegos de estrategia o aventuras "a vista de pájaro" pues permiten a los programadores disponer de mapas fabricados a partir de matrices que toman diferentes valores dependiendo del "tile" que se representan en pantalla. Por otro lado, existen dos implementaciones principales para representar los "tiles". La más básica, que es la que veremos aquí, consiste en disponerlos de tal forma que simulen un escenario visto desde arriba. La otra, es la que implementa una vista isométrica de tal forma que los "tiles" vienen a ser rombos que, una vez colocados de forma adyacente, crean una sensación de profundidad 3D. He aquí algunas muestras de juegos que utilizan estas técnicas.
Fernando Rodríguez
Introducción a la técnica de los "tiles".
| |
| |
Para poder entender todo mejor, basaré mi explicación en un antiguo desarrollo, llamado "Maptool", para la construcción de escenarios. Veréis, que alguno de los "tiles" han sido sacados del "Civilization II". Esto es así porque el set original del "Maptool" (que data de 1994), dejaba bastante que desear. Por otro lado, la aplicación ha sufrido muchas variaciones para uso puramente personal (para realizar pruebas de programación) por lo que la flexibilidad del programa es nula. .Su carácter es, pues, didáctico y puede servir de ayuda a todos aquellos que quieran crear una herramienta como el "Maptool" para sus propios proyectos o experimentos.
Una primera aproximación al problema
Vamos a realizar, ahora, una aproximación al problema del diseño de las estructuras de datos e implementaciones necesarias para resolver la representación del mapa a editar. Posteriormente, iremos más al grano.
Como se dijo al comienzo, un "tile" es una imagen gráfica de muy pequeñas dimensiones (16x16 o 32x32 pixels). Obviamente, a medida que aumentemos la resolución del juego, deberemos de trabajar con tamaños más grandes para los "tiles". Si al igual que hacemos con una baldosa al construir el suelo de una casa, unimos varios de esos "tiles" obtendremos un bloque capaz de representar un mapa mucho más grande en términos de resolución. Esto abre grandes posibilidades para ser utilizado en editores de escenarios pues no obliga a los creadores a trabajar, por ejemplo, con un bitmap de grandes dimensiones. Si tuviéramos que utilizar un bitmap que representara un mapa, necesitaríamos un bitmap de proporciones enormes y, por consiguiente, mucha cantidad de memoria para mantenerlo. Si el mapa fuera de dimensiones muy reducidas, es decir, de una resolución igual o menor a la que se está utilizando en pantalla, realmente no estaríamos utilizando un mapa, sino una "imagen de fondo".
La idea es, pues, utilizar una matriz (más adelante, analizaremos el uso de listas dinámicas. Mientras tanto, vamos a suponer que el mapa está construido sobre una matriz) de las dimensiones del mapa a representar. Cada coordenada del mapa dispondría de un valor numérico que indicaría qué "tile" debe de cargarse en dicha zona.
Imaginemos por un momento que el mapa representa un océano. Bastará con poner repetidamente el tile que tiene textura de océano en pantalla, o lo que es lo mismo, inicializar el array o matriz con el valor numérico que utilizamos para representar al "tile" agua. Cuando nos movamos por el mapa (o array), lo que haremos será leer el número del tile que hay que poner, ir a una tabla que nos diga en qué coordenada del buffer (supongo que la persona que esté leyendo este artículo, tiene conocimientos mínimos de programación gráfica) se encuentra el tile que representa el agua y, finalmente, dibujar ese "tile" en el mapa de edición. Esta técnica resulta muy poderosa si se dispone de un set de "tiles" preparado y bien texturizado tarea, ésta, que debería de ser cubierta por el grafista del grupo. Si no hay tal grafista, el programador siempre puede apañárselas con gráficos rudimentarios pero que le sirvan para poder comenzar a trabajar en el "engine" basado en "tiles".
Una vez que hemos realizado una primera aproximación a cómo poder implementar un mapa basado en "tiles", cabría profundizar un poco más en la idea pues, en el momento que vayamos a codificar, nos daremos cuenta de otros factores que existen en un mapa y cumplen unas condiciones peculiares.
A parte de la base o terreno sobre el que está construido un mapa (por ejemplo, un "tile" que represente suelo verde), éste también tiene otro factores que, por así decirlo, van encima de lo que es la base. Sólo hace falta volver a pensar en una pradera. Sobre la pradera podría ir un río o existir una montaña. Si pensamos en un desierto, en medio de éste pudiera existir un oasis, o un grupo de camellos, etc. A estos aspectos a representar en el mapa les vamos a denominar aspectos de forma pues contribuyen a "modelar" el set de "tiles" destinado a crear el terreno o la base del escenario (por ejemplo, una montaña que se añade a un terreno rocoso). Así pues, el set de forma se añade siempre encima del set de "tiles" base pero no lo destruye sino que se acopla a él. Para hacer esto, como veremos más adelante, podremos utilizar varias técnica. Tenemos la opción de acudir a máscaras o bien decantarnos por la utilización del color invisible. "Maptool" utiliza ésta última técnica. Junto al set de "tiles" de forma, podemos pensar en otro llamado set de "tiles" objeto que lo que haga sea añadir un factor miscelaneo al mapa, es decir, que añada aspectos que no tengan por qué configurar el aspecto propio del terreno pero que sí ayuden a dar vivacidad al mundo que estamos creando. Así pues, en este set podrían ir personas, animales, medios de transporte, etc.
En conclusión, hemos visto que podemos utilizar un array o matriz para representar el mapa que estamos editando. Dicho array podría tener unas dimensiones de mxn casillas (en el caso de "Maptool", los escenarios son de 64x64 casillas. Por supuesto, una herramienta bien diseñada debería de ofrecer amplia libertad para elegir las dimensiones del mapa). También hemos visto que cada casilla o posición del array, puede quedar definida por tres valores de tres set distintos de "tiles". A saber:
Además, el orden en que se dibujarían en el mapa sería el mostrado arriba de tal forma que la parte más visible es la concerniente al set de objetos (imaginémonos la situación. Pintamos un terreno verde, encima un río y, por último, una pequeña barca con un pescador).
Antes de abandonar esta aproximación a la representación de los "tiles", comentar que el poco código que se va a enseñar aquí (la idea es que la persona que lea esto pueda hacerse una idea más o menos clara de cómo hacer las cosas), va a ser en el C de toda la vida. Pero repito que, como apenas va a ver código, con lo aquí explicado se podrá crear el engine en cualquier lenguaje.
Los "tiles" del "Maptool", se representan en un array de 64x64. Como dicho array tiene un gran tamaño se reserva espacio, al comienzo del programa, para mantener dicho array. El array contiene, para cada posición, tres campos. Cada uno de los campos o variables está destinado a mantener un "tile" que corresponde a una de las tres capas que existen: capa base, capa de forma y capa de objetos (este concepto se examinará con mayor profundidad en el apartado siguiente "El concepto de 'las tres capas' "). Se puede examinar la estructura que define y mantiene el mapa de edición, a continuación:
typedef struct mapaEdicion {
unsigned char tileBase;
unsigned char tileForma;
unsigned char tileObjeto;
}; // Definición de los datos del mapa de edición.
Los "tiles" se representan en el array como un tipo de datos unsigned char, es decir, no habrá ningún set que tenga más de 256 "tiles" distintos.
En cuanto a la representación externa, los "tiles" se encuentran dibujados en un archivo .SCR (formato propio). Este archivo contiene una información, la de los "tiles", que es continuamente utilizada. Una buena idea es mantenerlo en memoria pues, de lo contrario, los continuos acceso a disco terminarían por exasperar a cualquiera. Tal y como hicimos con el mapa que contiene los "tiles", el buffer que contiene la gráficos de los "tiles" es reservado nada más arrancar la aplicación. Los "tiles" tienen un tamaño de 32x32 pixels.
Antes de pasa a mostrar la imagen del archivo que contiene a los tiles, tenemos que tener constancia de un aspecto muy importante. Cuando nosotros diseñamos (o encargamos diseñar) un set de "tiles" para el terreno, debemos de tener en cuenta que necesitaremos de una serie de "tiles" que nos proporcionen una transición de un tipo de terreno a otro. Para entender esto mejor, nada como un gráfico explicativo:
 |
 |
Como se puede observar, cuando no hay un "tile" especial que se encargue de proporcionar la transición entre diferentes tipos de terrenos, el resultado es que tenemos un mapa muy brusco y, por consiguiente, muy poco real. Sin embargo, si destinamos un "tile" especial a para cubrir tal objetivo, obtendremos un mapa mucho más coherente y menos tosco. El problema está en ingeniárnoslas para tener un número de "tiles" pequeño que se encargue de realizar todas las transiciones entre tipos de terreno. Fijémonos, ahora, en la figura siguiente que muestra 5 de los 12 tipos de transición, para los tipos de terreno "agua", "hierba" y "desierto":
 |
 |
 |
Como se puede observar, todos los terrenos llevan el mismo tipo de transición. Si lográramos hacer una especie de "molde" sobre el que construir las diferentes transiciones utilizando los "tiles" de base, quizás podríamos superar este problema. En el "Maptool", el set de "tiles" base contiene 7 "tiles", el set de forma 32 "tiles" y el set de "tiles" objeto 14. Como hemos explicado más atrás, en el set de "tiles" debería de haber muchos más pues los "tiles" dedicados a simular el paso de un tipo de base a otra son 12 y si hay 7 bases distintas deberíamos de tener 12x7 = 84 "tiles", o lo que es lo mismo, un ingente gasto de memoria. Para solucionar el problema, lo que se hace es construir, en tiempo de ejecución, los tiles de transición. Para ello, se usan unos moldes que se encargan de simular los 12 "tiles" que representan el cambio de una base de terreno a otra. Aquí ofrecemos la idea, en el apartado ""tiles" que se construyen en tiempo de ejecución" los explicamos más exhaustivamente.
A continuación se muestra el aspecto del archivo que contiene la información gráfica de los distintos set de "tiles":
El concepto de las tres capas hace referencia al uso de los tres grupos de "tiles" con los que trabajamos, aunque podrían ser muchos más. Estos set son:
Como vimos más arriba, la estructura o array que se encarga de almacenar los "tiles", cuenta con tres campos en donde distinguir los "tiles" que vamos incorporando al mapa. Una de estas variables es la de base, otra la de forma y, por último, otra para el objeto. El editor trabaja con estos tres tipos distintos de set y cada una de las posiciones que editamos puede tener un tile de cada uno de los set. El tile que siempre es obligado que tenga el mapa es el que corresponde al set de "tiles" base. Por el contrario, no pasará nada si falta el tile de forma o el de objeto. Bastará con utilizar un código que signifique "no hay tile" y, simplemente, no dibujaremos nada ("Maptool" utiliza el código 0 para indicar que no hay "tile")
Para poder representar los "tiles" sobrepuestos sin que se machaque el dibujo, es decir, de tal forma que se dibuje sólo el contorno de los "tiles" que pertenecen al set de forma u objeto, se utiliza la técnica que se vale de un determinado color de la paleta, conocido como color invisible (que suele ser el color 0 de la paleta), que nunca se imprime en pantalla. Esta técnica lo que hace es leer el gráfico del "tile" que se debe de dibujar una posición del mapa recorriendo cada una de los pixels del mismo. Si el valor leído o byte leído (estamos trabajando con 256 colores luego cada pixel se representa con un byte) es distinto a 0, ese valor se llevará a pantalla. Si, por el contrario el valor es 0, no se llevará a pantalla. En ambos casos, después de la comprobación y del posible dibujo, aumentaremos la posición de lectura sobre el gráfico del "tile". Esta técnica es ampliamente utilizada para representar sprites o imágenes discontinuas. Obviamente, cuando digo "se llevará a pantalla", me refiero que a que se llevará a un buffer sobre el que estaremos construyendo la imagen que luego sí que se volcará a pantalla (repito que entiendo que la persona que lea esto tiene unos conocimientos elementales de la programación gráfica. Si no es así, me remito a los artículos sobre sprites publicados en este mismo número de Macedonia).
A modo de ejemplo, si la imagen (sprite o tile) a representar es la siguiente:
011100000Lo que haríamos sería leer y copiar a pantalla sólo aquellas zonas que fueran
1. De esta forma, se logra representar una imagen discontinua en pantalla pues la porción que tenga el color 0, no se dibujaría (prevaleciendo lo que hubiera debajo). Podríamos imaginarnos que el color rojo representa una textura de tierra. Si debajo hubiera un "tile" de océano, al aplicar esta técnica, el gráfico resultante sería una costa. Otro ejemplo sería suponer un "tile" que simule un árbol. Este no tiene que ocupar todo su espacio con datos distintos a 0, sino que se supone que se dibujará sobre una base ocupando una pequeña porción de la misma. Lo único que tenemos que hacer es dibujar un árbol no muy grande y poner a valor 0 todas aquellas partes que quedan a su alrededor para que no se pinten en pantalla. La mejor idea es construir los "tiles" sobre una plantilla de color igual al que tengamos seleccionado como color invisible. Ver figura del árbol:
Añadir, para finalizar este apartado, que como los "tiles" base siempre tiene todo con valores distintos de 0 (no tienen porciones de color invisible) al dibujarse en pantalla "machacarán" a lo que había antes.
Anteriormente se mencionó el hecho de que existen "tiles", pertenecientes al set de forma, que se construyen en tiempo de ejecución. Esto es así porque hay un tipo especial de tile de forma que se encarga de simular el paso de una base o terreno a otro. Como existen un total de 7 terrenos base a representar y 12 son los tipos distintos de "tiles" dedicados a simular el paso de una zona a otra, necesitaríamos un total de 12 x 7 = 84 "tiles". Para solucionar el problema lo que se hace es construir esos "tiles" por medio de otros llamados "tiles" molde en conjunción con los propios "tiles" de base. Un tile de molde es aquel que está compuesto por 2 colores. Un color 0, como color invisible, y un color distinto de 0 para simbolizar que en esa zona ha de ir la textura del "tile" de base sobre el que se debe de aplicar el molde. El proceso de construcción de los "tiles" de transición es bien sencillo. Debemos de llevar todos aquellos pixels que representan color invisible en el "tile" de molde, al "tile" de base. Para ello, comenzamos a recorrer el "tile" de molde. Si el color leído es el color invisible, lo ponemos encima del "tile" de base para el que queremos construir la transición. En cualquier otro caso, no copiamos nada sobre el "tile" de base y continuamos con el proceso de construcción hasta que acabemos de recorrer todo el "tile" de molde. Es decir:
0000000El tile que queda al montar un tile sobre otro es el siguiente:
0000000Como puede apreciarse, el tile que hemos construido no es más que el tile de base pero poniendo a 0 las zonas que están a 0 en el tile de molde. Esta técnica tan sencilla nos permite ahorrarnos un buen montón de "tiles". Lógicamente, el tile resultante "no existe en ningún sitio" (no está almacenado en ningún fichero gráfico), sino que se crea siempre que se necesita dibujar en pantalla.
Hasta aquí, hemos explicado la base sobre la que poder construir el engine de "tiles" en 2D. Ahora, vamos a ver otros aspectos que pueden ayudarnos a la hora de plantear la construcción del engine basado en "tiles". Haremos referencia (muy por encima, porque el cometido de este artículo ya se ha cubierto) a aspectos del "Maptool" que, sin formar parte directa del engine, sí que le dan un toque más profesional e interesante. También comentaremos posibles mejoras para que nadie se pierda a la hora de implementar su propio sistema basado en "tiles 2D".
 |
El mini - mapa.
Una de las mayores comodidades del editor es el mini - mapa. Su implementación no reviste mayores problemas. El mini - mapa ocupa una dimensiones de 64x64 pixels en pantalla. Cada pixel de pantalla representa una posición del mapa que estamos editando, o lo que es lo mismo, un tile de 32x32 pixels. Como hay tres "tiles" que pueden dibujarse en una única posición del mapa, lo que se hace es establecer unas prioridades de identificación. Cada tile que se dibuja en el mini - mapa tiene asignado un color, salvo los "tiles" que pertenecen al set de "tiles" objetos que tienen todos como color asignado el color rojo.
Por tanto, el método a la hora de representar el mini mapa es el de dibujar el tile de mayor prioridad representado, precisamente, la zona del mapa en donde se encuentra. La máxima prioridad de dibujado en el mini mapa es inversa a la del mapa de edición, es decir, si hay tile objeto se dibuja ese tile y si no se mira si hay tile forma, si hay tile forma se dibuja ese tile. De nuevo, si no hay tile forma, entonces seguro que hay tile base y es ese tile el que se identifica en el mini - mapa.
El mini - mapa se actualiza sólo en la zona que ha sido actualizada en el mapa de edición, es decir, se actualiza cuando hacemos una modificación.
Implementación del zoom en el mapa global.
Una de las opciones más interesantes del "Maptool" es la referente al mapa global y la posibilidad de hacer zoom tanto para acercarnos a ellos como para alejarnos. Las prestaciones por defecto del mapa global permiten divisar un mapa con 10 "tiles" a lo ancho y 6 a lo alto frente a los 7 y 4 que permite el mapa de edición. Esto ya supone una gran ventaja pues podemos ver más terreno real. Pero lo que de verdad puede ser más interesante a la hora de ir viendo el trabajo que vamos haciendo es ver el mapa mediante sucesivos zoom. Podemos acercarnos al terreno y ver los "tiles" más grandes o podemos alejarnos y ver los "tiles" más pequeños. Con éste modo de zoom, podemos llegar a ver hasta 20 "tiles" horizontales y 18 verticales es decir, en pantalla estaríamos viendo un total de 20x8=160 "tiles" a la vez, frente a los 7x4=28 "tiles" que vemos en el mapa de edición normal.
Una de las primeras soluciones que pensé para llevar a cabo este proceso fue la de disponer de pequeños "tiles" acordes a lo que debería ser un zoom, tanto de acercamiento o alejamiento. Esta solución, fue rápidamente desechada porque sería muy ineficiente (sería una salvajada). Estaba claro que esa no podía ser la solución así que se tenía que implementar por software, algún tipo de escalado para reducir los "tiles". Al final, se decidió implementar el siguiente método: Cada vez que nos alejemos se irán repitiendo pixels del tile que estamos dibujando, mientras nos acerquemos, se irán desechando pixels del "tile" que estamos dibujando.
Así pues, cada vez que nos alejamos más del mapa se va examinando cada menos tiempo un contador que se inicializa a 0 y que, llegado a un determinado valor de tope, indica que el pixel que se ha puesto en pantalla se ha de repetir, o no, en la siguiente operación. Así, si nos acercamos 2 casillas, y los "tiles" son de 32x32, el contador tendrá que llegar al tope 32/2 -1, es decir, 15. Cuando llegue a 15, no se aumentará el puntero que recorre el buffer en dónde se encuentra la imagen o "tile" que estamos copiando (recordemos que, antes de mostrar todo en pantalla, se construye en una pantalla virtual para, posteriormente, volcarlo a memoria de vídeo) sino que se mantendrá obligando a que la siguiente iteración dibuje lo mismo. Seguidamente, el contador se inicializará a 0. Es fácil deducir que a medida que nos acerquemos más el tope disminuirá se tenderá a repetir más veces partes del dibujo, es decir, la fórmula será (32/aumento – 1). El contador se utilizará tanto para dibujar columnas como filas.
En el caso de estar alejándonos a pantalla todo será igual salvo que, en lugar de no aumentar el puntero que recorre el buffer en donde está el tile que debemos de dibujar en pantalla, lo que haremos será aumentarlo dos veces, esto provocará que parte del tile no se dibuje. A medida que más nos acerquemos, el contador indicará que esa operación ha de hacerse más a menudo.
Rutina de relleno de la zona editada.
Esta rutina se encarga de rellenar la parte de edición que estamos viendo de un solo tile, el que esté seleccionado. Para ello, lo único que se hace es actualizar el array con los datos sobre el tile y, después, actualizar la pantalla dibujando sólo la zona que estamos viendo según las técnicas de pantalla virtual vistas anteriormente.
Rutina de la implementación de una rejilla.
La opción de rejilla lo único que hace es dibujar en pantalla los contornos de cada uno de los "tiles" de color negro. No es ningún tema complicado pues lo único que se hace es trazar líneas verticales y horizontales respetando las dimensiones de cada tile, es decir, las dimensiones de 32x32.
Animación de los "tiles".
Uno de los efecto que más pueden llamar la atención, es el referente al tema de la animación del agua. Para realizar este efecto, lo que se hace es utilizar una función de rotación de paleta. Para ello, la podemos llamar utilizando una rutina que se aloje en el vector de interrupciones y que el time la vaya llamando a intervalos de tiempo estándar. Si estamos programando bajo Windows, bastaría con utilizar temporizadores. La rotación de la paleta produce excelentes resultados y dan mucha vivacidad al escenario.
¿Arrays o listas dinámicas?.
Como se citó al comienzo del artículo, esta aplicación tiene ya unos añitos y los cambios que se han ido sucediendo en la misma han estado supeditados al uso personal. En el caso de que queramos construir una aplicación flexible o un juego que utilice niveles de distinto tamaño, deberemos de utilizar, obligatoriamente, listas dinámicas; más concretamente, listas de listas. Las listas van a permitirnos ocupar la memoria que necesitemos en cada momento con todas las ventajas que ello comporta. Al utilizar arrays, estamos predefiniendo el tamaño de nuestros niveles o pantallas por lo que esto se torna muy ineficaz. La única ventaja que aportan los arrays frente a las listas (a parte de su mayor facilidad de implementación), es que son de más rápido acceso pues los datos se almacenan en posiciones consecutivas de memoria. Este artículo no está destinado a comentar las estructuras de datos dinámicas. Simplemente, realizamos una mención a la posibilidad de implementar el engine con estructuras de datos mucho más flexibles y que, de hecho, deberían de ser utilizadas..
Una pequeña mención a las pantallas virtuales o buffers.
Las pantallas virtuales sirven para construir la imagen que debemos de mostrar en pantalla. Por ejemplo, si el usuario se ha movido de un lado a otro de la pantalla, lo que se hace es construir en un buffer, de un tamaño igual al área de pantalla en donde se muestra el mapa, lo que se debería de mostrar después del movimiento. Una vez que se ha construido todo en este buffer, se procede a volcarlo, por medio de alguna rutina rápida, a pantalla. Este método permite construir imágenes compuestas de muy distintos tipos de objetos de una forma muy elegante y, sobre todo, óptima de cara al usuario. En el "Maptool" lo que se hace es construir todo el mapa de edición en una pantalla virtual y luego, mediante la rutina en ensamblador rápida, dibujar o volcar todo rápidamente.
Algunas técnicas más a tener en cuenta
Aún hay algunos cuantos aspectos que podríamos considerar en la construcción de un engine basado en "tiles" (que en el "Maptool" no se utilizan). Ahí van:
Uno de los aspectos que podríamos considerar, podría ser el de dotar al engine de una cuarta capa. Esta capa, sería la que iría por encima de todas las demás (incluso por encima de la capa que cubre los aspectos de objeto) y que cubriría, por así decirlo, lo que está en el aire. Imaginémonos la siguiente situación. Nuestro personaje va caminando y se encuentra con una casa con la puerta abierta (obviamente, deberíamos de construir múltiples tiles que sirvan para crear el contorno de la casa, sus interiores, etc). Cuando el personaje está fuera de la casa, lo que ve no es más que el tejado de la misma y las paredes (dependiendo, siempre, de la pericia del grafista del grupo). Cuando entre en la casa, ¿qué pasará?. Tenemos dos opciones. Una sería cargar en memoria un mini-escenario, en el que se mostraría la casa por dentro. Otra, sería no dibujar el tejado de la casa y ver a nuestro personaje caminando por su interior. Esto último, es lo que nos brindaría la utilización de una cuarta capa de tiles. Como veis, resulta sumamente interesante hacer algo así. De hecho, es lo que se utiliza en la mayoría de los juego. El coste de implementar algo como esto es muy bajo pues tan sólo deberemos de comprobar si el personaje está sobre una casilla que mantiene una casa. Si está, a la hora de dibujarla desecharemos el pintar los "tiles" que forman el tejado de la misma (los que se encuentran en la cuarta capa de "tiles") con lo que siempre veremos a nuestro personaje andando por su interior. Cuando salgamos de la casa, sí que pintaremos el tejado del recinto, dejándonos sin ver lo que hay en su interior.
Otra de las técnicas que pueden resultar muy interesantes, es la referida a la implementación de un sistema que calcule el área de visibilidad del personaje. Como siempre, el problema se divide en un proceso de cálculo interno y otro externo. En el interno, debemos de determinar el cálculo de las casillas que el persona puede ver. Así, por ejemplo, si el personaje tiene una visibilidad de 5 significará que podrá ver en un radio de 5 casillas (5 casillas por cada uno de los posibles lados del personaje). La representación externa hace referencia a la implementación gráfica del problema. Para simular el área de visibilidad, podemos hacer que aquellas casillas que queden fuera del área del visibilidad del personaje se dibujen con algún tipo de niebla (dibujamos los "tiles" y, encima, un "tile" que tenga puntos aleatorios de negro y color invisible) o que sólo dibuje el "tile" de base sin dejarnos saber si hay un río, un personaje, un enemigo, un objeto, etc, encima del mismo.
En conclusión.
En este artículo hemos visto cómo poder implementar engines basados en el concepto de "tile 2D". Aunque este tipo de "tile" no dota de profundidad a nuestros escenarios, puede sacársele mucho provecho si las estructuras que se construyen encima del mismo sí tienen carácter tridimensional (llegando a emular lo que puede ofrecer un engine basado en "tiles" isométricos).
En definitiva, el uso de esta técnica reporta importantes beneficios de cara al desarrollo de juegos de estrategia que tengan que representar grandes escenarios. También resulta muy útil para juegos de aventuras o rol en los que el protagonista deba de caminar por mampeados grandes. Además, otra de las virtudes del uso de "tiles" es que no son complicados de manejar. Ahora bien, resulta ineludible que el grupo de desarrollo se construya sus propias herramientas para el diseño de niveles.
Antes de finalizar el artículo, comentar que aquí se han expuesto las ideas básicas sobre este tipo de técnica y que, con ellas, ya es posible que todo aquel que tenga unos conocimientos mínimos de programación gráfica (en cualquier sistema) pueda hacer su juego o editor basado en "tiles". Comentar a esto último, que es recomendable que trabajéis siempre que podáis, con listas dinámicas y no con arrays pues, de lo contrario, vuestros escenarios no podrán crecer en tamaño y siempre estarán supeditados a un tope.
ÚLTIMA REVISIÓN EN ABRIL DE 1999
|
|