[ Dudas sobre el curso de programación de juegos ]

planteamiento mapa "pacman"

Hola! Quisiera preguntarte como plantearias un mapa del clásico "pacman". Te hago ésta pregunta porque el mapa es irregular y no me sirve el usar casillas de mismas dimensiones como en otras ocasiones, en este caso algunas casillas son de 16x16 y otras de 8x8...

Yo había pensado en dibujar el mapa con las primitivas de dibujo, lineas, pixeles... y detectar colisiones buscando un pixel de un color en concreto. De ser así, como comprobariamos la colision con este pixel? Se te ocurre otra manera que no sea esa?

Saludos!

Por una parte, el que una figura sea de 16x16 en un laberinto de 8x8 no es problema, porque una imagen de 16x16 se puede descomponer como 4 figuras de 8x8.

Por otra parte, si usas una rutina de solapamiento de rectángulos, puedes comprobar si colisionan dos imágenes de cualquier tamaño.

La colisión a nivel de pixel, tanto si dibujas usando primitivas como si usas un mapa de casillas, supone que revises cada una de las 16x16 posiciones del personaje para ver si cada uno de esos puntos corresponde realmente a un punto amarillo del personaje y a la vez a una casilla de fondo (a la que no podrías desplazarte) o a un fragmento de fantasma (que supondría perder una vida).

Un problema añadido es que además del fantasma rojo, tienes frutas como cerezas o fresas, que también tienen color rojo, pero deben darte puntos en vez de matarte (aunque eso es fácil de resolver, basta jugar con la paleta de colores, para que dos "colores hardware" distintos se vean igual, o bien usar dos colore muy parecidos -pero no iguales- si la paleta es suficientemente amplia).

En mi caso, yo descompondría todo en casillas (tiles). Creo que es mucho más sencillo así. He adelantado el tema del curso que habla del PacMan (digo... PicMan ;-D) por si quieres ver mi planteamiento y eso te da alguna idea:

http://www.nachocabanes.com/videojuegos/ipj/ipj41.php

Como curiosidad, el juego original no usaba colisión a nivel de pixel, sino que comprobaba la posición "central" del personaje, lo que podía llegar a provocar en casos muy esporádicos que "atravesaras" un fantasma, si tu posicion central y la del fantasma se intercambiaban en el momento adecuado. Tienes los detalles (en inglés) aquí:

http://home.comcast.net/~jpittman2/pacman/pacmandossier.html#CH3 - What Tile Am I In

gracias nacho! he empezado a leer el nuevo apartado "ipj41" y nada mas ver la imagen de como esta compuesto el mapa me has solucionado las dudas! no se por que me imaginaba las casillas del mapa de 16x16 y claro, así no me cuadraba la cosa jeje.

saludos y gracias de nuevo!

Si, la opción de dibujar una "rejilla" de The GIMP es una buena ayuda para "descubrir mapas de casillas" en este tipo de juegos, Y más sabiendo que suele bastar con probar tamaños múltiplos de 8 (típicamente 8, 16 o 32).

Si te apetece crear el mapa y hacer un esqueleto de juego a partir de la entrega 4 del miner, te lo publico en el curso con tu nombre. ¿Te apuntas? Yo ese tema no lo voy a ampliar todavía, porque en un día o dos publicaré una nueva entrega con la resolución de la forma de cambiar de niveles en el Miner (apartado 37), y el planteamiento de los Scrolls (apartado 45). El tema del PacMan tendrá que esperar hasta primeros de septiembre, y ya estaré desbordado de trabajo, lo que quiere decir que quizá se demore aun más, así que cualquier contribución será bienvenida.

Eso está hecho! Ya tenía las imagenes cortadas (16x16) y el mapa dibujado en un programa hecho por mí, en cuanto pueda lo hago sobre tu base del miner y lo subo ;-)  

El motivo por el cual no use tu base es porque flojeo bastante sobre la POO, así que voy a tener que empaparme un poco de ésto que ya va siendo hora...

En cuanto al mapa, el pacman tiene 32 tipos de casillas diferentes, así que definir cada una con una letra es muy dificil para aclararse... yo lo que he hecho es un array bidimensional de enteros del 1 al 32, siendo por ejemplo el "1" la imagen "1.bmp" y así sucesivamente.

Si se te ocurre otra manera mas sencilla para que podamos interpretar el mapa del fichero que cargamos con el fopen suéltalo y sinó pues lo hago con éste método y le meto el array de numeros a saco  :-)

Saludos!

El problema del array de enteros es que inicializar un array en C es trivial, pero en C++, si es como parte de un proyecto formado por muchos fuentes... puede no compilar, porque considere que lo has declarado varias veces (una vez por cada momento que incluyas el fichero ".h" correspondiente, mira el aparatado 34 para más detalles).

Hay "trucos", como declarar el array (pero sin contenido) en el fichero ".h"

Puedes probar. Si no, ya sabes que la solución más simple puede ser un fichero: o bien de texto puro (tienes 32 tipos de casillas en este juego, pero entre letras minúsculas, mayúsculas, cifras y símbolos de puntuación básicos tienes más de 70 símbolos), o bien de cifras numéricas. Eso sí, yo suelo tener la manía de, cuando uso cifras numéricas, poner todas con dos cifras, de modo que el array quede bien tabulado y sea fácil de comprobar.

Es decir, yo haría algo como

r-------
|......
|.R__S.
|O!  !.
|.

o bien algo como

01,02,02,02,02
03,04,04,04,04
05,04,06

(se podría quitar las comas, ya que todo es de ancho 2, pero así es más fácil cotejar con el diseño en papel -o la captura de pantalla, en este caso-)


En cuanto a la programación orientada a objetos... en programas grandes es vital. Los hace mucho más fáciles de:

- Diseñar, porque se "ven" los componentes y sus relaciones, al crear una serie de diagramas iniciales.

- Crear, porque se puede repartir trabajo con facilidad, además de que hay herramientas que te generan un esqueleto de programa a partir de esos diagramas iniciales.

- De mantener, porque cada bloque de programa tiene una misión clara, así que es más fácil saber por dónde ampliar cuando es necesario, y detectar fallos cuando se producen.

Como ejemplo, durante este curso escolar hemos creado un acuario en modo gráfico (imitando uno de los jueguecillos de Facebook), con peces que nadaban de un lado para otro, plantas cuyas hojas se movían, adornos estáticos, burbujas que subían serpenteando... en no mucho más de 100 minutos. Yo les dije "quiero hacer esto, vamos a hacerlo con las clases que veis en este diagrama, aquí teneis las imágenes capturadas". Ellos eligieron tareas (por parejas), y en una clase de 2x50 minutos el acuario ya estaba bastante avanzado (en C#, que es menos propenso a errores que C++).

Vamos, que si te llama el mundillo de la programación, en cuanto te acerques a proyectos grandes, tendrás que pensar en objetos o perderás mucho más tiempo corrigiendo que creando. Sólo es mi opinión...  ;-)