[Dev-Blog] [Proyecto Isekai] [#15] Segundo sprint

 

 

    Han transcurrido treinta días desde la última actualización que compartí con respecto al proyecto "Isekai" y me complace presentarles los avances realizados desde entonces. Como mencioné en la entrada anterior (https://www.elgeneralfailure.com/2025/11/dev-blog-proyecto-isekai-14.html), tomé la decisión de reiniciar el proyecto desde cero tras jugar al Seven Pirates H de Nintendo Switch.  La simplicidad y efectividad dicho juego me inspiraron a desarrollar un prototipo utilizando Godot.  Y tras un mes este prototipo permitía ya tener a un personaje que se podía desplazar por un entorno tridimensional, escalar muros, volar, gestionar un sistema de grupo, acceder al interior de viviendas, hablar con NPC e incluso interactuar con un mecanismo básico de tiendas.

     A principios de noviembre comencé con la implementación de la pantalla de "Pulsa Start".  Para ello posicioné a Greta, la protagonista del juego, en una celda (actualmente obtenida de Sketchfab, aunque la intención es que finalmente se utilice un escenario modelado por mi: https://sketchfab.com/3d-models/dp3-hw9-prison-room-9d2f42db20814a02a87ad4cc5e031698) y le incorporé diversos detalles.  Por ejemplo, en el menú de opciones, el usuario tiene la posibilidad de activar o desactivar funcionalidades como el "modo gore" (para la visualización de sangre) o el "modo adulto" (que afecta a las físicas de rebote de busto o a la necesidad de realizar trámites administrativos, tales como el pago del IRPF, el IVA, multas o la tasa de autónomos).  Sí, el "modo adulto" busca ser una parodia del modo adulto. Cada vez que se activa o desactiva una de estas opciones, además de generar un mensaje emergente de advertencia, la textura de Greta se modifica en tiempo real, por ejemplo, permitiendo visualizarla magullada y ensangrentada al activar el "modo gore".

     Como se mencionó en entradas anteriores, Greta, la protagonista, es una viajera espacial que sufre un accidente en un planeta habitado por una civilización medieval y,  por circunstancias fortuitas, se convierte en prisionera.  Con el fin de enfatizar la naturaleza fantástica de la aventura, en la que el jugador se enfrentará con figuras políticas, monarcas e incluso deidades, generé una canción haciendo uso Suno que hiciera énfasis en dichos puntos.  Además, implementé que se visualizara la letra de la canción a modo de karaoke, permitiendo a los jugadores seguir la interpretación vocal.

    Como siempre, deseo recordar que el uso de arte generativo se limita a fines de placeholding.  Una vez que se haya determinado la viabilidad del proyecto, procederé a la contratación de artistas profesionales.  No deseo la presencia de contenido generado por IA en el producto final. Otro detalle que no he mencionado, pero que se aprecia en el tweet, es que en dicha pantalla podemos mover el ratón para girar la cámara, además de que la iluminación tiene cierto efecto de inestabilidad para simular ser una antorcha.

   Durante los días siguientes, me dediqué a la modularización de los personajes, con el objetivo de que todos utilicen el mismo esqueleto y las mismas animaciones, permitiendo, al mismo tiempo, la modificación de sus proporciones.  En este proceso, también desarrollé un editor de personajes.  En su estado actual, este editor ofrece funcionalidades limitadas, como la posibilidad de cambiar el aspecto del personaje, la cabeza, las proporciones del esqueleto y la textura del cuerpo, aunque no su vestimenta.

   Asimismo, también desarrollé un sistema cíclico de día y noche, que incorpora la generación procedural de elementos celestes como el sol, las nubes, la luna y las estrellas.

   Y también trabajé en minuciosos detalles, tales como la implementación de la mecánica de que los personajes mantengan contacto visual al encontrarse en proximidad:

   Asimismo, también implementé un sistema de simulación de físicas de rebote para el busto y una nueva interfaz de configuración gráfica, que permite la activación o desactivación de opciones como el SSR, SSO y SDFGI. Para el tema de las físicas de rebote, cabe destacar que normalmente los juegos hacen uso de plugins de spring-bones para simular su movimiento, pero decidí pasar de ellos e implementar mi propio sistema de spring-bones desde cero (con código en C# puro y duro).

    De hecho, jugar con las configuraciones gráficas me generó un punto de inflexión significativo, ya que la incapacidad de mi ordenador para ejecutar el juego en Ultra me impulsó a empezar a trabajar en optimizaciones. Y entre las primeras acciones implementadas incluí la aplicación de distintos niveles de detalle para los modelos, comúnmente conocidos como "LOD".

    Al concluir el mes, llevé a cabo dos mejoras significativas. En primer lugar, tras observar un atardecer un día durante mi trayecto de regreso a casa, me decidí a retocar la iluminación ambiental y el sistema de nubes con el objetivo de lograr una mayor realismo visual. Vamos, que hice las nubes aún más bonitas. En segundo lugar, realicé la adaptación de los controles para permitir la compatibilidad con mandos de consola. Si bien esta tarea pueda parecer trivial, representa un desafío considerable lograr una integración fluida y natural entre el teclado y el gamepad.

    Y estos son los avances que puedo presentar hasta el momento. ¿Y ahora qué? Pues he mostrado el juego a varios compañeros de trabajo, quienes me han señalado que el juego presenta un nivel elevado de sexualización, principalmente debido a las proporciones de los personajes y a la ausencia de un sistema de vestimenta funcional. En consecuencia, he decidido priorizar el desarrollo del sistema de vestimenta en el próximo sprint, así como la implementación de personajes masculinos. Estas tareas ya estaban contempladas en mi planificación, pero su priorización es crucial para evitar que se formen percepciones erróneas sobre la visión final del juego. Adicionalmente, si el tiempo lo permite, me propongo iniciar la implementación del sistema de misiones, el sistema de diálogos y el sistema de combate por turnos.

    En cuanto a las estadísticas del proyecto, tras dos meses de desarrollo, se han alcanzado las siguientes cifras: 38.331 líneas de código, 675 pruebas unitarias automatizadas y cero issues remontados por SonarQube.

 

Decompilan y portan Super Mario 64 a PS1

      Video Game Esoterica ha publicado un video que muestra un port del Super Mario 64 funcionando en la primera PlayStation. Este port ha sido desarrollado por el usuario brasileño Malucard y presenta numerosos errores gráficos, problemas con la cámara y fallos en los controles, como la imposibilidad de agarrar a Bowser por la cola cuando nos enfrentamos a él.  A pesar de estos inconvenientes, el hecho de que el juego se ejecute y se pueda observar a Mario en movimiento constituye un logro significativo.

    Cabe destacar que Malucard no ha desarrollado este port desde cero, sino que se basa en un fork del proyecto de GitHub "Super Mario 64 Port", reconocido por haber adaptado el juego a sistemas operativos contemporáneos como Windows y Linux.  Y éste último, a su vez, deriva del proyecto de GitHub "SM64", que contiene una versión decompilada del Super Mario 64 original.

[ENG] Rerez, Modern Vintage Gamer, My Life in Gaming y MetalJesusRocks analizan la Analogue 3D, la consola de Analogue que emula N64 por FPGA

    Desde las 18:00 horas de hoy, todos los creadores de contenido de habla inglesa especializados en videojuegos retro han empezado a publicar sus reseñas de la Analogue 3D, la consola de Analogue que emula la Nintendo 64 mediante FPGA.

 

[ENG] Microsoft bloquea el uso compartido familiar no oficial en PC Game Pass, impidiendo el acceso a saves en la nube para usuarios secundarios

     Inside Games ha publicado un video en el que se afirma que Xbox ha desactivado la funcionalidad de uso compartido en familia de PC Game Pass, impidiendo el acceso a los datos de las partidas guardadas en la nube para las cuentas que no suscriben el servicio.

      Cabe destacar que, si bien hasta la fecha el uso compartido de Xbox PC Game Pass ha sido posible de manera no oficial dentro del núcleo familiar (permitiendo a múltiples usuarios acceder al servicio en un único ordenador con una sola suscripción mediante workarounds como iniciar sesión en la Microsoft Store con la cuenta suscriptora y en la app de Xbox con cuentas secundarias), Microsoft nunca ha reconocido oficialmente esta funcionalidad para PC, limitándola a consolas a través de la opción "Xbox Principal".

    Según indica Inside Games, los cambios no anunciados en el PC Game Pass han causado problemas en la sincronización en la nube para usuarios secundarios que no son los suscriptores principales, incluyendo fallos en el acceso a servicios en línea y guardados en la nube. Esta situación puede impedir la descarga o sincronización adecuada de partidas guardadas, lo que conlleva, en casos como reinstalar un juego, la creación de un nuevo archivo de partida local considerado como "más reciente" que el almacenado en la nube, resultando en la pérdida de los "saves" más avanzados.

[Dev-Blog] [Proyecto Isekai] [#14] Transformación del proyecto

    Han transcurrido casi un año desde mi última comunicación sobre este proyecto y me complace presentarles los avances realizados durante el último mes.  En primer lugar, debo informarles que el proyecto ha experimentado un reinicio, priorizando el desarrollo de la versión para PC. ¿Implica esto el abandono de mi intención de desarrollar un juego para Game Boy?  Pues digamos que la posibilidad de llevar a cabo este proyecto aún no ha sido descartada, pero, en este momento, considero prioritario concentrar mis esfuerzos en el desarrollo de la versión para PC.

     Para proporcionar un contexto adecuado, el proyecto se encontraba estancado durante un período prolongado y, a finales de septiembre, durante una semana de vacaciones, decidí volver a jugar al Seven Pirates H para Nintendo Switch.  Si bien ese juego es bastante mediocre, posee mecánicas de juego simples y efectivas que me interesaba implementar: un jugador en un mapa tridimensional que puede desplazarse, saltar, interactuar con enemigos para iniciar combates, abrir cofres y utilizar a Otton, una foca rosa de aspecto peculiar, para escalar paredes o cruzar estanques. Consideré que desarrollar un motor que simulara estas mecánicas en Godot no presentaría una dificultad significativa, y con esta premisa, procedí a su implementación. La elección de Godot se debe a que, en el marco del programa de voluntariado de mi empresa, estoy colaborando en el desarrollo de un juego para una ONG. Dadas las restricciones de licencias en motores como Unity o Unreal, Godot se presenta como el entorno de desarrollo integrado (IDE) más seguro desde el punto de vista de evitar sorpresas a nivel monetario (sólo faltaría que hiciera un juego gratis y acabara siendo despedido), lo que me ha permitido adquirir una sólida familiaridad con su uso.

    Mi objetivo inicial consistía en adquirir assets rápidamente, desarrollar una habitación de pruebas donde probar las mecánicas y evaluar el alcance potencial del proyecto.  Prefiero no utilizar assets de terceros ni recurrir a soluciones de inteligencia artificial como Meshy AI. Sin embargo, he hecho uso de ellos con la idea de que sean placeholders para la fase de prototipado y, una vez que el motor del juego se encuentre funcional, procederé a la creación de mis propios assets.  Para contextualizar, la creación de un personaje atractivo en Blender suele llevarme unas dos semanas (aquí un ejemplo y aquí otro), mientras que con Meshy AI puedo tener un personaje funcional, con esqueleto, texturas y animaciones, en aproximadamente una hora, aunque con un número excesivo de vértices y las animaciones parezcan ortopédicas.

    Para ela sala de pruebas empleé el mapa "Sealos Island Town - Map Remake" de Uradamus y como personaje le pasé a Meshy AI una figura de Good Smile Company de Rimuru vestida de conejita (enlace). Con esos dos recursos y varios scripts simples de Godot, ese mismo día logré que Rimuru se desplazara por el escenario e implementé un sistema básico de colisiones con muros.

Sealos Island Town - Map Remake by Uradamus on Sketchfab

 

 

 

 

    Tras tres días más de desarrollo implementé un sistema básico de diálogos. Si bien la implementación de un sistema básico de este tipo puede completarse en una hora, incorporé mecánicas avanzadas, tales como que ambos personajes roten mostrando la animación de "andar" para mirarse a la cara antes de iniciar el diálogo y cuando éste inicia, la cámara cambia a una perspectiva en primera persona con el fin de proporcionar cierto nivel de inmersión. Mi idea es que, en el juego final, la cámara de los diálogos sea similar a juegos de Bethesda como Oblivion, Fallout o Starfield. En este momento ya pasaba de intentar imitar al Seven Pirates y me dedicaba más bien a implementar mecánicas que me divirtieran.

 

 

    Una semana más tarde ya tenía Rimuru corriéndose, aganchándose, saltando, escalando y le implementé también una barra de energía, similar a la de Breath of The Wild y Genshin Impact y varios elementos del HUD que aparecen y se desvanecen dependiendo del estado del personaje. También, para que la animación de correr se sintiera mejor, le aplico una deformación del POV para que se vea más estilo "ojo de pez", a la vez que le pego ciertos tambaleo de cámara para simular los trotes.

    Por cierto, recurrí a Blender para hacer el círculo que mide la energía:

 

 

    Valga la pena destacar que el sistema de escalada me produjo una cantidad muy grande de errores que requirieron varios días de meticulosa corrección.  Si bien el concepto teórico parecía sencillo (proyectar un rayo delante del personaje y escalar el objeto si se detectaba un collider), la implementación práctica resultó en un comportamiento poco natural.  En particular, el personaje podía tener más de medio cuerpo flotando al desplazarse lateralmente o la subida a la cima no quedaba nada natural.  Además, la cámara mostraba un comportamiento errático al interactuar con las normales de las superficies adyacentes, y se producían inconsistencias en los estados del personaje una vez alcanzada la cima (programaba dar un paso, pero como no se tocaba suelo mi motor interpretaba un salto).  Para solucionar estos problemas, implementé un sistema de cuatro rayos: uno en la cabeza, otro en los pies y dos adicionales en cada brazo, con el fin de definir con precisión los límites de la escalada.

    A los doce días de desarrollo implementé una librería DLL en .NET con el fin de separar la capa de mecánicas de JRPG de los scripts de Godot.  Esta implementación permite la recuperación de datos del personaje mediante un fichero JSON.  Adicionalmente, también desarrollé un sistema de pausa con un menú que recuerda al de títulos como Final Fantasy VII y VIII.  Asimismo, concebí el concepto de "Puerta de los Mundos", un sistema de gachas en el que conseguiríamos personajes para nuestra party, aunque aún no ha sido implementado.

 

    Al día siguiente decidí implementar un sistema de vuelo. Mi intención es que determinados personajes tengan la capacidad de escalar, mientras que otros puedan volar, otros curar, etc. Esta estrategia tiene como objetivo incentivar al jugador a utilizar todo su elenco de personajes para lograr la exploración completa del mundo al 100%. Este sistema no me costó mucho de implementar, debido a que meses antes estuve programando un prototipo de un juego basado en el universo de Tanya Degurechaff (enlace).

 

    Un día más tarde implementé un sistema para cambiar de personaje en tiempo real. Los primeros intentos me dieron problemas debido a que cargaba los modelos y sus texturas al vuelo, produciendo parones de uno o dos segundos cada vez que cambiaba de personaje. Lo solucioné creando un diccionario donde cargaba todos los modelos jugables al iniciar la partida.

 

    Con el fin de introducir dinamismo a esa mecánica, implementé el sistema de gachas dos días después y lo estuve puliendo durante esa semana.  Este sistema requiere que el jugador recoja una serie de esferas denominadas "Esferas de Singularidad" que estarán distribuidas estratégicamente por todo el mundo del juego. La obtención de estas esferas permite al jugador adquirir un personaje aleatorio. Esta mecánica está diseñada para fomentar la exploración, ya que recompensa al jugador con un nuevo personaje por su esfuerzo en explorar áreas de difícil acceso, en lugar de simplemente proporcionarle un ítem coleccionable sin utilidad práctica. Esta implementación también requirió una revisión de la arquitectura del diccionario de modelos de personajes, realizando la carga en segundo plano de los modelos "nuevos" una vez que son obtenidos a través del sistema de gachas.

    Dos días después, me puse manos a la obra con el funcionamiento de los interiores. Mi objetivo es crear una sensación de mundo abierto, aunque no lo sea realmente (la magia de la programación, ¿verdad?).  No quiero teletransportes mágicos ni tiempos de carga al entrar en casas, tiendas o mazmorras. Para conseguirlo, hice que las puertas se abran solas automáticamente y que, al entrar en un lugar cerrado, el exterior se vuelva transparente. Para lograr este efecto, desmonté una casa en diferentes partes dentro de Blender, separando la cubierta exterior de las plantas y jugando con las normales de los muros para aprovechar el backface culling. Además, ajustando el alpha de los materiales, le di un efecto de desvanecimiento progresivo a la fachada exterior.

    Los siguientes los dediqué crear y a pulir la pantalla de organización de grupo, pudiendo seleccionar el orden de los personajes de la party, indicar cuales están ella y cuales no e incluso cómo estarán organizados en el combate (sorpresa, mi idea es implementar un sistema por turnos similar al de Breath of Fire II).

    En el día 24 de desarrollo me apetecía hacer algo diferente e implementé una pelota y sus físicas. Además también programé a los NPC para que te devuelvan el balón si detectan que lo tienen cerca. No aporta nada al juego, pero me pareció divertido de programar.

    También aproveché al día siguiente para revisar toda la arquitectura del proyecto, separándolo en tres capas: Una DLL con la lógica general de un JRPG, una segunda DLL con la lógica extendida para este proyecto, sendos proyectos de test unitarios para ambos e intentar que todo lo que esté en los scripts de Godot sean meros glue code (código mínimo para conectar con los distintos componentes). Por ahora no he conseguido minimizar el código lógico de los scripts para que sean 100% glue code, pero ya tengo una base. El prototipo ya iba pillando forma y me apetecía tener un mínimo de organización antes de empezar a picar aún más líneas de código.

    En el día 27 implementé las pantallas de gestión de objetos, de magias (habilidades) y  de estado de los personajes:

   Y para acabar con los avances del primer mes de prototipado, también implementé un sistema básico de tiendas, con los que comprar y vender ítems.

 

    Por cierto, aunque en esta entrada veáis personajes de anime famosos, ninguno de ellos estará en la versión final del juego. Se tratan de modelos creados rápidamente para testear las mecánicas del prototipo.