Echo v1.4: road to season two

[Drumpi]

Perdón por el silencio de... ¿radio? Bueno, el caso es que tampoco hay mucho que contar, porque estos días he estado muy liado por temas ajenos, ya no sólo del trabajo.

Pero vamos a lo que importa.
Sí, finalmente empecé a probar las colisiones, y por supuesto, no funcionaban, así que me tiré un buen rato intentando ver por qué fallaban. Cuando lo hicieron, pues me dio por ponerme con la rotura del bloque: hice una animación sencilla, básicamente creé cuatro procesos que eran lanzados en 4 direcciones, a los que les afectaba la gravedad, y al llegar a la parte de abajo de la pantalla, desaparecían. Hice algunas pruebas, con diferentes tamaños, diferentes velocidades y diferentes velocidades de rotación y quedó algo curioso, mucho más vistoso que el que desaparezcan los tiles sin más.

Hablando de lo cual, y después de ajustar mejor los tamaños de las explosiones, me puse a probar qué tal se manejaría el lanzamiento de bombas. Creo que ya lo expliqué antes, pero tengo problemas con la carga del disparo, porque el teclado no me permite usar Z, X y dos cursores al mismo tiempo, lo cual es extremadamente problemático. Tengo que darle una vuelta a eso y buscarle una solución cuanto antes, porque si no, voy a tener que prescindir de la fuerza de lanzamiento.
Pero a pesar de eso, estuve probando con una pared de ladrillos, y hay una jugabilidad interesante ahí, teniendo que saber cómo romper los ladrillos, y teniendo puntería, para poder hacer escaleras, pasadizos... me ha molado, y me ha traído recuerdos del Tails Adventures.
De hecho, si os acordáis, ya mencioné que había desarrollado otra bomba antes que la de ahora, que me había salido por accidente. Pues si hago que se pueda detonar con una segunda pulsación del botón de disparo, pues tenemos las bombas remotas, y eso da muchísimo juego. Me gustaría poder añadirlas más adelante como las "Fox bombs" o algo así.

Poco más he hecho dese entonces. He podido comprobar que los disparos normales también me habrían servido para romper las paredes (en un análisis previo, me decía que no, que estos colisionaban con la pared y perdían la energía antes de ser detectados por el tile). He hecho algún ajuste extra y ya está. También he estado investigando diversas animaciones de explosiones, para diseñar un par de ellas para los niveles 1 y 2 de la explosión, y dejar, de momento, la que ya tengo para el nivel 3.
Lo cierto es que ahora no sé por dónde seguir, porque tenía pensado que el arma para derrotar al boss 4 también se disparara cargando el disparo, pero visto lo visto voy a tener que rechazar la idea. En fin, ya veremos.

De momento tengo que terminar un par de cosas, puede que esté sin escribir unos cuantos días. Ya os contaré entonces cómo va la cosa.

[Gabysantof]

Hay alguna demo de este proyecto? Para los curiosos jeje

[Drumpi]

Buenas de nuevo:

He tenido que darle otro parón al desarrollo... y a venir al foro ^^U Cuando el trabajo se pone intensito...
Bueno, antes de enrollarme: demo no, lo que hay es versión completa en mi página de GameJolt, la 1.3.algo (recordemos que estoy intentando crear la 1.4)
https://gamejolt.com/games/the-amazing-adventures-of-echo/170481

A ver, que por qué este parón... Bueno, este verano no he tocado el ordenador, como hago todos los veranos (y qué bien me ha venido), y a la vuelta, pues tampoco había ganas ^^U. No, pero el motivo principal ha sido que, como todos los años, debo terminar un juego paperactivo, y esta vez me he propuesto acabar uno que empecé en el lejano 1990 y muchos, junto con un colega: una cosa a medio camino de un GTA y un juego de rol de Mortadelo y Filemon. A día de hoy, el juego base está acabado, pero aún me queda una semana para añadidos y otras cosas que he querido mejorar en estos años (minijuegos para ganar dinero, más NPCs...).
También he medio metido un proyecto para hacer un vídeo sobe cómo construiros una Game Paperactiva 2, una consola de cartón que hará las delicias de vuestros hijos e hijas. Ahora mismo está grabado todo el proceso y el guión escrito. La semana que viene me pondré con el "voice over" y la edición.


Bien, respecto al juego, pues buenas noticias: parece ser que si en lugar de usar los botones Z y X para el salto y el disparo, uso X y C, ya no tengo el problema de la carga del disparo, por lo que puedo seguir el desarrollo, tan pronto como cambie los botones por defecto en PC (y guarde mi nueva configuración :P).
Por lo demás, no hay más que contar. Puede que alguna noche haya puesto un par de pixels en la animación de la lava, pero poco más.

Vienen días de poca actividad en este sentido: temporada alta en el trabajo, las visitas navideñas, terminar el vídeo, y ya veremos si no hay otro proyecto paperactivo metiendo baza también. De todas formas, intentaré dedicarle algún ratillo los fines de semana. Ya os iré contando.

[Drumpi]

Bueno, voy a actualizar esto un poco, que está muy desangelado :D

Ciertamente, en este tiempo no he podido avanzar con el Echo, se me han juntado varios factores que me lo han impedido.
Para empezar, como siempre, el trabajo, que parece que en Navidades vamos a tener una temporada tranquila, especialmente yo, que me dedico al desarrollo y no suelen pedir nada nuevo para esta época, pero se han juntado una serie de tareas urgentes con un desarrollo que he tenido que acelerar para solucionar otros... total, que me tienen trabajando al 110%
Por otro lado, como ya comenté. este verano y otoño se ha despertado mucho interés por la "Game Paperactiva 2", una "consola" de cartón que hice para algunos de mis juegos paperactivos, y que ha gustado a algunos chavalines y padres ociosos, así que decidí hacer un vídeo de cómo se hace. Quiero mantener el vídeo lo más sencillo posible, pero ya sabéis, yo soy yo, y si no me complico de una manera u otra, pues no estoy tranquilo. Por cierto, ya llevo la introducción, los materiales y las medidas, estoy por la parte de los cortes, a falta de la pantalla, el doblado y las conclusiones, aunque constantemente vuelvo atrás para hacer revisión... y aún no tengo ni una música de fondo ^^U

Pero bueno, al menos hay alguna novedad. No quiero dar falsas esperanzas a nadie, pero estoy haciendo pruebas a un "port" que ha hecho SplinterGU para una beta de BennuGD2, y de momento pinta bien, quitando algunos detalles, fruto de ciertos comportamientos que han cambiado de una versión a otra, pero me parece increíble que un juego tan ¿complejo?, bueno, más bien "completo", funcione al 98% sin muchos cambios (o al menos, es lo que parece). Quizás es demasiado prematuro decir 98%, pues apenas he podido avanzar una pantalla del juego. Ya iré informando... a SplinterGU :D

En cuanto pueda terminar con el vídeo, a ver si le puedo dar un empujoncito más al juego.

[SplinterGU]

maravilloso! (la version de bennugd2, es oficial, en desarrollo...)

[Drumpi]

Bueno, tras varias pruebas con la versión modificada del Echo que ha hecho Splinter, he podido sacar algunas conclusiones:

Primero, el juego (en la segunda versión que me ha pasado Splinter) funciona casi perfectamente hasta donde he podido probar. Hubo una primera versión en que los "fades" fallaban, porque los hago "a mano" (empleo una imagen pintada en negro, para distintos efectos de transparencia, como que la pausa deje el juego más oscuro pero no en negro), y es que el color 1 ya no es el negro opaco, al cambiar los colores de RGB 565 a RGBA 8888 (ya no hay modos de color de 8 o 16 bits). En la última eso está corregido.

Segundo: que hacer un port no es algo que se pueda hacer de forma directa. Hay cambios en los tipos de dato (los antiguos INT eran de 32, los nuevos son de 64), en el manejo de las posiciones en pantalla (ahora se usan decimales), en la gestión de controles, hay que crear una gestión de rutas (las partidas las guardo en la carpeta /save junto a los binarios del juego, pero por lo visto, algunos sistemas exigen el uso de una ruta específica de usuario), y la que peor me ha sentado, hay que reescribir todo el tema de colisiones.

El juego usaba collision. Bueno, primero comprobaba si había algo lo suficientemente cerca para hacer colisión, y luego hacía dicha comprobación. El caso es que las colisiones eran "pixel perfect". Eso, en BennuGD2 ya no existe, y las colisiones se hacen en base a primitivas, por tanto, en el port se estaban usando colisiones cuadradas con el gráfico, lo cual, en el 90% no es problemático, porque eso significa una caja de colisión mayor para eliminar enemigos... pero también para que te hagan daño por contacto. No suele ser un problema porque los gráficos están bastante ajustados, pero en lugares donde te tienes que situar entre dos enemigos muy juntos es especialmente problemático.
Donde la cosa se vuelve crítica es con los jefes. Usan sprites enormes, y la mayoría con formas irregulares, con huecos y salientes, y que el gráfico entero sea una caja de colisión es injusto para el jugador.
El peor caso se lo lleva "Gravor", el dragón de la pantalla 1-3: para acabar con él, hay que dispararle al interior de la boca, hasta que sufre el suficiente daño como para que levante la garra y deje su torso al descubierto. El caso es que la boca tiene un par de gráficos invisibles (alpha = 0) que hacen de barrera, e impiden que pasen los disparos al interior de la boca, que tienen la forma de la parte exterior del hocico. Pues al usar todo el gráfico, al abrir la boca, los disparos hacen colisión con la parte "no pintada" de las durezas, y evitan que alcance el interior de la boca, por lo que nunca sufre daño, nunca levanta la protección, y el jefe se vuelve invencible... que ha sido lo más lejos que he llegado.

"Bueno, pues lo corriges y ya está".
Ojalá fuera tan sencillo. Actualmente estoy en mitad del desarrollo de la versión 1.4, y la que ha usado Splinter es la versión que se lanzó para el aniversario, por lo que hay muchos cambios que no están en el port, así que, para empezar, tengo que terminar la v1.4 antes de pensar en hacer un nuevo port.
Por otro lado, ya dije que intentaría que el juego fuera aún compatible con Wiz (ya que fue la plataforma objetivo desde el inicio), y a  día de hoy, BennuGD2 no es compatible, lo cual es problemático para mi. He estado preguntando en GP32Spain, y sí que parece que hubo una SDL2 para Wiz, porque en una lista de compatibilidad (no sé si oficial) se dice que "fue compatible en algún momento", pero no sé si sigue en mantenimiento. Habría que preguntar en los foros de OpenHandhelds, que es donde están los de Pandora, y el que creo que hizo el port de SDL2 a Wiz.

Bueno, para ir concluyendo, he hablado con Splinter, y se le han ocurrido un par de ideas que podrían mejorar el rendimiento del scroll tileado. Intentaré implementarlo lo antes posible, antes de que se me olviden, y a ver qué resultados obtengo, pero como digo, estoy muy liado últimamente y apenas tengo tiempo ni ganas. 

[Drumpi]

Buenas de nuevo, traigo noticias (sin exclamaciones, esto no es para tirar cohetes :D)

No sé si lo sabéis, pero durante el verano se ha organizado un concurso de minijuegos para la GP32, y cómo no, cuando queda poco tiempo para la entrega, es cuando me entran ganas de ponerme con algún otro proyecto distinto al que tengo que hacer :D
Al final no he podido terminar el minijuego (apenas tengo hecho el motor), pero han ampliado el plazo para participar hasta el 31 de diciembre, por lo que si alguien quiere desempolvar el Fénix 084, aún está a tiempo. Aprovechando la ampliación de plazo, quería terminar el vídeo que estoy haciendo del Dani Chase, que le quedan los créditos y pulir detalles, así que este fin de semana me he puesto... con el Echo ^^U

Bueno, el sábado no fue el único día que estuve con el Echo, ya la semana pasada le metí mano a un par de cosillas, y lo cierto es que traigo muy buenas noticias para los que aún lo jueguen en la Wiz. Aviso que los siguientes tres párrafos son cambios internos al motor y pueden ser muy aburridos para los que busquen cosas relacionadas con el juego, y no de la programación en sí.

Estuve revisando varias cosas del motor de scroll tileado por mi cuenta (no recordaba que tenía el código que me mandó Splinter), para ver si podía optimizar la función que actualiza el scroll cuando hay cambio de tile, ya que esta provocaba que hubiera tirones en el desplazamiento en la consola portátil.
Pues bien, el primer cambio que hice fue mover el bucle que recorre los datos del mapa de tile por capas al interior de los bucles de filas y columnas. Como este bucle no realiza ninguna instrucción propia (salvo incrementar el contador Z), al meterlo dentro de los otros dos, ahorramos que estas se repitan por cada capa que haya en el scroll, lo cual ya es un ahorro importante de cara a los mapas multicapa.
Pero claro, la última versión lanzada no usaba (aún) los mapas multicapa. Así que estuve revisando y, otro cambio que hice fue omitir la llamada a la función "obtener_tile" del motor de scroll tileado, que se ejecuta dentro del triple bucle que mencioné antes, y en su lugar copié directamente el código de la función. Estilísticamente no se debe hacer, porque se repite código, y a la hora de hacer mantenimiento, si se cambia código en un lado, hay que repetir los cambios en el otro...

Pero vaya cambio. El scroll ya no pega tirones, va suave independientemente que se esté desplazando dentro de un tile o se esté cambiando. No he implementado un cambio que me sugirió Splinter, de cambiar la lista enlazada de nodos Tile (o más bien que cada proceso tile enlace con el siguiente) por un array de memoria con REALLOC y procesos tile durmiendo, porque son cambios mayores que requieren darle una vuelta con más tranquilidad, y quizás generar una versión nueva del scroll... Aparte, que no sé qué impacto tendría en la Wiz, tener procesos dormidos sin usar, por un lado, de cara a buscar procesos tile, o algún tipo de envío de señales a estos procesos... y por otro, el tener más procesos en memoria de los que estoy usando.
También hay que tener en cuenta el impacto de REALLOC, porque si lo uso para hacer incrementos de unos pocos tiles (10, por ejemplo), y en el primer frame lo tengo que ejecutar 15 veces para tener disponibles 150 tiles, eso puede provocar un tirón. Es un ejemplo muy extremo que dudo que se de durante el juego, porque lo normal es mantener una cantidad media de tiles todo el rato, lo máximo que se va a añadir es una fila o una columna de tiles por capa (un mínimo de 15 y un máximo de 40, dado que es raro que el scroll se desplace más de un tile por frame), y nunca se eliminarían nodos ni procesos tile (quedarían dormidos).

El caso es que, viendo el cambio que se ha producido al cambiar las llamadas a una función por escribir el código directamente, hay otra función que es llamada decenas de veces por frame, y sólo contiene dos líneas: la que convierte coordenadas del scroll tileado en coordenadas de pantalla. Son sólo dos líneas, que contienen una multiplicación y una suma cada una de ellas, y son invocadas por todos los procesos dentro del scroll, una vez por frame. Si el simple hecho de quitar la función de obtener tile ha dado tan buenos resultados, creo que el omitir esta otra en las decenas de procesos enemigos que hay en pantalla puede mejorar muchísimo el rendimiento, pero odio la idea de no usar una función, dado que son ya más de 30 procesos diferentes los que la llaman, y cualquier modificación implicaría una pesadilla a la hora de mantener. Así que tengo dos opciones: o usar "include" en los procesos enemigos para añadir las dos líneas desde un fichero de código aparte, lo cual es feo de narices, o usar algo que creo recordar que se implementó en BennuGD en sus últimas versiones: una suerte de funciones pre-declaradas o algo así, no recuerdo cómo iba, a ver si SplinterGU me puede refrescar la memoria.

Pero bueno, dejemos las cosas aburridas a un lado, porque aquí habéis venido a saber qué cambios se le han hecho al juego.
Bien, pues resulta que, no sé si lo dije, el boss del nuevo nivel 4 debe ser derrotado con un arma que sólo podremos utilizar durante su combate, al estilo del cañón de Phazon de Metroid Prime. El sábado estuve realizando ya la implementación del arma en el código. Inicialmente iba a hacer un reemplazo del proceso "arma" por el de la nueva, pero ya había empezado el código para añadirlo al final de la lista de armas normales, y de no hacerlo así, sería un enorme problema de cara a la interfaz de usuario, pues depende del proceso "arma" y de los distintos arrays de datos globales que maneja (arrays de gráficos, arrays de animaciones, arrays de niveles de experiencia...).
En fin, que me he puesto con el proceso de coger el arma, y de su recarga, que debe hacerse en un punto concreto de la habitación del boss, y más o menos funciona. Aún me queda por añadir algunos gráficos de obtener el arma (que a ver cómo lo hago, si estos los generaba desde DIV2, y tengo la imagen del W98 en la máquina virtual corrupta), de la recarga del arma, y del arma en sí, pero otra tarde de trabajo como esa y la tendré lista.

Hablando de interfaz, estuve repasándola y aproveché para arreglar unos bugs y corregir algunas cosillas. Por lo visto, el código no permitía subir más de un nivel de experiencia el arma, y eso estaba provocando que las nuevas armas, al coger items de los gordos, hiciera estragos en la barra superior, y en algunos casos, hasta crashear el juego. Ya está corregido, pero debo optimizar el código un poco más, que se ve feo.
Y por esto, amigos míos, aunque en programación os digan "esa situación nunca se va a dar", no hagáis caso y haced las cosas bien, porque os va a ahorrar muchos quebraderos de cabeza en el futuro.

¡Ah! Dos apuntes más: he encontrado un error que hace que al cambiar la configuración de los controles, los botones arma sig. y anterior se guarden intercambiados. Creía que era cosa de la RG350, pero ya he visto el problema y lo he solucionado (un cambio en el orden de la declaración de unas constantes). También he cambiado los controles por defecto: Z y X ya no son salto y disparo, sino X y C. De no hacerlo así, la diagonal arriba-izquierda mientras saltamos con el botón de disparo pulsado, sería imposible, y es necesario para las dos nuevas armas que estoy desarrollando. Esto no afecta a Wiz, pero sí a los usuarios de PC con un teclado "normal".


Al final, no han sido más de 6h de trabajo en los últimos dos fines de semana, pero ha cundido. No sé lo que habré estado haciendo en los últimos años, pero puedo ver fallos en el código del Echo que antes no sabía ni que existían, y puedo verlos con muchísima claridad, así como sus posibles soluciones. No van a hacer que el juego mejore de cara al usuario, pero me permitirá optimizar algunas cosillas, aclarar un poco más el código, y facilitar el mantenimiento.
Debo terminar el vídeo en el próximo fin de semana, pero quién sabe, lo mismo termino el arma que estoy haciendo.