19 años en Internet

04 noviembre 2025

[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, potencialmente resultando en pérdida de progreso en local.

02 noviembre 2025

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

 

 

 
    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.

21 octubre 2025

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

27 septiembre 2025

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


 

25 septiembre 2025

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.

24 septiembre 2025

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.


 

10 septiembre 2025

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.

28 agosto 2025

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

 

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





 

 

 

19 agosto 2025

[Blender] Trucos que he aprendido modelando a Tanya por segunda vez

     Ayer publiqué un nuevo modelo 3D de Tanya Degurechaff (enlace) y en la entrada de hoy quisiera compartiros los trucos que he aprendido la semana pasada mientras la modelaba.

 

1.- Usar el modificador de "skin" sobre simples vértices para crear líneas con profundidad. 

Este descubrimiento ha sido muy valioso para mí. Para contextualizar, deseaba recrear el marco dorado de estilo clásico que aparece en las portadas de “Diario de Guerra: Saga of Tanya The Evil”. Inicialmente, intenté hacerlo con un plano simple en el que delineaba el contorno del marco mediante extrusiones ("extrudes"), lo cual resultó ser un proceso muy lento, ineficaz y depresivo. Con esta técnica rudimentaria, podía dedicar diez minutos sin obtener avances significativos. Para haceros una idea, os comparto aquí la portada que quería usar de inspiración, donde se ve el nivel de complejidad de dicho marco dorado (que rodea toda la composición).


 

Después consideré la posibilidad de utilizar nurbs path y curves, una técnica que suelo emplear para la creación del cabello de los personajes. Sin embargo, esta opción añadía una complejidad excesiva al modelado. Finalmente, encontré una solución óptima y sencilla: Crear una ruta de vértices a la que posteriormente aplicaría un modificador “Skin” para generar volumen. Este método resultó mucho más eficiente: siguiendo el contorno, colocaba un vértice, aplicaba una extrusión, colocaba otro vértice y repetía el proceso. De esta manera, en poco más de una hora, el marco estaba terminado.

Es importante destacar que la estructura del marco en el manga presenta una mayor complejidad, ya que los nudos poseen profundidad (permitiendo distinguir con facilidad los puntos de entrada y salida del trazo) y, además, presenta tramos con un trazo más fino o grueso. Si bien esta característica podría replicarse mediante la técnica de vértices y el modificador “skin” (jugando con la coordenada del eje Y y combinando con Control+A para cambiar el grosor del trazo), opté por mantener una estructura plana con trazos uniformes para simplificar el proceso, considerando que, en la composición final, el marco no adquiere una relevancia que justifique una inversión de tiempo excesiva. 






2.- El motor EEVEE permite efectos muy buenos para aplicar estilos de dibujo.

Una de las principales diferencias entre los motores de renderizado EEVEE y Cycles es que EEVEE es menos realista y permite jugar con la vista, implementando nodos como el "Convert Shader to RGB" que no funciona en Cycles (el cual ofrece iluminaciones más realistas al estar basado en el trazado de rayos). De hecho, jugando con los nodos puedes simular cierto nivel de celshading sin tener que crear un objeto de contorno negro con normales invertidas.

 

Pero claro, no es tan sencillo como pillar un nodo de Color Ramp, te toca experimentar con los nodos de "Geometry" y jugar con las normales para luego alterar el displacement del material final. Aquí os dejo, como ejemplo, todos los nodos que tuve que emplear únicamente para el color del pelo:



 

3.- Ponerle al iris y a las cejas un material de emisión queda genial en escenas oscuras.

De esta forma podemos ver los ojos del personaje incluso si no hay iluminación.



 

4.- Los motores de juegos o Sketchfab se parecen más al motor Cycles que al EEVEE.

Como he dicho antes, EEVEE es un motor muy genial para implementar efectos de dibujo, pero en cuanto subes tu modelo a sitios como a Sketchfab o lo exportas a un formato como GLB/GLTF o FBX para utilizarlo en algún juego, te encuentras con que los materiales, una vez importados a Unity/Unreal/Godot, no se parecen a los que estabas empleando en Blender. El principal problema suele estar en nodos como el "Shader to RGB", que no son compatibles fuera de EEVEE.

Mi modelo renderizado en EEVEE antes de adaptar los materiales para funcionar con Cycles. 

 

Mi modelo visto en Cycles antes de que adaptara los materiales.

Esto sería un ejemplo de "se ve bien en  Blender, pero feo en Unity/Godot/Unreal".

 

Mi modelo con los materiales adaptados a Cycles.

 

 

Dicho esto, si tienes pensado exportar tu modelo, vale la pena dedicarle tiempo a ver cómo quedan tus materiales en el motor de Cycles.

En mi caso la adaptación pasó por identificar todos los materiales que hacían uso del "Shader to RGB" y reemplazarlo generalmente por un "Diffuse BSDF", salvo si éste estaba siendo usado como factor para un Color Ramp, que en ese caso un "Geometry> Normal", "Geometry> True Normal" o "Geometry> Tangent" me daba mejores resultados.



5.- "Hornear" texturas para que tu modelo se vea igual en Blender que en Sketchfab o en cualquier juego.

Cada juego o motor suele tener su propio sistema de luces. Si quieres hacer que una escena se vea exactamente igual sin tener muchas complicaciones de cabeza, con el motor Cycles puedes hacer un "bake" de las texturas. Es decir, imprimir el resultado final del material aplicado en tu modelo en un fichero de imagen de textura. Es decir, la textura resultante contendrá los datos de iluminación y color conforme los estas viendo ahora mismo. No es complicado, pero sí muy tedioso. Si el material a "hornear" está en objetos complejos (con miles de vértices), esto puede durar más de diez minutos, dependiendo de tu tarjeta gráfica. En objetos normales, sin mucha complejidad, este proceso suele ser casi instantáneo.

Primero tienes que asegurarte que el objeto tenga unas UV bien definidas. Para ello basta con seleccionarlo, irte a la pestaña de edición de UV y si ves que las caras no parecen bien posicionadas en la textura fuente, puedes probar a recrearlas con UV > Smart UV Project. Recomiendo encarnizadamente revisar las UV antes de empezar con el "bake". Si no está familiarizado con el concepto, las UV pueden entenderse como un “mapa” de vértices utilizado para la texturización de superficies. En otras palabras, describen cómo se proyectan las caras de un objeto en un plano bidimensional, o cómo se asigna cada área del archivo de textura a una cara específica del objeto. En términos generales, puede entenderse como un mapa.

 

UV por defecto que propone Blender para la cabeza de mi modelo, con los modificadores sin aplicar.

Ese vértice rebelde puede dar problemas en determinados motores de juegos. 

 

UV tras pasar por Smart UV Project, con los modificadores sin aplicar.

 

 

UV recalculado con "Smart UV Project" con los modificadores ya aplicados.

 

 Para "bakear" el proceso es muy sencillo. Una vez tu material está adaptado para funcionar en Cycles, le añades un nodo de "Texture Image" y creas una imagen con un tamaño que sea una potencia de 8 (por ejemplo 512x512, 1024x1024, 2048x2048, 4096x4096...). Acto seguido, en la pestaña de "Render", en el motor Cycles te saldrá una opción de "Bake" en el que puedes indicar todos los datos que se tienen que exportar en la textura resultante (luz directa, indirecta, brillo, transiciones, etc) y le das a "Bake".



 

Cabe destacar que si tu material está siendo usado por varios objetos, tendrás que cambiar la "Texture Image" en cada objeto que vayas a "bakear". De misma forma, motores como el de Sketchfab no te permiten materiales con múltiples texturas, por lo que lo más sencillo será que dupliques el material a cada vez que "bakees" un objeto y lo renombres para recordar qué textura va en qué material.


 

 

6.- Copiar modificadores con "Control+L".

Esto es algo bastante práctico que no sabía que se podía hacer. Para daros contexto, los peinados de mis personajes suelen tener muchos vértices. En Blender parece liviano porque utilizo una mezcla de nurbs curves + nurbs paths, pero una vez los convierto en malla estos atrapan un volumen exagerado de vértices. A esto sumadle que el peinado de Tanya puede constar perfectamente de unos 50 mechones, lo que puede dar lugar a más de 600.000 vértices en el modelo sin optimizar sólo para el cabello.

Lógicamente yo no puedo publicar un modelo con medio millón de vértices sólo en el pelo. La solución lógica parece que pasa por convertir todos los mechones a malla, unirlos en un único objeto con Control+J (o hacer uso de modificadores de boolean de tipo unión) y aplicarles un modificador de "Decimate" para aplanar las caras. Claro, esto sobre el papel parece una buena idea, pero te acaba deformando la hermosa caballera y encima ésta sigue teniendo un número considerablemente alto de vértices (si lo bajo a 400.000 vértices se ve feísimo). 

Así que opté por otra técnica: ¿Qué pasa si aplico un decimate, por separado, a cada mechón? Pues esto fue lo que salvó el pelo de Tanya en el modelo final. Resulta que si en Blender seleccionas varios objetos y pulsas Control+L, te sale un menú desplegable donde una de las opciones es "Copy Modifiers" y que lo que hace es, como suena, copiar TODOS los modificadores del objeto seleccionado al resto. Y bueno, si éste último objeto seleccionado no tiene ningún modificador, te borrará todos los modificadores de todos los objetos seleccionados (lo cual también puede ser práctico).

 

De esta forma, a base de copiar y pegar modificadores, podía hacer de forma fácil que los mechones que eran poco visibles tuvieran un factor de decimate elevado y de paso ser menos agresivo con los decimates de los mechones del flequillo, haciendo que el pelo de Tanya pasara de 600.000 vértices a 100.000 sin que se apreciara una caída drástica de calidad. Se podría optimizar aún más, pero para Sketchfab ya era un valor aceptable y decidí dejarlo así.