[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. 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 del juego me inspiraron a desarrollar un prototipo utilizando Godot.  Y tras un mes, este prototipo permitía ya tener a un personaje que pueda navegar por un entorno tridimensional, escalar muros, volar, gestionar un sistema de grupo, acceder al interior de edificios 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.

   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, he desarrollado 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.

    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. 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 portean 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.

A pesar de las cancelaciones de preventas, Bandai Namco lista una versión física de Tales Of Xillia Remastered de Xbox Series X para España y Suecia

    De forma inesperada, sin previo aviso, ni comunicación oficial y a tan solo diez días del lanzamiento de Tales of Xillia Remastered, la página web europea de Bandai Namco ha actualizado la información relativa a dicho juego.  En la sección de preventa de dicho título se ha incorporado la disponibilidad de una edición física ("standard") para las plataformas PlayStation 5, Xbox Series X y Nintendo Switch, así como la de una edición digital ("Deluxe") para las plataformas PlayStation 5, Xbox Series, Nintendo Switch y PC (Steam).

 

 

    En dicha sección se indica que la versión física de la consola Xbox Series X debería estar disponible para reserva en Amazon (aunque el artículo ha sido retirado del sitio web y marcado como "no disponible"), Fnac (que ha procedido a la cancelación de todas las preventas del juego, reembolsando a los clientes y bloqueando la posibilidad de compra), Game (que ha modificado el título de las preventas de Xbox Series X, añadiendo la palabra "Cancel" al principio del título, sin proceder a su cancelación), MediaMarkt (que también ha bloqueado las preventas) y XtraLife (que ha marcado el producto como descatalogado, a pesar de que aún no se ha puesto a la venta). Además, para añadir más misterio a la situación, la versión física de Xbox Series X no sale listada si cambiamos el país a Francia, Reino Unido, Alemania o Italia. De hecho, aparece sólo listada para España y Suecia.

 

 

Fnac canceló todas las preventas del juego de Xbox Serires X y devolvió el dinero a los compradores.

 

 

Game no ha cancelado las preventas, pero ha añadido el texto "CANCEL" delante de la versión de Series X.

 

 

 XtraLife marca el producto como "descatalogado" y sólo deja reservar un código de descarga.

 

 

    Desde luego, la preventa de la versión para Xbox Series X del videojuego Tales of Xillia se perfila como una de las más problemáticas en las últimas décadas.  Es inaceptable que, a tan solo diez días de su lanzamiento, los consumidores de Xbox Series X se encuentren en la incertidumbre de no saber si recibirán el producto, si se les cancelará la reserva o si su versión física se transmutará en una tarjeta con código de descarga. Y, para más inri, la ausencia de comunicaciones por parte de Bandai Namco en sus redes sociales sólo contribuye a intensificar la especulación y la incertidumbre.

 

     Todo esto solo aumenta la mala reputación de Bandai Namco, conocida por sus EULAS extremadamente abusivas que obligan a aceptar para poder jugar (si las rechazas, intenta explicarle la devolución al vendedor y por qué se tiene que comer con patatas un juego desprecintado). Entre las condiciones abusivas que exigen se encuentra revocación unilateral de licencia (pueden básicamente quitarte el juego, porque sí), obligarte a destruir el disco físico del juego, exigirte indemnizaciones, actualizar la licencia con nuevas condiciones, suspenderte el acceso a contenido virtual (como ítems, monedas in-game o partidas guardadas), robarte un gameplay o dibujo y publicarlo como suyo (te obligan a aceptar la renuncia de derechos morales) y para más inri sus licencias tienen cláusulas de post-terminación (debes de seguir aceptando lo acordado incluso si ellos te quitan la licencia de uso o si matan el juego).

Enrique (Eurogamer) enumera, una a una, todas las mentiras de Microsoft sobre Xbox

¿Cuánto duran los discos de nuestras consolas (y por qué aún funcionan muchos de hace décadas)?

    En una entrada reciente analizamos la vida útil de los cartuchos de Nintendo Switch (enlace), estimando que, a falta de confirmación oficial, podrían tener una duración aproximada de 20 años (en condiciones normales). En esta ocasión nos centraremos en la durabilidad de los juegos basados en discos. ¿Es necesaria esta entrada? La entrada sobre Switch surgió a raíz de la publicación de diversos shorts y TikToks que desinformaban. Esta entrada es una continuación que considero necesaria, ya que durante años se ha publicado en prensa seria una serie de artículos con información inexacta sobre la durabilidad de los discos ópticos. Algunos afirman que estos se deterioran en un plazo relativamente corto (20 años), lo cual es exagerado. Si bien la putrefacción de los discos es un fenómeno real, la afirmación carece de precisión. Por lo tanto, al igual que en el caso de los cartuchos de Switch, en esta entrada abordaremos y desmentiremos ciertos mitos.

Mi reacción al ver al enésimo TikToker desinformando.

 

    Cuando uno habla de discos, lo primero que piensa es: "si los cuido, me duran para siempre". Error. El plástico, el metal y la óptica no son inmortales. Pero tampoco son papel higiénico: En condiciones decentes, un disco puede vivir más que el propio lector de la consola e incluso que el propietario del juego (tú). Vamos por partes.

La vida promedia según generación (tened en cuenta que son estimaciones):

• PS1, Saturn y algunos juegos de PS2 (CD-ROM): Entre 20 y 50 años. Larga durabilidad, pero muy fáciles de rayar. Tienen una única capa metálica (la capa de datos) reflectante muy cerca de la superficie superior. Eso significa que cualquier rayón en la parte de la etiqueta puede exponer o dañar directamente los datos.
• Dreamcast (GD-ROM): Entre 20 y 50 años. En cuanto a tecnología son similares a los CD-ROM, pero admiten más capacidad.
• Xbox original / PS2 / Xbox 360 (DVD-ROM): De 30 a 50 años. Más capacidad, pero misma fragilidad física que un CD-ROM: Un rayón puede ser la muerte instantánea. Los DVD salieron 15 años más tarde que los primeros CD-ROM, por lo que benefician de procesos de prensado más refinados, materiales de mayor pureza y adhesivos más estables. Se añadieron recubrimientos protectores mejores que los CD-ROM/GD-ROM, reduciendo el riesgo de microarañazos y contaminación.
• PS3, PS4, Xbox One (Blu-ray): En teoría 40 a 100 años, especialmente porque la capa protectora empleada para este medio es mucho más resistente a rayones y suciedad.

    Si consideramos el caso que en teoría tiene una vida útil menor (20/50 años), podemos observar que estos superan en durabilidad a los cartuchos de Switch. Mientras que los cartuchos de las consolas actuales (Switch, Evercade, etc...) se basan en memorias flash de tipo NAND, susceptibles a fugas de electrones en sus células electrónicas (los "ceros y unos" que forman los bits, para simplificar), los discos se graban con un patrón de surcos sobre una superficie. La interpretación del valor 0 o 1 de un bit se determina según la altura de la pista. Estos surcos físicos no presentan fugas con el tiempo (a diferencia de las memorias flash de tipo NAND) y, además, están protegidos con distintas capas puestas únicamente para ese fin, su protección, lo que prolonga su vida útil muy significativamente. No obstante, si se produce un rayón físico, la capa de datos puede verse dañada, impidiendo que los lectores de disco detecten correctamente los bytes de los archivos afectados y, en consecuencia, haciendo que el juego resulte ilegible para la consola. 

    Ahora bien, ¿cuantos años durarán tus juegos? Pues todo depende en gran medida de las condiciones de almacenamiento. Dejar los discos expuestos a la superficie los hace más susceptibles a la humedad y al deterioro, mientras que almacenarlos apilados en una tarrina puede propiciar la aparición de rayones. La mejor opción para preservar su estado óptimo es guardarlos en sus cajas originales y lejos de la luz solar directa. Los rayos UV degradan la capa protectora de policarbonato y, en el caso de los discos regrabables, también afectan al tinte de la capa de datos. Si están dentro de sus cajas y éstas están expuestas a la luz solar, en principio el disco no recibe los rayos UV, pero la cubierta de la caja puede sufrir de sunfade (efecto por el cual una portada pierde viveza, contraste y saturación, quedando con un aspecto "lavado" o apagado), por lo que el disco no sufriría daños, pero su caja tendría una portada (o lomo) venida a menos. Si se almacenan los juegos en sus cajas y en un lugar sin exposición directa a la luz solar, su estado de conservación es bastante bueno. Para mejorar aún más su preservación, se podrían almacenar en ambientes oscuros y considerar el uso de bolsas de plástico para aislarlos aún más de la humedad, siempre que el ambiente no sea extremadamente cálido.

    Cabe destacar que la calidad de los materiales empleados en la fabricación de los discos influye notablemente en su durabilidad. En comparación con un disco pirata grabado en 1999, los originales presentan una resistencia considerablemente mayor: Mientras que el pirata puede fallar en apenas una década, el original es un tanque que puede conservarse en óptimas condiciones durante un periodo mucho más largo. Esto se debe a que los discos grabables que quemamos nosotros mismos suelen estar compuestos por materiales de baja calidad, propensos a la oxidación y a la proliferación de hongos con mayor facilidad, lo que acelera su deterioro (se pudren más rápido). A su vez, es lógico pensar que la durabilidad de un disco grabable (quemado por nosotros mismos) también depende de la calidad de los materiales del propio disco: En general, los discos grabables de marca blanca y de bajo coste suelen ser los primeros en deteriorarse.

    Sin embargo, es importante distinguir entre la vida útil promedio de un soporte óptico (CD-ROM, DVD de doble capa, Blu-ray...) y su uso real. Existe una realidad bastante incómoda: ciertos lectores de consola son más propensos que otros a rayar los discos durante la lectura. Un caso famoso fue el de algunas versiones de Xbox 360, donde se documentaron casos de consolas que llegaban a rayar los discos de forma muy notoria (enlace 1, enlace 2). De hecho, el conocido youtuber Austin Evans publicó recientemente un vídeo en el que adquiría una Xbox 360 de segunda mano que le dañó dos discos (enlace, minuto 16:18). Microsoft, consciente del problema, ofreció en la década de los 2000 un programa de sustitución de discos rayados (enlace). Otros lectores problemáticos se encontraron en determinados modelos de PS2 Slim (cuya acumulación de polvo podía rayar los discos durante la lectura) y en las Xbox originales con lector Thomson. Si utilizas habitualmente discos originales para jugar en tus consolas retro, te recomiendo que te informes sobre el lector de tu consola para determinar si se trata de un modelo más propenso a dañarlos.

    ¿Y qué pasa si el lector deja de leerme los discos de la consola? ¿Se pueden sustituir? Pues, en caso de que el lector de discos de la consola falle, su sustitución es posible, aunque la dificultad varía según el modelo. En consolas como PS1, PS2, Sega Saturn o Dreamcast, la sustitución del lector no presenta mayores inconvenientes: Desmontar, reemplazar y rearmar. Sin embargo, en consolas más modernas como Xbox clásica, Xbox 360, PlayStation 3, PlayStation 4 y modelos posteriores, el lector está vinculado al sistema DRM de la consola, lo que complica su sustitución. Es decir, para esos modelos el lector está vinculado a su consola original, lo cual, para quienes no estén familiarizados con el hacking en consolas, implica la necesidad de recurrir a un servicio técnico. En resumen, a mayor modernidad de la consola, más complejo resulta el proceso de sustitución del lector.

    ¿Y si hablamos del mantenimiento de discos? Youtube y TikTok están llenos de shorts donde enseñan a revivir discos usando pasta de dientes o lápiz labial. En relación con el mantenimiento de discos, estos dos métodos pueden parecer efectivos a corto plazo, pero que a largo plazo resultan perjudiciales para el disco. La pasta de dientes puede ocultar rayones superficiales temporalmente, pero al ser un abrasivo leve puede dejar residuos y microabrasiones que deterioran el disco con el tiempo. Por otro lado, el lápiz labial, al ser una grasa con pigmento, puede cubrir rayones por refracción, pero se derrite con el calor del lector y ensucia la lente (lo cual es una mala idea). Si tienes que recurrir a estas técnicas para jugar a tu juego, mi consejo es que te plantees hacer un backup del disco y jugar desde él (que no explicaré cómo hacerlo por razones obvias), pulirlo o bien buscarte un reemplazo de segunda mano. Y esto lo digo porque, con los discos difíciles de leer, el lector intenta leer la pista varias veces, recalibrando el láser y moviendo el motor, lo cual produce un desgaste constante. Piensa que tu lector es un componente mecánico, susceptible de fallar con el número de usos, y que cuanto menos trabaje, menos desgaste sufrirá con el tiempo.

    Y para finalizar la entrada nos queda por abordar un último punto y es el elefante en la habitación: El pulido de discos. Y menciono esto porque, además de estar en relación con el párrafo anterior, he observado en Youtube vídeos de tiendas en línea que han adquirido pulidores de discos para mejorar la apariencia estética de los juegos que comercializan (enlace). Por lo tanto, si adquieres un juego de segunda mano donde el disco está perfecto estado, sospecha (en especial si el estado del disco no es acorde con el de su caja). Pero, ¿qué pasa aquí? Pues el problema está en que esto no debe de hacerse únicamente por fines estéticos, ya que consiste en reducir el grosor de la capa de policarbonato (la capa protectora) eliminando los rayones que interfieren con la correcta lectura de la capa de datos. Esto mejora la legibilidad del disco; sin embargo, a largo plazo, este proceso incrementa la exposición del disco a la humedad y al deterioro interno. En otras palabras, el pulido puede prolongar la vida útil del disco en situaciones críticas, pero reduce su esperanza de vida general y lo hace más susceptible a futuros rayones (debido a que cada pulido adelgaza la capa protectora de policarbonato). Es importante destacar que el pulido de un disco no debería realizarse generalmente con fines estéticos, sino para solucionar problemas de lectura. Si su disco es ilegible en la actualidad, acortar su vida útil mediante el pulido para poder seguir utilizándolo se considera un mal menor.

 

Los cartuchos de Switch no son eternos (y jugarlos no los revive)

 

    Por si no lo sabíais, los cartuchos de Switch tienen fecha de caducidad, aunque no esté escrita en ninguna parte (y esto a lo mejor se tendría que legislar). Y no es un problema exclusivo de esta consola: Lo mismo ocurre con los cartuchos de Nintendo DS, 3DS e incluso con los cartuchos de PS Vita y Evercade. La tecnología que usan estos dispositivos, basada en memoria flash NAND, tiene una vida útil limitada y, aunque duren décadas, no son eternos.

    Últimamente me he topado con varios vídeos y tiktoks que aseguran que, para evitar que estos cartuchos mueran, basta con meterlos en la consola de vez en cuando y jugarlos. Su teoría es que la consola los "mantiene vivos", puesto que ésta reescribe en las celdas de la memoria del cartucho. Spoiler: Eso es un disparate. La Switch no reescribe los cartuchos, ni los rejuvenece mágicamente. Esa idea es un mito. Los cartuchos de Switch son de sólo lectura: Salvo sorpresa, la consola no los reescribe y, por ende, no se regeneran.

    La verdad es más sencilla (y menos mágica): No es cuestión de usar un cartucho o no, sino de que esta tecnología no fue diseñada para durar siglos. Los cartuchos de Switch, como cualquier dispositivo basado en memoria flash NAND, tienen una vida útil estimada. Y lo más importante: Estos cartuchos están pensados para jugarse, no para quedarse eternamente precintados en una estantería.

    Entrando en detalle, los datos en un cartucho moderno se guardan en celdas electrónicas que mantienen atrapados electrones. Estos electrones son los unos y los ceros que componen los bytes y, por ende, su contenido. Con el tiempo, esos electrones se escapan (fuga eléctrica), y los datos acaban corrompiéndose (al no saber interpretarse si una celda X representa un cero o un uno, los ficheros se leen mal). Puedes verlo como las ruedas de tu bici: Aunque no uses tu bici, sus ruedas se desinflan con el tiempo. Usar tu bici no hace que las ruedas se reinflen, pero puedes pillar un bombín y reinflarlas.

    Se calcula que la vida útil de un cartucho de Nintendo Switch ronda los 20 años. Puede ser más, puede ser menos: No hay una duración oficial por parte de Nintendo y su vida depende de la calidad del chip, del almacenamiento, del uso, del calor, la humedad... Pero, en todo caso, no son eternos. El reloj empieza a correr desde el día que el cartucho sale de fábrica, lo uses o no.

Y ya hay ejemplos cercanos:

• Cartuchos de Nintendo DS que hoy no arrancan, sin motivo aparente (enlace).
• Wii U muertas porque su memoria interna se degradó sola, sin tocarse (enlace).

    En su día, bastantes títulos de 8 y 16 bits (Zelda, Secret of Mana, Fifa 96, etc...) usaban una pila de botón soldada a la placa para guardar la partida. Realmente la pila no "guardaba", si no que más bien alimentaba de forma constante la memoria volátil (SRAM) donde se guardaban las variables. Treinta años después, esas pilas están agotadas. Los cartuchos siguen funcionando, pero ya no guardan. Repararlos requiere cierto mantenimiento: Abrir el cartucho, desoldar la batería agotada y reemplazarla por otra. No es un proceso complicado, pero puede dar miedo a cualquiera que no haya usado nunca un lápiz soldador. Ahora bien, esos juegos viejos se "escribían" con silicio en memorias ROM, las cuales sí que son casi eternas y rara vez se estropean.

    ¿Por qué he sacado el tema de las baterías? Pues porque el hecho de que un cartucho dure unos veinte años no debería verse como una tragedia. Dos décadas dan tiempo de sobra para jugar, rejugar, compartir y atesorar esos títulos. Lo que no tiene sentido es tratarlos como fósiles intocables, como si su función fuese estar en una urna de metacrilato. Los cartuchos se hicieron para jugar. Y como todo dispositivo electrónico, un día dejarán de hacerlo. La mejor forma de honrarlos no es guardarlos como reliquias, sino jugarlos mientras viven. Existen coleccionistas que guardan juegos precintados de Switch como inversión, pero la realidad es que un juego precintado también tiene fecha de caducidad. El plástico seguirá intacto, pero sus datos, dentro del cartucho, acabarán muriendo. 

    ¿Significa esto que en el futuro dejarán de existir cartuchos de Switch jugables? No necesariamente, existe algo bastante fantasioso que podemos probar. Al igual que existen empresas de criogénesis que se ofrecen a congelar tu cuerpo para descongelarte en un futuro donde se encuentre una cura para tu problema, podemos realizar un backup de nuestros cartuchos (que no diré cómo hacerlo por motivos obvios), con la esperanza de que algún día exista un método para reescribirlos y restaurar los datos de nuestros cartuchos "rotos". De momento es más un deseo teórico que una realidad práctica (estos cartuchos están compuestos por una flash NAND cifrada + pequeñas secciones de EEPROM para control/seguridad). Pero, de conseguirse, aunque la memoria flash envejezca y los datos se degraden, nuestro "cartucho descriogénizado" seguiría vivo, como si nada hubiera pasado. Ojo, no os estoy invitando a compartir vuestros juegos por internet, si no a haceros una copia de seguridad privada para restaurar en el futuro el producto original (lo cual, a día de hoy, no se puede hacer).

    ¿Y la alternativa digital? Aquí la cosa tampoco es mucho mejor. Confiar en la eShop es como poner tu esperanza de vida en manos de una aseguradora: Depende únicamente de la bondad de Nintendo mantener sus servidores vivos durante décadas. A eso hay que sumarle que tanto la Switch como su sucesora tienen un espacio de disco ridículo (32 GB y 256 GB, respectivamente), que obliga a tirar de tarjetas SD. Así que sí, la idea de los backups como criogenización digital puede sonar soñador, pero la alternativa oficial tampoco ofrece garantías reales de preservación a largo plazo: Vivimos en un mundo donde se te cobra hasta por rechazar cookies, donde se te obliga a borrar tu cuenta si rechazas las modificaciones de una EULA (no ese broma, pasa en Xbox) y donde tampoco sería descabellado imaginar, aunque suene amarillista, un futuro distópico en el que Nintendo nos haga volver a pasar por caja, aunque sea con un "precio simbólico",  para seguir accediendo a juegos que ya compramos, con la excusa de mantener vivos los servidores.

     Seguramente habrá ahora mismo gente que esté pensando en la piratería como solución a estos males.  No obstante, la piratería tampoco es la solución: Cada cartucho lleva una firma digital y Nintendo ya tiene mecanismos para detectar consolas o dispositivos que usan copias no autorizadas o firmware modificado, lo que acarrea el riesgo añadido de poder quedar vetado de sus servicios online. Además, regrabar o clonar cartuchos oficiales con backups de dudosa procedencia conlleva riesgos legales y prácticos que varían según la legislación de casa país. Por eso, hacer un backup privado de tus propias compras es una aproximación mucho más razonable desde el punto de vista de preservación.

 

Actualización: Para la consola Nintendo 3DS existe una herramienta no oficial y experimental (https://github.com/skawo/GodMode9-with-Cartridge-Fixer) que verifica la integridad de los datos en un cartucho e intenta repararlos, en caso de corrupción, mediante el mecanismo de corrección de errores integrado en el chip NAND flash del cartucho (ECC), de forma similar a lo que hacen los ordenadores con sus discos duros. Esto genera esperanzas de que, en el futuro, surja una solución equivalente para cartuchos de Nintendo Switch. Sin embargo, la verificación solo detecta los errores y en caso de haberlos la reparación es reactiva y limitada: El ECC corrige un número limitado de bits por sector, ya sea cuando se supera el umbral de errores o cuando se detectan bloques defectuosos permanentes. Si, tras 20-500 reintentos fallidos, el hash permanece sin cambios, el ECC marca los chunks como irrecuperables. De hecho, según reportes en el foro de GBATemp, la tasa de éxito de esta herramienta con cartuchos "corruptos" es parcial (~50% de éxito).

    Como se detalla el repositorio de GitHub de la herramienta, la Nintendo 3DS ya ejecuta esta verificación automáticamente cada 10.000 lecturas, al insertar el cartucho y al apagar el sistema y es probable que la idea de que los juegos "permanecen vivos" con uso frecuente provenga de esto, ya que el uso regular activa más verificaciones y refreshes. No obstante, esta función es solo reactiva (actúa una vez detectada la corrupción, solo para 3DS), con resultados variables: puede requerir múltiples intentos (incluso más de 8 por cartucho), no garantiza éxito en casos graves y no previene daños irreversibles por envejecimiento del NAND. En pocas palabras: El famoso "refresh" intenta arreglar datos ya corruptos, cuando lo bonito sería que machara los "1" por "1" y los "0" por "0", bit a bit, para evitar así la fuga de electrones antes de que se produzca una corrupción. Por lo tanto, jugar diariamente durante años no asegura que el cartucho permanezca intacto indefinidamente. Ahora bien, más vale tener esto que nada. No obstante, lo único que podría "salvar" un cartucho es llegar a crear una herramienta que "formatee" su contenido cargando nuestros backups en él (y por ahora no existe).

     Entonces, resumiendo en plan sencillo de entender: El control que hace la 3DS cada 10.000 lecturas sirve para mirar si algún sector del cartucho se ha estropeado. Si solo hay unos pocos bits cambiados, la consola los corrige sola; si hay demasiados, ese sector ya no se puede salvar y queda muerto.  El resto de la memoria, sin embargo, sigue perdiendo carga de electrones poco a poco con los años. Por eso, aunque juegues mucho o aunque un día cojas el cartucho olvidado, lo metas y llegues rápido a esas 10.000 lecturas para que la consola intente arreglarlo, el resultado final será prácticamente el mismo: cuando pasen 20/30 años la mayoría de los datos tendrán tantos errores que ya no habrá forma de recuperarlos.  En definitiva, jugar con frecuencia no alarga de verdad la vida del cartucho; solo retrasa un pelín lo inevitable: Los refrescos regulares extienden la retención efectiva, pero solo mientras los errores sean corregibles... una vez que la degradación física es avanzada (después de ~10-15 años), ni los refrescos salvan bloques muertos. El "refresco" te puede dar un par de años de gracia en el mejor de los casos, pero no una década.

 

Tales of Xillia Remastered: Las tiendas europeas cancelan las preventas de la versión física de Xbox

     Sin previo aviso y con un EAN ya asignado (3391892031713), las tiendas europeas han empezado a cancelar las preventas de la versión física para Xbox Series X del Tales of Xillia Remastered, el cual está previsto que salga el 31 de Octubre.

      Además de esto, sitios como TodoConsolas han retirado la página del producto y otros como Fnac o Amazon han bloqueado su preventa, mostrando un simple aviso de "Producto no disponible".

 

 

     Esta versión aún se puede reservar en sitios como Game o XtraLife, pero, sin una comunicación oficial de Bandai Namco, parece que el juego se lanzará exclusivamente en formato digital para Xbox Series X. A esto se suma que el juego no está listado en la tienda de Xbox como “Xbox Play Anywhere” (opción que permite acceder a la versión de consola y PC con una única compra), por lo que los usuarios de la próxima consola portátil ROG Xbox Ally tendrán que jugarlo en la nube o adquirirlo directamente en Steam. Cabe destacar que, para poder jugar en cloud a la ROG Xbox Ally, hay que pagar una subscripción de Game Pass Ultimate o tener una Xbox Series propia ejecutando el juego.

    Todo esto solo aumenta la mala reputación de Bandai Namco, conocida por sus EULAS extremadamente abusivas que obligan a aceptar para poder jugar (si las rechazas, intenta explicarle la devolución al vendedor y por qué se tiene que comer con patatas un juego desprecintado). Entre las condiciones abusivas que exigen se encuentra revocación unilateral de licencia (pueden básicamente quitarte el juego, porque sí), obligarte a destruir el disco físico del juego, exigirte indemnizaciones, actualizar la licencia con nuevas condiciones, suspenderte el acceso a contenido virtual (como ítems, monedas in-game o partidas guardadas), robarte un gameplay y publicarlo como suyo (te obligan a aceptar la renuncia de derechos morales) y para más inri sus licencias tienen cláusulas de post-terminación (debes de seguir aceptando lo acordado incluso si ellos te quitan la licencia de uso o si matan el juego).

     Pero aquí no acaba la cosa: La estrategia comercial de Bandai Namco resulta tan cuestionable que, a un mes del lanzamiento del juego, su página web no menciona ninguna versión física, ni siquiera para PS5 o Nintendo Switch, permitiendo las preventas únicamente en formato digital, por lo que existe el riesgo de que las preventas del formato físico de Switch y PS5 también sean canceladas y que en Europa este juego esté disponible sólo en formato digital.

 

La NASA confirma haber hallado indicios de restos de vida microbiana en Marte

    El hallazgo fue compartido con la comunidad científica hace un año y no se ha encontrado otra explicación posible a la existencia pasada de vida microbiana en Marte.

[Blender] Nazuna (Backstabbed in a Backwater Dungeon)

    En marzo os presenté un primer esbozo (blockout) del modelo de Nazuna (enlace), uno de los personajes secundarios de Backstabbed in a Backwater Dungeon. Esta serie, cuyo manga he estado coleccionando mediante importación desde Estados Unidos, verá estrenada su adaptación al anime en octubre de este año. HIDIVE ha adquirido los derechos de distribución, por lo que es probable que en Europa esté disponible a través de Netflix. Mi objetivo inicial era finalizar el modelo en marzo, pero por diversas razones lo dejé en suspenso. Finalmente lo he retomado hace dos semanas, aprovechando para rehacer por completo el blockout, pulirlo y finalizarlo.

Nazuna, from Backstabbed in a Backwater Dungeon by hamster_ruso on Sketchfab

 

 ¿Quién es Nazuna? Bueno, Nazuna es uno de los aliados más poderosos de Light, el protagonista de (atentos al titulazo) “Backstabbed in a Backwater Dungeon: My Trusted Companions Tried to Kill Me, But Thanks to the Gift of an Unlimited Gacha I Got LVL 9999 Friends and Am Out For Revenge on my former party members and the world”, también conocido como "Backstabbed in a Backwater Dungeon".  La narrativa sigue a Light, un joven traicionado y dado por muerto, quien se transforma en un formidable antagonista con la intención de eliminar a sus antiguos compañeros, similar a la trama de Kill Bill, y de paso, destruir el mundo. Esta información no constituye un spoiler, sino una conclusión que se puede extraer tras la lectura del primer volumen.

   El caso es que Light termina abandonado en lo más profundo del Abismo, la mazmorra más letal del mundo. Esta situación, sin preveerlo, le provoca una fuerte alteración en su factor de suerte (buffer positivo), lo cual resulta sumamente beneficioso para su poder: la capacidad de obtener gachas infinitos. Al lanzar su hechizo de gachas, obtiene una tarjeta que puede materializarse en un objeto, un arma o incluso en una persona. De hecho, gracias a esta alteración en su suerte, a base de gachas logra construir una fortaleza, obtener un armamento de élite y un ejército de aliados de nivel 9999 (el máximo) a su servicio. Entre esos aliados se encuentra Nazuna, quien es probablemente el personaje más fuerte de toda la serie.

    Nazuna destaca por su gran fuerza, su largo cabello plateado, sus llamativos ojos rojos, su pesada armadura (que en la adaptación al anime ha sido aligerada) y por blandir una gigantesca espada más grande que ella. Sin embargo, no se deje engañar por las apariencias, ya que es capaz de eliminar a enemigos de altísimo nivel utilizando únicamente sus puños. Digamos que es una especie de mezcla de Noelle de Genshin Impact y de Son Goku (es igual de bruta y de irresponsable que él).

 

    Con todo ello, os comparto varias capturas de la versión preliminar en Blender y de la versión subida a Sketchfab.

 

A modo de retorno de experiencia, ¿qué cosas he aprendido realizando este modelo?

 

Vincular Nurbspath a Armatures a través de una Constraint de tipo "Child Of"

    Si como yo hacéis la cabellera de los personajes con nurbspaths o las pestañas con segmentos simples con modificador de skin,  sabréis que vincular este tipo de objetos a un armature para hacer el rig (la articulación) es toda una tortura. Pues resulta que a este tipo de objetos puedes aplicarles un "constraint" (restricción) para que sean hijo del hueso de un objeto de tipo armature. Al hacer eso las coordenadas se recalcularán y os destrozarán la composición, pero podéis hacer en el botón "Set Inverse" para recuperar la posición inicial. De esta forma resulta muy sencillo poder animar pelos o cejas.

 

Añadir objetos vacíos para utilizar de pivote en los modificadores de Mirror

    Supongo que os habrá pasado ya de liarla con el orden de los modificadores, del estilo que mueves la melena de un personaje en una animación y como el orden de los modificadores no es el correcto se pierde la simetría. Lo que he aprendido es que, en vez de utilizar objetos pivotes (como cabezas o torsos), podemos crear un cubo, posicionarlo como pivote (por ejemplo en el centro de la cabeza o en el centro del torso), borrar todos sus vértices (es decir, dejar el objeto vacío), añadirle una restricción de "Child of" como he mencionado antes para que esté vinculado a un hueso y utilizarlo como pivote para los modificadores de Mirror. De esta forma evito sorpresas como la ya mencionada.

Pivote "genérico" sin restricción de "Child Of":

 Pivote con restricción de "Child Of":

 

Cuando te ofusques, revisa los libros de dibujo de Taco

    ¿Proporciones inusuales en la cabeza o los brazos? ¿La cabeza de tu modelo parece un gato y el torso un pollo? Si encuentra dificultades al retrabajar su modelo, te sugiero analizar a artistas como Taco. De hecho, Pascu, de Destripando La Historia, me recomendó uno de sus libros, el cual se ha convertido en una de mis principales referencias. No hace falta que calques el estilo de Taco, pero si estas bloqueado, te servirá para pensar cómo reimplementar la topografía de tu modelo. De hecho, apreciaréis que el modelo final de mi Nazuna se parece muy poco al que os presenté en marzo.