Echo v1.4: road to season two

[Drumpi]

Hola de nuevo:

Después de meses sin tocar ni una línea de código, he decidido darle un empujoncito al juego, a ver si podemos avanzar algo. Debido a la salida de la RG350, y al intento frustrado de Fede de portar el juego a la BitBoy, me dio por ponerme un rato y añadir el código que necesitaba para configurar la pantalla y los botones de la RG350, y pode rasí ejecutarse... más o menos bien, ya que lo que hice puede considerarse una chapuza (por alguna razón, el Bennu de la RG350 no reconoce el SO como OpenDingux, y sospecho que la BitBoy hace tres cuartos de lo mismo).

Tras esto, me siguieron quedando ganas de programar, así que fui trasladando los cambios, ahora sí, como es debido, al código principal. Ya más o menos he metido todo el código que implementé en el "parche", aunque quedan un par de detalles.

Pero la principal razón de no haber tocado el código, aparte de la falta de tiempo y ganas por pasarme 9 horas al día programando en el trabajo, es que hay un bug en la detección de durezas de uno de los enemigos: los Corvos. Por alguna razón que desconocía, los Corvos eran capaces de volar atravesando los suelos o las paredes desde la última actualización del código. Como ya mencioné alguna vez, el código que controla la detección de durezas alcanza las 2500 íneas de código, si bien en realidad sólo se ejecuta el 15% del mismo, si llega, y depurar semejante monstruosidad necesita de mucha paciencia, dedicación y dosis de suerte.

Y precisamente, con suerte y con ingenio pude dar con la clave. Por un lado, la detección de durezas se separó en 4 ficheros que se comparte a lo largo del código de aquellos enemigos y objetos que usan físicas. Son 4 trozos de código que se "incrustan" dentro del código de los procesos enemigos, directamente. Por otro lado, y es la parte afortunada, aun disponía de esos ficheros en una versión anterior, cuando aun funcionaban. Los cambios no eran excesivamente drásticos, y eran compatibles con el código actual, así que los sustituí para comprobar que con el motor "antiguo", los Corvos aun se comportaban como debían.

Confirmado esto, fui sustituyendo los ficheros uno a uno por los nuevos hasta que volvió a fallar. El tercero fue el que dio la voz de alarma, pero no quise meterme a ello hasta comprobar que el cuarto funcionaba correctamente. Definitvamente el tercero.
Este tercer fichero controlaba el comportamiento del enemigo si cambiaba de tile verticalmente. Tenía sentido, pues los Corvos atravesaban los suelos pero rara vez las paredes. Bien, pues usando Notepad++ (y una doble pantalla, no sabéis lo útil que puede llegar a ser) comparé ambos ficheros y había dos líneas que cambiaban: ambas controlaban una cosa, el reposicionamiento del enemigo si este intentaba atravesar un suelo sólido. En principio no veía nada raro, así que las dejé como en la versión anterior, y todo volvió a funcionar como debía.

Pero el cambio se hizo por algo: era un código que reducía los cálculos a la mitad, y tenía en cuenta la posición y el movimiento del enemigo en pantalla... un momento ¿los movimientos? Ahí estaba la respuesta ¿Por qué sólo los Corvos atravesaban los suelos y no el resto de enemigos? ¡Porque los Corvos tenían un valor cero para la variable "gravedad"! Esa era la clave.

Así que hice un IF: si tenían gravedad, usan los cálculos nuevos, si no, usan los cálculos antiguos, y así todo a funcionar como debía.


Con esto tan complejo ya fuera de la ecuación, he podido seguir con el desarrollo normal: crear nuevos tiles interactivos, nuevos gráficos, continuar con el nivel... pero eso es una historia para otro día.

[Drumpi]

Tendría que haber escrito esto hace ya hace una semana, pero lo de siempre: lo vas dejando, dices que es mucho rato, y al final...
Intentaré ir dosificando la información de lo que he ido haciendo, así, los días que no haga nada, tendré para seguir contando :D

Bueno, empecemos por el principio, porque creo que me lo salté. Una de las razones, quizás la principal, fue que Fede me pidió que portara el juego a la BitBoy. Hice deprisa y corriendo unos cambios y... eso me picó el gusanillo.
Me puse a leer acerca del juego, de cuando lo hice para el concurso. Aun está el hilo en los proyectos del foro inglés, bajo el nombre original del proyecto: Doggy!!! Ahora más o menos sabéis por qué. Luego seguí con este mismo hilo, ya no sólo por la nostalgia, sino porque es una fuente de información de lo que hice y cómo lo hice... más o menos, lo que me ha ayudado a retomar el proyecto por donde lo dejé.

Ya habéis leido acerca del error con el movimiento de los enemigos que ya he corregido. Pues el siguiente paso era añadir elementos que aumentasen las posibilidades de hacer puzles y plataformeo interesante, y aquí es donde interviene un proyecto que fue "cancelado", y que tenía intención de seguir (algo se ha hecho, pero me quería centrar en Echo). Dicho proyecto era, según su director, un clon del Echo, con otro personaje, y que cumpliera las características de cierto concurso que se suspendió por falta de participación.Dicho proyecto, aprovechando que tenía el motor hecho, y que tenía mucho más tiempo libre que ahora, le pude añadir una serie de tiles interactivos muy interesantes: suelos que se rompen, plataformas que aparecen y desaparecen de forma síncrona... Bueno, ya que estaban hechos, sólo había que añadirlo al Echo y... sí, funcionaron desde el primer momento, al menos los dos tipos de bloques que desaparecen al pisarlos, no me quise poner a probar los bloques síncronos por... exigencias del guión... Bueno ¡qué leches! Ya habéis visto que el nivel 3 (en realidad el 4) comienza en un desierto y termina en un agujero en lo que parecen unas ruinas egipcias, que daba paso al nivel de la cueva. El nivel de la cueva ha sido sustituido (más bien, aplazado) por un nivel subterráneo, una especie de pasadizo secreto que comunica la puerta con una entrada secreta a la gran pirámide, pero no penséis que la entrada va a ser sencilla, ya va a tener un pequeño adelanto de lo que nos espera dentro.También voy a adelantaros que la pirámide va a cumplir el mismo propósito que lo que se había diseñado para la "season two", sólo que ahora dicha temporada va a ser una trilogía de episodios. Esta pirámide esconde muchos secretos, y obviamente, un laberinto, pero el secreto más importante es el acceso a las cuevas que ya habéis visto, que serán el segundo capítulo. Las cuevas se ampliarán, usaran los bloques que se rompen, y se complicará un poco más, todo para servir de nexo al tercer capítulo de la trilogía: el "misterio en construcción" :D Lo siento, no voy a desvelarlo todo, y menos si aun no sé hasta dónde voy a llegar :P
Bueno, volviendo al diario, tras añadir y probar los nuevos tiles, era hora de intentar añadir un elemento que se me ha resistido desde los albores de Fenix: crear plataformas móviles. La dificultad reside en que dichas plataformas, además de moverse, tienen que mover al prota, ignorando las físicas normales de las durezas. Por tanto, el primer paso era poder "capturar" al prota cuando intentase atravesar dicha plataforma de arriba a abajo.La parte complicada es que el prota se comporta de forma diferente a la habitual y he creado un nuevo estado llamado "en plataforma", en cuyo caso se ignora la gravedad y actúa como si estuviera parado o andando. Como la plataforma no debe actuar directamente sobre el prota, porque no entiende las durezas del entorno, se me ocurrió un sistema pasivo, similar al que tengo para los golpes: la estructura info_prota ahora cuenta con una variable "plataforma_id", en la que si una plataforma "captura" al prota, pondrá ahí su ID, y ya el prota sabrá qué hacer.En concreto, lo que debe hacer la plataforma es indicarle al prota cuanto "debería" moverse para seguirla, además de su movimiento normal, mientras siga sobre ella.
Aquí se plantean dos cuestiones: como "liberarse" de la plataforma, y cómo afecta el movimiento extra al prota.De momento, liberarse es fácil: si el prota salta, ya no está "en plataforma". Aun quedan dos asuntos por resolver, que son "si se aleja demasiado de la plataforma" (que se caería de ella) o si "la plataforma atraviesa una dureza y posa al prta en un suelo", pero quiero dejarlo para más adelante, porque quiero aprovechar el modo "en plataforma" todo lo que pueda en una zona controlada.Y es lo que nos lleva a la segunda parte: interactuar con las durezas usando el movimiento extra. Mi primera idea era "desplazar" al prota, y luego sumarle el movimiento propio, y las durezas le impedirían avanzar. Pues resulta que no, Echo empezó a atravesar suelos y paredes cual fantasma, vaya horror. Entonces decidí que lo que haría sería sumar las velocidades calculadas de gravedad y aceleración para andar con la de la plataforma... y funcionar funcionó, pero aun hace cosas muy raras, como que no puede acelerar en contra del movimiento de la plataforma.
Aun tengo un poco de lío cerebral con el tema de qué velocidades deben reducirse al contacto con una dureza, si debería mantener la velocidad propia del prota y la de la plataforma unidas, o cómo le podría afectar el cambio de tile.De momento descubrí que si la plataforma se movía hacia abajo, y atravesaba un tile, el detector de durezas activava el estado "en caida" y atravesaba la plataforma. Eso lo he corregido forzando el estado en caso de que "plataforma_id" siga siendo distinto de -1. Pero aun no sé por qué hace algunas cosas raras con la aceleración, o por qué el prota se mueve con 1 frame de retraso. Eso será una historia para otro momento.
En el próximo episodio, hablaré de cómo seguí el desarrollo por otro lado.

[warrior_rockk]

Para el tema del frame de retraso del personaje cuando está en la plataforma (problema típico que se puede ver hasta en los juegos comerciales de consolas de 8/16 bits) tienes que intercambiar la prioridad del proceso plataforma (con la variable local priority) respecto a la del proceso prota para que tenga una prioridad superior la plataforma cuando el prota esté encima y devolverle la prioridad al prota cuando no está en ella.

[oskarg]

Esto me ha pasado en el engine que estoy  haciendo,quería que el prota fuera  a 40 frames y la plataforma a distintos frames y aunque lo aclara se producía un temblor en el protagonista según cuánto avanzaba la plataforma,para salir del paso todo va a los mismos frames, probaré eso de priority más a fondo pues lo hice pero no hacía nada.

Como reflexión debería ya el propio bennugd o derivado de div tener un motor tipo tiles ,pues es lo más laborioso , tengo  tropecientas líneas y me quedan aún más para considerarlo terminado .

[Drumpi]

Sí, eso es lo que hago:
Inicialmente, la plataforma tiene una prioridad inferior que la del prota, porque necesito que el prota se desplace antes de detectar la captura de la plataforma, de forma que si se produce, pueda "recolocar" la imagen del prota (sólo la imagen, no la posición dentro del scroll) antes del final del frame (el renderizado), y luego se pone su prioridad a una superior a la del prota.
En el siguiente frame, la plataforma se mueve, y le manda las velocidades X e Y mediante las variables de la estructura info_prota, como ya mencioné antes. El prota entonces se debería ejecutar, ver que ha sido "capturado", ponerse en modo plataforma, y reajustar su posición de acuerdo a la modificación que le hizo la plataforma en el frame anterior. En teoría, en este frame ignoraría las velocidades (creo, no tengo el código delante), pero no importa que se ignore el primer "impulso" mientras coja los siguientes.

Tengo que verificarlo bien, pero diría que o bien no se está alterando correctamente la prioridad, o por alguna razón, hay un frame de retraso, o una actualización erronea de la posición del prota en el scroll tileado.


Hablando de scroll tileado, en realidad no es tan laborioso... Bueno, un poco lo es, pero después de haber implementado como ¿5 versiones? tampoco es demasiado complejo.
Es cierto que se echa de menos, pero es que no hay aun siquiera un consenso sobre un formato de mapas de tiles. Hay una librería de scroll de mapas de tiles hecha por un forero, no recuerdo quién, y el código fuente de mi scroll está disponible por aquí, por si lo quieres mirar o directamente usar, oscarg.

[oskarg]

Gracias por el detalle,le echaré un  vistazo el domingo que es mi día libre y veré cómo lo has implementado, siempre y claro me aclare con el código  :)

[Drumpi]

Creo que está explicado en el mismo hilo.
Básicamente tengo una lista con un proceso por tile no nulo. Cada vez que la cámara al desplazarse cambia de tile, se comprueba el mapa de tiles, y se modifican los procesos tile (gráfico y posición), borrando de la lista los procesos sobrantes, o añadiendo según la necesidad.
La ventaja es que hay un fichero, add_tile.inc, que es donde va el código que añade el tile a la lista, y puede ser modificado para que, en lugar de generar un proceso tile, genere cualquier otro tipo de proceso, como enemigos, botones o lo que sea, por lo que se puede usar el mapa de tiles más que para mostrar los escenarios.

A la hora de usarlo, he intentado que sea simple: load_tmf, se setean algunas variables, start_tscroll y a correr. Al menos, tan simple como pueda ser el scroll de Bennu, salvando las distancias.

Lo más complejo es calcular la posición de la cámara respecto al mapa, y tener en cuenta si este se repite horizontal o verticalmente.
También hice el típico scroll pintando en un mapa, pero era muy lento, y luego hice un híbrido de pintado en mapa y uso del scroll de Bennu que no recuerdo si lo liberé... o si encontré cierto bug que lo rompía.

[Drumpi]

Buf, lo siento, debería estar actualizando el diario y no lo estoy haciendo.

Sí, el desarrollo del juego sigue adelante. No tan rápido como me gustaría, y estoy viendo que me va a ser imposible  añadir los dos niveles que tenía previsto para la primera semana de Marzo... De hecho, es muy probable que ni siquiera termine uno de ellos, porque a medida que avanzo en el desarrollo se me van acumulando cosas, en lugar de reducirse:

Para empezar, voy a tener que crear un set de tiles nuevo para la tercera parte del nivel egipcio. Tenía pensado usar los tiles ya creados, y añadirle dos o tres nuevos, pero resulta que la ambientación dentro de la pirámide es diferente a la de fuera. Me he documentado, y el interior debería tener más aspecto de templo que lo visto hasta ahora, con colores vivos, jeroglíficos (ya estoy hablando con una experta en el tema para darle un poco de "legitimidad" al asunto... y que si no lo hago, va a dejar de hablarme :D ) y mucha decoración. Voy a intentar reutilizar algunos tiles ya creados, pero estoy limitado a 100 tiles diferentes como máximo, y cambiar esa restricción me iba a hacer cambiar todos los FPGs y un montón de cosas en el código: a partir del tile 100 se generan objetos especiales, y tendría que revisar el código para no meter la pata, y ahora no tengo tiempo para eso.
También he tenido que crear diversos tiles para la segunda parte del nivel, que al ser subterránea, hay tiles que debía "oscurecer". Por fortuna, dispongo de tiles de FBustamante para tal propósito, y su edición no supondrá un problema.

Aun tengo que lidiar con un problema con los tiles de agua, que no puedo resolver, de momento, sin mapas de tiles de 2 capas, y no sé si es buena idea incluirlos ya, porque... vale, mientras se incluya la información en la capa 0, y se deje la capa 1 para tiles normales, no hay pegas, pero hay tiles que al crear un objeto (un enemigo, por ejemplo) modifican el contenido para evitar que esté generándose a cada frame, pero no tienen en cuenta el tema de las capas, y es algo que precisa revisión. Al igual que con lo de ampliar el número de tiles, no tengo tiempo para eso.

Y se le suma que tengo que crear dos jefes de fase, con su IA; dos tipos de enemigos nuevos, con una IA bastante compleja; que hay que reordenar en el código los niveles que se van a ejecutar y, si fuera posible, cambiar la numeración de los niveles, por constantes, para que fuera más simple esta tarea; una sala nueva para el boss del nivel con unas reglas muy específicas... A cada día que pasa se añaden cosas... no nuevas, sino que no había pensado que fueran tan complejas.


Pero dejemos de hablar de lo que falta por hacer, y pongámonos con lo que se ha hecho. Lo voy a hacer sin ningún orden concreto, porque hay tantos detalles que si no, seguro que se me pasa algo.

De vuelta a las plataformas móviles, me alegra anunciar que la mayoría de los problemas están resueltos, o eso creo. El principal problema que estoy teniendo es cuando el prota choca con una dureza, porque esto provoca una variación de las variables internas de velocidad. Como ya comenté anteriormente, las plataformas móviles suman su velocidad a la que ya tuviera el prota, y la idea es que la detección de durezas intente mantenerla, o modificarla en caso de que se choque con algo. Al no ser velocidades separadas, la del prota y la de la plataforma, esta variación de velocidad está provocando efectos no deseados al no ser capaz de distingur si afecta a una velocidad o a otra... aunque creo que eso poco tiene que ver. El caso es que he podido resolver todos los efectos no deseados, como no poder acelerar en dirección opuesta al movimiento de la plataforma, atravesar paredes o suelos, e incluso caer cuando se cambia de tile hacia abajo. Ahora mismo quedan dos cosas por resolver: si se choca con una pared lateralmente, Echo se queda en el sitio, pero hace la animación de andar en lugar de quedarse quieto, y si al bajar la plataforma Echo "choca" con algún suelo (o sea, la plataforma atraviesa una dureza mientras baja) no se pierde el contacto con la plataforma y sigue ligada a ella.
En cuanto resuelva lo de la animación, podré seguir adelante, porque lo otro, de momento, para este nivel, no afecta... aunque debo arreglarlo, claro.

También está implementado la mayoría del código referente a OpenDingux: qué control usar, qué resolución, opciones por defecto, etc. Incluso he añadido lectura de parámetros para el BGDI, para que se pueda forzar el OS_ID, como en el caso de la RG350, que lo detecta como Linux. Lo único que está sin implementar es un proceso para configurar las teclas; ahora mismo se está usando el de PC, que hace uso de SCANCODE, y funciona relativamente bien, salvo para los botones A y B, que por alguna razón, se les asigna el mismo valor, y luego no funcionan.

Y sobre los niveles, el segundo mapa ya tiene terminado la parte de las durezas, por lo que es jugable de principio a fin. Ahora estoy en la parte de asignarle los tiles visibles adecuados, y luego llegará la parte de añadir enemigos, que es la que me preocupa, porque en esta parte hay agua, y ya he dicho que aun no está 100% implementada. Lo peor es que va a haber lava, y no sé qué hacer con las muertes, si va a ser muerte instantánea, progresiva, si hacer que vuelvas al último checkpoint (y cómo distinguirlo de una muerte "normal")... tengo muchas dudas de cómo implementar esto, y me tendré que enfrentar a ello en breve. Me pone de los nervios porque si a la gente ya le parece injusto el actual sistema de muertes, que te deja en el mismo sitio en el que muriste, el tener que hacerles ir para atrás al caer en la lava... Cualquier sugerencia será bienvenida.

Sí, he empezado con el mapa de durezas de la tercera parte... pero no última, ya que la lucha contra el boss va a tener lugar en una sala aparte. Una vez vencido, en lugar de terminar el nivel, como hasta ahora, se volverá al sub-nivel 3, y se completará un camino secreto que nos llevará al nivel 5: el de las cuevas.

Y luego está el tema de la música, que salvo milagro, me temo que van a ser tres "sub-niveles" muy silenciosos, salvo por los bosses. Tengo un comienzo de melodía, pero como ya sabéis, lo mío no es componer música.

Bueno, creo que eso resume, más o menos, por dónde anda la cosa a día de hoy. Quedan 3 semanas para terminarlo todo, y veo que no llego al ritmo actual, pero tampoco es que pueda acelerarlo mucho más, el tiempo que tengo es el que es, y las fuerzas las tengo que dosificar para no acabar reventado, y que afecte a mi trabajo o al juego. Voy a intentar tener, al menos, la fase esta de Egipto para el día 7 de Marzo, aunque tenga que posponer el desarrollo del mid-boss a la siguiente revisión, pero ya veremos cómo se presenta la cosa. Una cosa es hacer recortes, pero si quito demasiadas cosas, no va a tener sustancia :D

[oskarg]

Hola drumpi,
disculpa por mi pereza...pero me puedes poner el link del motor de tiles donde lo pueda compilar y ejecutar?¿?
Otra cuestion,cuantos procesos ,tiles tienes ejecutando a la vez?¿?lo expreso para saber si lo puedo trasladar el motor a divgo sin que afecte a su rendimiento.Todavia no lo veo claro,pues por ejemplo, si tengo un simple mapa de 320x240 de tiles de 8x8.. son 40x30=1200 procesos o tiles solo para la primera capa...me parece que se me escapa algun detalle . :P

[Drumpi]

Pues lo cierto es que haces bien en preguntar.
Aunque hay una versión 3.2.1:
http://forum.bennugd.org/index.php/topic,4294.0.html
Por lo que leo, se le dejó añadida la función que hace zoom al scroll. Si el rendimiento no importa y quieres probar a hacer efectos chulos, usa esa (en el primer mensaje está adjunto). Si no, te recomiendo que pruebes la 3.2:
http://forum.bennugd.org/index.php/topic,819.0.html

Tendría que comprobar si realmente es la última que tengo, pero creo que sí. Si no, te sirve para hacerte una idea.
Traen diversos ejemplos de uso (incluso para un scroll isométrico que se quedó de forma experimental), por lo que empieza por ellos.

Antes de que preguntes, los formatos TMF y TPR los genero con este programita: http://forum.bennugd.org/index.php/topic,4207.0.html
El formato TMG no es más que un FPG, con mapas de 8 o 16 bits, donde cada valor de pixel es el número del tile.

Sobre cuántos procesos uso... eso depende: en el peor de los casos uso (ancho_pantalla/ancho_tile) * (alto_pantalla/alto_tile) * capas (entendiendo por "pantalla" la zona donde se pinta el scroll, no tengo forma de acceder a la información de las regiones), pero puedes añadir filas y columnas de más, por si necesitas que aparezcan tiles "fuera de pantalla". En el mejor de los casos se usan 0 procesos.
Sí, cero. El motor genera un tile, siempre que dicha posición sea >0 (si está vacío, ¿para qué generar un proceso?). Si el mapa tiene muchas zonas vacías, el rendimiento mejorará, y si hay muchos tiles, pues empeorará. Truco avanzado: los tiles no tienen por qué ser todos del mismo tamaño, en ocasiones en el Echo uso tiles de 32x16 para ahorrarme un tile, o de 32x32 para ahorrarme 3 :D Sólo tienes que tener cuidado de colocar el centro del gráfico en la posición (7,7).


Por cierto: si usas la versión del zoom, si no recuerdo mal, el número de procesos tiles varía con dicho zoom. Si haces los tiles más grandes, habrá menos procesos, pero si los haces más pequeños, habrá más.

El Echo tiene una resolución de 320x240 con tiles de 16x16. Aun usando 2 capas, en Wiz he conseguido velocidades superiores a 60fps, pero el juego en sí sufre de ralentizaciones y no he podido determinar si es por culpa del motor de scroll tileado, por la detección de durezas, por la cantidad de elementos en pantalla, por el código de tantas cosas, por las colisiones o la suma de todas ellas.
Sin embargo, en PC, con un AMD K7 1600XP, pude mostrar los 650x50 tiles del nivel 2 en el editor de mapas de tiles al mismo tiempo sin ralentizaciones.
Ten en cuenta que los procesos tile son procesos vacíos, en estado sleep. Haz tus pruebas.

Si tienes alguna duda, no dudes, pregunta :D

[Drumpi]

Bueno, no tengo mucho más que añadir a lo escrito el lunes pasado, porque como he comentado más de una vez, mi trabajo en ocasiones me exige que esté hasta tarde, y llego a casa con tiempo de cambiarme, asear e ir a cenar :D

De todas formas, me he obligado a sentarme aunque sean 30 minutos antes de acostarme y avanzar algo.
Me he centrado más que nada en la segunda pantalla del nivel, para ir puliendo detalles, que siempre se cuentan por decenas y consumen mucho tiempo. He ido decorando el nivel, y creando tiles a medida que me han ido haciendo falta, nada super complejo, pero bueno, ahí van saliendo, e incluso he ido coloreando algunos tiles de la primera pantalla para poder usarlos en la tercera. Ya tengo casi todos los tiles colocados a falta de tres o cuatro que aun tengo que crear, y podré centrarme en añadir enemigos...
Le he estado dando vueltas, y no sé si tengo suficientes enemigos... bueno, o al menos, enemigos lo suficientemente originales, porque no sé si los que desarrollé para la primera pantalla me van a servir para la segunda o incluso para la tercera. Recordemos que tengo gusanos, langostas, la cosa esa que excava la arena, las cabezas de Anubis, los pinchos y las bolas de energía que necesitan un nuevo gráfico para este nivel. Y ahora voy a añadir momias que no se van a poder matar, pero necesito añadir más cosas, aunque reutilice procesos, pero quiero evitar recurrir de nuevo a clichés tipo serpientes, escorpiones, murciélagos...

Voy a intentar priorizar cosas para que salgan los niveles con la mayor cantidad de cosas terminadas, para que sea un nivel interesante, y que no haya que cambiar demasiado su estructura en versiones posteriores.

[Drumpi]

Bueno, pues aquí sigue el informe semanal de avances del juego :D
Ya sé que debería hacerlos más a menudo, pero entre semana no me da tiempo a hacer cosas y escribir :P

Bueno, no he avanzado tanto como me hubiese gustado, pero como ya dije, las cosas son más largas de lo que se planearon inicialmente. En el segundo nivel egipcio, el que ya comenté que tenía las durezas hechas, he estado poniendo tiles en el mapa visible. Obviamente había varios tiles que no tenía y los he tenido que ir haciendo sobre la marcha. Ya los tengo casi todos colocados y he hecho algunas modificaciones porque me he dado cuenta de algunos fallos. Este proceso es lento y prefiero irlo haciendo en varios días, porque suelo encontrar un fallo, arreglarlo, probar y encontrar otro, por lo que repetir este bucle una y otra vez se tarda mucho y es muy tedioso, así que por mi propia salud mental, prefiero arreglar uno o dos fallos, hacer otra cosa, y volver al cabo de un tiempo (obviamente, anotando los fallos que voy viendo).
Hoy ha habido mucho de esto último.
Luego, he ido colocando ya algunos enemigos, para darle un poco de picante al asunto, aunque he de reconocer que el nivel no se diseñó para albergar ninguna fauna :D

Y ya hablando de fauna, he puesto el primer enemigo que se ha diseñado para la tercera pantalla en esta segunda. Es un enemigo implacable, terrorífico e inmortal, así que aprovechando una "zona segura" del nivel, he colocado uno de ellos a modo de "entrenamiento". Hay suficiente espacio para esquivar, disparar y hacer de todo, para que aprendáis lo que podáis antes de enfrentaros a hordas de estos enemigos en pantallas posteriores. También es cierto que se requiere cierta pericia para llegar a donde se encuentra, así que consideradlo una recompensa para los buenos jugadores.

Y ya que añadía un nuevo enemigo a la lista de códigos a cargar, he reordenado un poco el código interno del juego. Básicamente toda la parte de carga de gráficos y de niveles, porque ya no hay nivel 4-1 y 4-2, sino que habrá niveles 4-1 al 4-4 y un quinto nivel, que es el de las cuevas, y todo eso hay que modificarlo. La última limpieza de código ha hecho maravillas ahí, pero aun debo reorganizarlo mejor, porque hay muchos pasos previos para poder ejecutar un nivel, y sigo usando un array fijo para almacenar los códigos de los FPGs cargados, y estoy desperdiciando la mitad del espacio :D

Por cierto, ya tengo listos los gráficos de otro enemigo más. Lo que no me aclaro es qué comportamiento darle, porque al ser acorazado, puede servir de animal terrestre. Puede volar, por lo que también puede servir como los corvos. Y no me cabe ninguna duda de que podría ir lanzando disparos como los Flozat del nivel 3. Me ahorraría el hacer gráficos de nuevos enemigos y usar estos para tener 3 versiones del mismo, pero... no sé.Y quiero usar el código del super guerrillero para crear un enemigo complicado de matar, pero no sé si voy a tener tiempo de diseñar un gato cachas... o un chacal, o un loro, o...

El nivel 4-3 sigue en desarrollo. Iba a subiros una captura de cómo va el mapa, pero al final se me ha pasado ^^U Llevo como un 25-30% del mapa de durezas, y todavía no tengo los tiles visibles. A este ritmo me parece que no me va a dar tiempo a terminarlo. De hecho, estoy valorando muy seriamente lanzar esta versión sólo con la compatibilidad con RG350 y con el nivel 4-2, nada más. No quiero subirlo con una versión inacabada de algún nivel.
Aun así, sigo avanzando, va a ser difícil que esté listo en dos semanas sin dedicarle el esfuerzo de una Game Jam... pero hay que intentarlo. El fin de semana que viene va a tener 3 días, así que puede que le de un buen empujón, si las fuerzas acompañan y la gente me deja trabajar tranquilo. Ya sabéis, cuando es puente, las personas quieren pasar su tiempo libre gastando el de otras :D :D :D

Pero bueno, no todo lo que se ha avanzado ha sido algo tangible. He estado planificando el jefe del nivel. Al principio pensaba en crear un enfrentamiento con un personaje de la vida internetil en plan venganza personal, pero se me ha ocurrido una idea que me ha gustado más. Ya os avanzo que va a ser un homenaje a un videojuego clásico, al que dediqué incontables horas de mi infancia, hasta que le pillé el truco y podía superar niveles una y otra vez sin problemas. Ya el nivel iba a contar con alguna referencia, como uno de los enemigos y la melodía (ahora sólo será en parte), pero creo que este enfrentamiento será a la vez nostálgico y épico. La mecánica del escenario será la misma, pero no la de acabar con el jefe porque... en el original no había jefe, y no se le disparaba para acabar con él. De hecho va a requerir el uso de un arma exclusiva de esta zona, tan exclusiva que no se va a poder usar en ninguna otra parte del juego :D
Ahora os estaréis preguntando a qué juego me estoy refiriendo. Pues no, no os lo voy a decir, y la verdad, dudo mucho que la gente lo conozca. Tampoco quiero dar pistas, porque con dar un par de ellas, ya sabréis cuál es, a poco que conozcáis el catálogo de aquel viejo ordenador... ¡ups! :D
Bueno, ya lo dejo aquí. Es muy tarde, mañana madrugo, y tengo que echar horas para poder salir el jueves y hacer lo que tenía previsto para el viernes, que estará todo cerrado. Iré haciendo cositas sueltas de aquí al viernes, a ver si para entonces tengo los tiles básicos del nivel 4-3 y varias de las funciones que necesito para el jefe de la fase.
Que durmáis bien.

[Drumpi]

Bueno, pues hoy me acabo de echar un jarro de agua fría, yo mismo, y no era ningún "challenge" de esos de Youtube.
Resulta que estaba pensando en que los gráficos de la tercera pantalla de la pirámide, lo mismo quedaban algo sosos si compratían ambientación con los anteriores niveles, aunque tuvieran colores, y estuve echando un vistazo a unas notas antiguas que encontré con ideas para el futuro. Había unas notas escritas sobre la ambientación de la pirámide, que tenían mucho que ver con una idea que me surgió mirando jeroglíficos, y la idea es genial... quizás demasiado extrema, pero eso implica cambiar mucho del diseño de tiles que ya tenía/tengo...
...Aunque pensándolo en frío, en realidad no tengo tantos tiles hechos, no tengo que deshacer nada. Sí que aumenta el número de tiles, pero como ya tenía la idea de dar diferentes tonos de luminosidad a las salas de la pirámide, al final no es tan gordo el problema. Lo es por el tiempo que tengo y la limitación de tiles, que tengo que cuadruplicar los tiles básicos, que son 11, quizás 12.
Hablando de la pirámide, ayer se me quedó en el tintero mostraros una captura de lo que va a ser el mapa de la tercera pantalla. Aquí la tenéis


Sí, como siempre, no me puedo ir a lo sencillo ^^U. En número de tiles, creo que igualaba al nivel de los guerrilleros y los aliens, pero como casi todo va a transcurrir dentro de la pirámide, el área efectiva es de la mitad, y como dije, es un laberinto (espero), por lo que no todas las salas tienen que ser visitadas. También he intentado imitar un poco los mapas que he visto de los interiores, con sus entradas en rampas, sus salas, recovecos, etc, y encima hacer caminos que se entrecruzan, pero no se mezclan.

Volviendo al desarrollo, tengo un problema que no sé resolver, y es que lo ideal es que dentro de la pirámide se tenga un scroll de fondo con una imágen oscura, adornada con jeroglíficos y eso, pero fuera debería verse el mismo cielo superiluminado de la primera pantalla. Como pasaba con el nivel 1-4, eso es fácil hacerlo cuando tienes dos capas de tiles, pero aquí sólo tenemos uno y debo idear algo (tengo pensado algo, pero es un poco cutre, que no es más que poner una imágen azul diagonal persiguiendo al scroll, colocándose estratégicamente delante del fondo de la pirámide cuando estás en la parte de fuera)...
En fin, en el lado positivo, he podido extraer varios tiles que me van a hacer falta en estas dos pantallas de la captura de Fede (ahora me toca diseñar los míos :D ) y he generado el FPG del nuevo enemigo para el caso de que sea volador; si fuera terrestre tiene una animación muy chula, pero debo escoger si quiero mostrarlo porque le pega al nivel, o volver a poner los gusanos por tener una variedad mayor de enemigos.
A ver hasta dónde puedo llegar de aquí al viernes.

[Drumpi]

Buenas de nuevo:

Debo daros malas noticias. A pesar de haberle dado un gran empujón al juego estos tres días, la cantidad de cosas y detalles que quedan pendientes para un lanzamiento que podamos considerar "completo" son demasiados para poder terminarlas para el sábado.
El plan B era poder sacar una versión compatible con RG350, y con al menos una nueva pantalla jugable, pero aunque lo segundo sea posible, lo primero no, pero voy a explicarlo bien.

Este fin de semana le he dedicado bastante tiempo al código, porque aun había bastantes cosas que cambiar para mover lo que antes se conocía como nivel 4-2 (el nivel de las cuevas) al nivel 5, y hacer sitio a lo que es el nuevo nivel 4-2. También quería ir llevando adelante lo que pudiera del nivel 4-4, más conocido como el "escenario del boss del nivel 4", porque había muchas cosas que programar, y bastante complicadas, por lo que para no saturar el cerebro mi método es hacer algo complicado cada cierto tiempo, y rellenar el tiempo de en medio con tareas más sencillas.
En este aspecto se ha avanzado bastante, porque tengo parte del código que modifica el escenario, y parte del código del boss, por lo que puedo estimar que está en un 45% de estar completo.

Pero el problema ha venido por la parte del código de la RG350. El viernes le dediqué buena parte de la tarde a probar el juego en la portátil, y funcionar funciona. Le he tenido que añadir ciertos cambios al código de configuación de las teclas para refinarlo... pero por alguna razón, la función que escanea las teclas (las teclas, no las tet...) hace cosas raras con el "backspace": según la documentación, está asignado al botón R1, y así pude comprobarlo con cierto código que diseñé para su testeo... pero una vez en la consola, al pulsar R1 se configura el botón B. WTF?
Dado que el sistema para depurar que tengo es bastante... cromañónico (compila, copia a SD, métela en el dispositivo, prueba, lee el log, repite), averiguar a ciencia cierta qué pasa me iba a llevar demasiado tiempo. He intentado buscarle un hueco el resto del fin de semana para ir depurando, pero me ha sido imposible, por lo que una compatibilidad del 100% con la consola es inviable en los próximos 6 días.

A eso hay que añadir que aun quedan cosas por programar para que funcione el nivel 4-2 correctamente: tengo que programar la lava, pero tengo el problema de que el sistema de daños del prota me hace muy difícil suministrar un daño continuo (es decir, 1 unidad de daño por frame). Por otro lado, aun no he podido arreglar las dos cosas que quedan pendientes de las plataformas móviles.


Por otro lado, el nivel 4-2 está casi terminado. Aun quedan un par de tiles que están sin hacer, pero por lo demás, está casi completo... pero sin el código que falta no se puede dar por terminado.


¿Y qué pasa con el nivel 4-3?. Bueno, ha seguido avanzando aquí y allá.
Lo que son las durezas ya llevo cerca de la mitad del nivel hecho, aunque no estoy metiendo todas las mecánicas nuevas, y debería estar haciéndolo ^^U De hecho, tengo que programar un par de ellas, que no es que sean complicadas de hacer, pero hay que hacerlas. Tiles hay un montón hechos, pero son todos de tipo básico (paredes, suelos, techos y rampas, sólo para sustituir a las durezas). Hay alguno de decoración, pero aun faltan bastantes por hacer para darle color al nivel.

Y es importante terminar el nivel 4-4 para terminar el 4-3. Como creo que ya comenté, la idea es llegar a una parte del 4-3 que te lleve a la sala del boss, en la 4-4, y al terminar el combate, poder volver y recorrer la última parte del camino.


Como veis, aun quedan bastantes cosas por hacer, y de aquí al sábado apenas voy a poder dedicarle un total de 4 horas sin acabar reventado, por lo que tener algo hecho de cara al usuario final es imposible. Como mucho, podré subir una beta con propósitos de depuración a nivel interno, pero ni por asomo una v1.3.1

Quién sabe si de aquí al sábado ocurre un milagro, pero no soy optimista en ese sentido. Se va a intentar, pero...
Lo siento.

[Drumpi]

Bueno, anoche decidí dedicarle un ratito a escribir algo de código, a ver si podía hacer una prueba preliminar de los tiles de lava... y al final estuve hora y media ^^U
Realmente, el código de los tiles de lava no es demasiado complicado. Lleva más tiempo reservarle un valor dentro del motor de scroll tileado, para que genere dicho tile de forma diferente al de los visibles, añadir el include al proyecto y diversos tratamientos adicionales (como enviarle la señal de pausa, por ejemplo), que el código en sí.
Dicho lo cual, el código base de un tile de lava está hecho, y la reacción del prota también... pero no se ha probado ¿Esto qué significa? Que sólo está hecha la mitad de lo necesario para que funcione :D Nunca subestiméis el tiempo necesario para realizar las pruebas, siempre es igual o mayor que el empleado en escribir el código.

Pero fijaos que digo "código base". Eso implica un tile de lava normal y corriente, un cuadrado rojo con un alpha de 190, que envía un par de valores al prota en cuanto está demasiado cerca. Quiero añadir al tile la capacidad de regular su altura, para poder hacer la superficie un poco más abajo y darle un poco de respiro cuando el jugador intente salir, es decir, que el tile de lava que está en la parte más alta de la piscina, pueda tener sólo 12 pixels de alto que le hagan daño de verdad a Echo.
También quiero poder añadir animaciones. El código ya está hecho en los tiles especiales... animados :D (si os pasasteis la versión anterior, recordaréis las cascadas de agua), pero antes de ponerme con todas esas "pijadas" (traducción para SplinterGU: elementos accesorios que sólo sirven para que quede bonito) tengo que conseguir que funcione la versión más básica: un cuadrado rojo que hace daño en cuanto lo tocas.

Espero poder terminarlo esta tarde y rellenar de lava el nivel 4-2. Con eso estaría casi terminado... salvo por los 30 detallitos que seguro que aun faltan por terminar :P
Y la mitad, relacionados con los gráficos de Fede :D