Vamos a hacer un roguelike #7 | Devlog Burst Apocalypse Classic


 Bueno, esto no es una nueva noticia nueva si alguien ha leído el post anterior pero el desarrollo de Burst Apocalypse 2 se ha pausado de forma indefinida para hacer un 'remake' del primer juego del que por desgracia perdí el código fuente en 2019 un poco antes del confinamiento al cambiar de PC.

Esta nueva versión toma el mundo y el setting del primer juego, pero utiliza otras mecánicas, por varios motivos, el primero es que el hacer el sistema de combate del primer juego requeriría incorporar partes modulares en el sistema de física de las entidades y sobre todo, MUCHOS mas assets únicos, cosa que no iba a hacer porque la dependencia de los assets es uno de los principales motivos para paralizar Burst Apocalypse 2.

Además de lo anteriormente dicho, hace tiempo que he querido hacer un roguelike con estética ASCII tradicional o un juego tipo MUD, pero tengo 0 intenciones de ponerme a programar un sistema que compruebe que comandos ha escrito el jugador para transcribirlo a acciones del jugador.

Este 2024 he estado principalmente jugando a Dwarf Fortress (por supuesto), Baldur's Gate 3, Elden Ring (por el DLC, una obra maestra), Crusaders Kings 3 y Caves of Qud (hay mas juegos en la lista pero los mencionados anteriormente son los que tomo como referencia e inspiración). Cuando hablo de Roguelike tradicional, me refiero al estilo de Dwarf Fortress Adventure Mode y Caves of Qud (de forma retorcida Crusaders Kings 3 también se podría contar, pero solo en aspectos conceptuales, no de gameplay).

En el post, reporte semanal #0, ya enseñé 2 capturas que incluyen la primera habitación del juego, junto con los diálogos de un NPC. Desde entonces he añadido cosas, como implementar la generación procedural de cuevas, cuya demo se encuentra en la web LINK y he corregido errores en la cámara que hacía que no se actualizara correctamente al mover al personaje.

Hay decisiones de diseño y de implementación que me sigo preguntando y experimentando como cuadra mejor con el espíritu y la identidad del juego.

Por ejemplo en esta captura se puede ver las paredes que no deberían ser visibles por el jugador, porque están detrás de otras, al igual que enemigos que no deberían ser visibles desde la posición actual.


Para solucionar esto, la solución es crear el mapa real y el mapa visible, que solo dibuja en pantalla aquellos elementos que el jugador puede ver. Ahora bien, ciertos roguelikes usan un campo de visión con forma de cono y tienen en cuenta la direccionalidad para determinar que objetos se ven y cuales no se ven, aunque en los ejemplos que he mencionado yo anteriormente como Dwarf Fortress y Caves of Qud, los jugadores pueden ver todo lo que tienen alrededor sin importar la direccionalidad en este aspecto, a demás de ambos implementar el sistema de luces para iluminar la oscuridad, que definitivamente no voy a utilizar por razones de lore.

Con el punto anterior quiero decir que al utilizar un framework que he ido personalizando durante mucho tiempo para cierto tipo de juego y ponerlo en otro contexto, surgen dudas y preguntas sobre el diseño del juego que hay que responder. Otro ejemplo de esto, es el hecho de que el jugador no puede atacar de momento, esto es una elección, al entrar en contacto con un enemigo, el jugador pierde salud al igual que el enemigo, quien sobrevive se queda en la celda. Esta decisión recontextualiza el diseño y la planificación de los enemigos, haciendo que el jugador deba de evitar a enemigos para no recibir mas daño del que puede soportar o tomar el riesgo de enfrentarlos.

Lo siguiente a implementar será esa capa para limitar lo que el jugador ve, así como una SIMPLE interfaz para ver la salud y los stats actuales conocidos, una de las pocas mecánicas que traigo de regreso con este DEMAKE de Burst Apocalypse, pero hablaré de eso en el siguiente devlog.


Comentarios

0 Comentarios ¡Sé el primero!