Este proyecto consiste en crear un pequeño y sencillo juego 2D.
- Tienes un punto de partida, un punto de salida y coleccionables para desbloquear la salida. Lo demás es cosa tuya.
- Pequeña animación del personaje y los coleccionable.
- Mostrar por pantalla el número de movimientos.
- Añadir una cartela informativa del funcionamiento e historia.
- Añadir cartela cuando el jugador gana o pierde.
- Mayor complejidad gráfica de los muros: Muro interconectado en vez de un único sprite repetido.
- Esto implicó la creación de 17 sprites única y exclusivamente para los muros, y aún podrían añadirse unos cuantos más para mejor resultado en ciertos casos.
- Lo más importante: Adición de enemigos con movimiento.
En este README sólo pondré el resultado del juego y algún comentario de cosas que me gustaría destacar, a continuación adjunto
mis apuntes en notion por si alguien quiere mirarlos y tener un mayor entendimiento del programa y su creación.
El proyecto se hizo al mes de realizar el cambio a Linux en Madrid, por tanto aún no se había establecido si se permitía el uso de la mlx de Codam, que tiene algunas funcionalidades extras y, sobretodo, permite trabajar sin problemas las imágenes con transparencia en Linux, y es que la mlx en Linux no permite superponer imágenes con transparencia.
Por no quedarme quieta esperando al aviso (que llegó 2 semanas después de que entregara el proyecto) busqué información de cómo sortear este problema. Había dos opciones:
- Crear imágenes sin transparencias
- complicarte la vida y crear funciones que comparen las dos imágenes a superponer (Por ejemplo, el suelo y el personaje) y pinten pixel a pixel.
¿Cómo funciona esto? Yo vi este blog, Pulgamecanica que lo explica muy bien. También me fue muy útil haber visto previamente el video de Oceano en que creamos un programa que "pinta" un cuadro de Pollock, ya que te enseña a crear tu propia versión de mlx_pixel_put(), la función que permite pintar pixel a pixel pero que está prohibida usar.
Muy resumidamente: Conocemos el tamaño que tienen las imágenes. Leemos cada pixel de la imagen a superponer (el personaje). Detectamos el color del pixel, si hay color, pintamos el pixel correspondiente de la pantalla de ese color. Es decir, el mapa es una matriz. El personaje se encuentra en una posición concreta de esa matriz, pero la imagen del personaje es otra matriz, y el pixel que estamos leyendo tiene su propia posición en esta. Un lío de coordenadas vamos.
Si no se detecta color ya que ese pixel concreto es transparente, realizamos el mismo proceso pero con la imagen de debajo, el suelo.
La mayoría de este proyecto lo realicé en casa, por lo que no contrasté las ideas con los compañeros tanto como me habría gustado. Sabía que una parte del bonus era añadir enemigos, y para mí era obvio que los enemigos se debían mover, así que eso empecé a implementar. Luego descubrí que la mayoría de la gente hacía enemigos estáticos, pero ya llevaba más de un día implementando (fallidamente) el movimiento, así que iba a seguir con ello.
Y es que lo difícil no es el movimiento como tal, hacer que un enemigo se mueva es fácil, lo difícil es lidiar con las colisiones entre enemigos.
Tras mucho rebanarme la cabeza, opté por este planteamiento:
-
Los enemigos sólo se moverían de izquierda a derecha, en una misma dirección hasta colisionar.
-
Primero se establece el movimiento de cada enemigo. En este momento hay 4 opciones:
- Si el enemigo o bloque de enemigos se encuentran entre bloques permanentes (muros o la salida), establecen su movimiento a permanentemente estáticos, nunca podrán moverse.
- Si el enemigo o bloque de enemigos se encuentran entre uno o más bloques no permanentes (los coleccionables), se mantendrán como estáticos hasta que el bloque no permanente desaparezca (cojas el coleccionable), creando espacio para moverse.
- Si el enemigo tiene su derecha despejada, siempre empezará el movimiento a su derecha.
- Si la derecha no está despejada, empezará el movimiento a su izquierda
-
La prioridad de movimiento es por orden de lectura de la matriz, es decir, de arriba a abajo, de derecha a izquierda.
-
De producirse colisión, el enemigo emplea un turno de movimiento en cambiar su dirección, turno en que está estático.
Para terminar, sólo quiero decir que el proyecto es mi pequeño homenaje al videojuego Pathologic 2, donde eres un médico que tiene 12 días para intentar salvar tu pueblo natal de una plaga que va a asolar todo. En este juego recoges hierbas especiales y mezclándolas con órganos infectados puedes obtener medicinas y lo más importante, la Panacea.
En mi versión sólo tienes que recoger hierbitas y huir de las nubes de plaga, así que es mucho más sencillo. Finalmente me despido, ¡Adiós!