El general Failure, leo tu disco duro

Rosebud

2026-04-16T23:08:00.003+02:00

Hoy he recibido mi "Rosebud", el Final Fantasy VII para PC, en su formato bigbox distribuida por Proein en España. Este título se trató de uno de los primeros juegos que compré con mi propio dinero, ocupó un lugar destacado en mi tiempo libre durante el inicio del instituto, llegando a dedicarle un considerable número de horas nocturnas. Alcancé el nivel máximo de 99 con todos los personajes, excepto Aerith, y completé todas las "Armas" (nombre de una serie de enemigos finales ocultos) y me hice con todas las materias posibles. Y es que lo acabé malvendiendo y aún recuerdo con claridad el nombre del compañero al que se lo vendí, decisión que he lamentado en numerosas ocasiones.

Tras años buscando y alucinar con los precios, finalmente lo encontré en Wallapop a un monto razonable. Si bien se encontraba en mal estado y carecía del manual de instrucciones, estos inconvenientes no me supusieron un obstáculo, dado que el ejemplar que poseía en aquella época tampoco se encontraba en óptimas condiciones y aún conservo el manual de instrucciones.

Dango Soccer. Build: 0.26.04.14 - ALPHA - Emisario EDITION

2026-04-14T23:57:00.003+02:00

Supongo que habréis notado que me he ausentado del blog durante los últimos meses. Esta ausencia no se debe a una falta de deseo por retomar la escritura, sino a circunstancias específicas. De hecho, tengo una entrada preparada para Div Games Studio. Sin embargo, en mi trabajo fui subcontratado para crear desde cero una app en React, tecnología en la que no me considero experto y esta situación me ha generado un nivel considerable de agotamiento. No obstante, para animarme, durante mi tiempo libre de estos meses opté por retomar el desarrollo del clon de PC Fútbol que estoy llevando a cabo con Godot .NET. A continuación, les presento un resumen cómo está quedando: https://www.youtube.com/watch?v=Hyy2Hx2vlJ0

¿Aprendiendo a programar para MS-DOS con DIV2 Games Studio? ¡Hagámos un bullet hell! (capítulo 3)

2026-02-04T01:33:00.001+01:00

En esta tercera entrega de la serie de programación de DIV, continuaremos con el enfoque establecido en la entrada anterior, partiendo de un prototipo básico y progresando gradualmente hacia la creación de un juego atractivo.... y en este caso tenemos incluso un juego COMPLETO (sí, en mayúsculas). Este capítulo incorpora el feedback recibido de la entrada anterior y se centra en mejorar la legibilidad del código, asegurando que los cambios entre las distintas versiones del ejercicio sean fácilmente identificables y además esta vez lo he escrito en castellano. Aún así prepararos un bocadillo y un café bien cargado, que los ejemplos finales no son sencillos.

Si eres nuevo, o no estás familiarizado con Div Games Studio, se trata de un entorno de programación de videojuegos para MS-DOS lanzado en 1998. Este lenguaje de programación es procedural, no orientado a objetos, y ofrece numerosas características atractivas para su época, tales como el uso de estructuras, punteros, reserva dinámica de memoria (con malloc/free) y una curva de aprendizaje relativamente sencilla. De hecho, mucha gente aprendió a programar con este lenguaje en España y se hizo tan popular a finales de los 90 que incluso llegaron a comercializarse revistas comerciales dedicados a este framework.

Uno de los aspectos más destacados del feedback recibido de la entrada anterior fueron las dudas sobre la utilidad de las estructuras, cómo diferenciar distintos tipos de enemigos o la eficiencia de implementar un proceso unificado para el dibujo, en lugar de permitir que cada instancia dibuje su propio gráfico. Esta reflexión me llevó a considerar el desarrollo de un juego de naves, similar a Space Invaders o Galaga, puesto que son elementos comunes en este tipo de juegos, donde debemos de dibujar grandes tipos de enemigos, de distintos tipos y evitando que el juego se ralentice.

Así que empecé a trabajar en un programa llamado "vshooter" de "Vertical Shooter", en honor al género de este tipo de juegos de marcianitos. Como siempre, recordad que todos estos ejemplos de código los tengo subidos en mi Github (https://github.com/LeHamsterRuso/DIV2Examples/blob/main/PRG/VSHOOT01.PRG).

Y vamos con el primer ejemplo:

//------------------------------------------------------------------------------
// TÍTULO:      VSHOOT01.PRG - Nave Jugador Simple
// AUTOR:       Sebastian J. MONCHO MAQUET
// FECHA:       18/01/2026
// DESCRIPCIÓN: Versión simplificada con solo la nave del jugador y controles.
// NOTA:        Usa las flechas para mover la nave, espacio para disparar y ESC para salir.
//              Requiere la paleta DIV2.PAL en el mismo directorio.
//              Código y comentarios en castellano para facilitar la comprensión (por petición).
//------------------------------------------------------------------------------

PROGRAM vshooter;
// Programa principal
BEGIN
    // Arrancamos el juego a 320x200 a 60 FPS con la paleta cargada
    set_mode(m320x200);  // 320x200
    set_fps(60, 0);
    load_pal("DIV2.PAL");

    // Creamos la nave del jugador
    jugador();

    // Bucle principal del juego
    LOOP
        FRAME;
    END
END

// Proceso: jugador
// Descripción: Controla la nave del jugador.
// - Maneja el dibujo, movimientos y disparos en un bucle continuo.
PROCESS jugador();
PRIVATE
    vel = 3;  // Velocidad de movimiento
    tiempo_disparo = 0; // Contador para controlar la frecuencia de disparos

    // El dibujo de la nave se compone de varias partes
    nave_circulo;       // ID del dibujo del círculo de la nave
    nave_linea1;        // ID del dibujo de la primera línea de la nave
    nave_linea2;        // ID del dibujo de la segunda línea de la nave
    nave_linea3;        // ID del dibujo de la tercera línea de la nave
BEGIN
    // Posición inicial de la nave en el centro inferior de la pantalla
    x = 160;  // Centro horizontal
    y = 170;  // Cerca del fondo

    // Bucle principal del jugador
    LOOP
        // Dibujamos la nave del jugador
        // Borrar los dibujos anteriores
        IF (nave_circulo != 0) delete_draw(nave_circulo); END
        IF (nave_linea1 != 0) delete_draw(nave_linea1); END
        IF (nave_linea2 != 0) delete_draw(nave_linea2); END
        IF (nave_linea3 != 0) delete_draw(nave_linea3); END

        // Dibujar la nave
        nave_circulo = draw(5, 31, 15, 0, x - 8, y - 8, x + 8, y + 8);
        nave_linea1 = draw(1, 31, 15, 0, x - 6, y + 8, x, y - 10);
        nave_linea2 = draw(1, 31, 15, 0, x + 6, y + 8, x, y - 10);
        nave_linea3 = draw(1, 31, 15, 0, x - 6, y + 8, x + 6, y + 8);

        // Movimiento de la nave
        IF (key(_left) AND x > 10) x -= vel; END
        IF (key(_right) AND x < 310) x += vel; END
        IF (key(_up) AND y > 10) y -= vel; END
        IF (key(_down) AND y < 190) y += vel; END

        // Disparar
        tiempo_disparo++;
        IF (key(_space) AND tiempo_disparo > 5)
            // Crear bala
            bala_jugador(x, y - 15);
            tiempo_disparo = 0;
        END

        // Salir con ESC
        IF (key(_esc))
            EXIT("Gracias por jugar.", 0);
        END

        FRAME;  // Esperar al siguiente frame
    END
END

// Proceso: bala_jugador
// Descripción: Controla el movimiento de una bala disparada por el jugador.
// - Se mueve hacia arriba y se elimina si sale de la pantalla.
PROCESS bala_jugador(x, y);
PRIVATE
    bala_draw;  // ID del dibujo de la bala
BEGIN
    LOOP
        // Borramos dibujo anterior si existe
        IF (bala_draw != 0) delete_draw(bala_draw); END

        // Dibujamos la bala
        bala_draw = draw(5, 10, 15, 0, x - 3, y - 3, x + 3, y + 3);

        // Movemos la bala hacia arriba
        y -= 5;

        // Eliminamos la bala si sale de la pantalla
        IF (y < -10) RETURN; END

        FRAME;  // Esperar al siguiente frame
    END
END

Este ejemplo que os he puesto es terriblemente sencillo: Manejamos una especie de botijo azul, que se desplaza pulsando los cursores (las teclas de arriba/abajo/izquierda/derecha), dispara balas redondas pulsando espacio y salimos del juego pulsando escape. Ya está, no tiene nada más, tienes un proceso de jugador, un proceso de bala_jugador, ambos se dibujan en pantalla con primitivas gráficas (ni siquiera sprites) y hacemos uso de una variable de "tiempo_disparo" para controlar que las balas se disparen por ráfagas.

Cosas chulas que no suelen verse: Si os fijáis en la bala_jugador, tenemos un bucle infinito (LOOP) que paramos con un RETURN. Aquí no actúa como "BREAK" del bucle, si no que indica que la ejecución del proceso acaba ahí. Sencillamente, cuando quieras forzar que una instancia deje de "vivir", la puedes "matar" con un return.

Ahora vamos a añadir enemigos. De hecho, vamos a añadir 2, uno de cada tipo y tendrán patrones de movimiento distinto. Uno se desplazará de derecha a izquierda y de izquierda a derecha y cada vez que llegue a un extremo de la pantalla bajará ligeramente. El otro se moverá haciendo ligeros círculos, casi imperceptibles (https://github.com/LeHamsterRuso/DIV2Examples/blob/main/PRG/VSHOOT02.PRG).

Para ello añadiremos una instancia de cada tipo de enemigo en el main:

PROGRAM vshooter;
// Programa principal
BEGIN
    // Arrancamos el juego a 320x200 a 60 FPS con la paleta cargada
    set_mode(m320x200);  // 320x200
    set_fps(60, 0);
    load_pal("DIV2.PAL");

    // Creamos la nave del jugador
    jugador();

    // Creamos 2 enemigos: uno tipo 1 y uno tipo 2
    enemigo_tipo1(50, 30);
    enemigo_tipo2(200, 40);

    // Bucle principal del juego
    LOOP
        FRAME;
    END
END

E implementamos ambos enemigos:

// Proceso: enemigo_tipo1
// Descripción: Controla el comportamiento de un enemigo tipo 1.
// - Se mueve horizontalmente, dispara balas y verifica si muere o llega abajo.
// Parámetros:
//   - x: Posición inicial x.
//   - y: Posición inicial y.
PROCESS enemigo_tipo1(x, y);
PRIVATE
    dir = 1;  // Dirección inicial
    tiempo = 0;
    enemigo_box;  // ID del dibujo de la caja
    enemigo_circulo;  // ID del dibujo del círculo
BEGIN
    LOOP
        // Dibujar enemigo
        dibujar_enemigo_tipo1(&enemigo_box, &enemigo_circulo, x, y);

        // Mover enemigo
        mover_enemigo_tipo1(&x, &y, &dir);

        // Salir si llega abajo
        IF (y > 210) RETURN; END

        FRAME;
    END
END

// Proceso: enemigo_tipo2
// Descripción: Controla el comportamiento de un enemigo tipo 2.
// - Se mueve en círculos, dispara balas dirigidas y verifica si muere.
// Parámetros:
//   - x: Posición inicial x.
//   - y: Posición inicial y.
PROCESS enemigo_tipo2(x, y);
PRIVATE
    ang = 0;  // Ángulo inicial
    tiempo = 0;
    enemigo_linea1;  // IDs de dibujos
    enemigo_linea2;
    enemigo_linea3;
    enemigo_linea4;
    enemigo_circulo;
BEGIN
    LOOP
        // Dibujar enemigo
        dibujar_enemigo_tipo2(&enemigo_linea1, &enemigo_linea2, &enemigo_linea3, &enemigo_linea4, &enemigo_circulo, x, y);

        // Mover enemigo
        mover_enemigo_tipo2(&x, &y, &ang);

        FRAME;
    END
END

Si os fijáis, a nivel de implementación son muy parecidos. Tienen sus parámetros y verificaciones propias, pero a su vez ambos tienen una estructura parecida, donde llamamos a un proceso de dibujo y controlamos su movimiento:

// Función: dibujar_enemigo_tipo1
// Descripción: Dibuja el enemigo tipo 1, borrando los dibujos anteriores.
// Parámetros:
//   - box_offset: Puntero al ID de la caja.  -> Usamos el puntero para modificar la variable original.
//   - circulo_offset: Puntero al ID del círculo.  -> Usamos el puntero para modificar la variable original.
//   - x: Posición x.
//   - y: Posición y.
// Los punteros sirven para modificar las variables originales fuera de la función.
// - Si modificas una varariable del puntero dentro de la función, se refleja fuera también.
// - Sirve para evitar el uso de variables globales innecesarias.
// Los PROCESS se ejecutan en paralelo, mientras que las FUNCTION se ejecutan de forma secuencial
// - Es decir, hasta que no termine esta función, el proceso que lo llama queda bloqueado
FUNCTION dibujar_enemigo_tipo1(INT box_offset, INT circulo_offset, INT x, INT y);
BEGIN
    // Borramos los dibujos del frame anterior
    // Controlamos que existe ya una box y un círculo (ID != 0) antes de borrarlos
    // Si no lo comprobamos, tendríamos una excepción en el primer FRAME y el juego se colgaría
    IF (*box_offset != 0) delete_draw(*box_offset); END
    IF (*circulo_offset != 0) delete_draw(*circulo_offset); END

    // Dibujamos el enemigo
    *box_offset = draw(3, 114, 15, 0, x - 8, y - 8, x + 8, y + 8);
    *circulo_offset = draw(5, 4, 15, 0, x - 3, y - 3, x + 3, y + 3);
END

// Función: mover_enemigo_tipo1
// Descripción: Maneja el movimiento horizontal del enemigo tipo 1, cambiando dirección al llegar a los bordes y descendiendo.
// Parámetros:
//   - x_offset: Puntero a la posición x. -> Usamos el puntero para modificar la variable original.
//   - y_offset: Puntero a la posición y. -> Usamos el puntero para modificar la variable original.
//   - dir_offset: Puntero a la dirección (1 o -1). -> Usamos el puntero para modificar la variable original.
// Los punteros sirven para modificar las variables originales fuera de la función.
// - Si modificas una varariable del puntero dentro de la función, se refleja fuera también.
// - Sirve para evitar el uso de variables globales innecesarias.
// Los PROCESS se ejecutan en paralelo, mientras que las FUNCTION se ejecutan de forma secuencial
// - Es decir, hasta que no termine esta función, el proceso que lo llama queda bloqueado
FUNCTION mover_enemigo_tipo1(INT x_offset, INT y_offset, INT dir_offset);
BEGIN
    *x_offset += *dir_offset * 2;  // Movimiento horizontal

    // Cambiar dirección al llegar a los bordes
    IF (*x_offset < 10 OR *x_offset > 310)
        *dir_offset = -*dir_offset;
        *y_offset += 5;  // Descenso
    END
END

// Función: dibujar_enemigo_tipo2
// Descripción: Dibuja el enemigo tipo 2, borrando los dibujos anteriores.
// Parámetros:
//   - linea1_offset: Puntero al ID de la línea 1.  -> Usamos el puntero para modificar la variable original.
//   - linea2_offset: Puntero al ID de la línea 2.  -> Usamos el puntero para modificar la variable original.
//   - linea3_offset: Puntero al ID de la línea 3.  -> Usamos el puntero para modificar la variable original.
//   - linea4_offset: Puntero al ID de la línea 4.  -> Usamos el puntero para modificar la variable original.
//   - circulo_offset: Puntero al ID del círculo.  -> Usamos el puntero para modificar la variable original.
//   - x: Posición x.
//   - y: Posición y.
// Los punteros sirven para modificar las variables originales fuera de la función.
// - Si modificas una varariable del puntero dentro de la función, se refleja fuera también.
// - Sirve para evitar el uso de variables globales innecesarias.
// Los PROCESS se ejecutan en paralelo, mientras que las FUNCTION se ejecutan de forma secuencial
// - Es decir, hasta que no termine esta función, el proceso que lo llama queda bloqueado
FUNCTION dibujar_enemigo_tipo2(INT linea1_offset, INT linea2_offset, INT linea3_offset, INT linea4_offset, INT circulo_offset, INT x, INT y);
BEGIN
    // Borramos los dibujos anteriores
    IF (*linea1_offset != 0) delete_draw(*linea1_offset); END
    IF (*linea2_offset != 0) delete_draw(*linea2_offset); END
    IF (*linea3_offset != 0) delete_draw(*linea3_offset); END
    IF (*linea4_offset != 0) delete_draw(*linea4_offset); END
    IF (*circulo_offset != 0) delete_draw(*circulo_offset); END

    // Dibujamos el enemigo
    *linea1_offset = draw(1, 9, 15, 0, x, y - 8, x + 8, y);
    *linea2_offset = draw(1, 9, 15, 0, x + 8, y, x, y + 8);
    *linea3_offset = draw(1, 9, 15, 0, x, y + 8, x - 8, y);
    *linea4_offset = draw(1, 9, 15, 0, x - 8, y, x, y - 8);
    *circulo_offset = draw(5, 9, 15, 0, x - 2, y - 2, x + 2, y + 2);
END

// Función: mover_enemigo_tipo2
// Descripción: Maneja el movimiento circular del enemigo tipo 2, manteniéndolo dentro de la pantalla.
// Parámetros:
//   - x_offset: Puntero a la posición x. -> Usamos el puntero para modificar la variable original.
//   - y_offset: Puntero a la posición y. -> Usamos el puntero para modificar la variable original.
//   - ang_offset: Puntero al ángulo de movimiento. -> Usamos el puntero para modificar la variable original.
// Los punteros sirven para modificar las variables originales fuera de la función.
// - Si modificas una varariable del puntero dentro de la función, se refleja fuera también.
// - Sirve para evitar el uso de variables globales innecesarias.
// Los PROCESS se ejecutan en paralelo, mientras que las FUNCTION se ejecutan de forma secuencial
// - Es decir, hasta que no termine esta función, el proceso que lo llama queda bloqueado
FUNCTION mover_enemigo_tipo2(INT x_offset, INT y_offset, INT ang_offset);
BEGIN
    *ang_offset += 5000;  // Incremento del ángulo

    // Movimiento circular
    *x_offset += get_distx(*ang_offset / 1000, 1);
    *y_offset += get_disty(*ang_offset / 1000, 1);

    // Mantener dentro de la pantalla
    IF (*x_offset < 10) *x_offset = 10; END
    IF (*x_offset > 310) *x_offset = 310; END
    IF (*y_offset < 10) *y_offset = 10; END
    IF (*y_offset > 190) *y_offset = 190; END
END

Cosas chulas que no se suelen ver:

- Dividir el objeto, el comportamiento y su dibujado en procesos distintos. Esto suele hacerse para para reducir la complejidad del código, haciendo que sea más sencillo de leer (no es lo mismo un proceso gigante que tres pequeños) y de mantener.

- Hago uso de punteros tanto para el dibujado como para el movimiento de los enemigos. ¿Qué es un puntero? Digamos que tanto la variable "x" de enemigo, como la variable "x_offset" de mover_enemigo, comparten la misma región de memoria. O dicho de otra forma, si modificas una de esas dos variables, estás modificando realmente ambas variables a la vez. Esto es muy útil si quieres que varios procesos "comuniquen" entre ellos en tiempo real, sin tener que recurrir a variables globales.

¿Se puede hacer todo eso por valor en vez de punteros? Sí. ¿Estoy complicando el código innecesariamente? También. Pero pensad que ahora mismo sólo tenemos dos enemigos en pantalla. Mañana tendremos 160.

Bueno, pues ahora que ya tenemos un jugador, balas y enemigos, podemos plantearnos ya hacer un juego: Pongamos más enemigos en pantalla, que disparen con patrones distintos, explosiones y que el jugador y los enemigos mueran al colisionar con las balas. Atentos, que se vienen curvas (https://github.com/LeHamsterRuso/DIV2Examples/blob/main/PRG/VSHOOT03.PRG).

En este ejemplo (el tercero), si hacéis un diff con el anterior veréis que hay muchísimos cambios, en gran parte porque, además de añadir todo lo que os voy a describir, he remplazado muchos "magic numbers" por constantes. Y también me lié y cambié de lugar varias funciones. ¿Qué es un "magic number"? Pues ni más ni menos que todos los valores "hardcodeados" que veis por el código. Está claro que si quieres centrar un proceso en una pantalla de 320x200, puedes directamente decir que su posición X es 160 y su posición Y es 100, pero en programación los llamamos números "mágicos" porque sacados de contexto no significan nada. Imagínate dentro de 6 meses releyendo tu código: "¿Por qué puse aquí 80? ¿Por que sí y punto?". Pues esos números mágicos o cadenas mágicas (para el caso de los strings) se mitigan poniendo constantes. La constante nos permite aplicar un nombre que le otorga un contexto en lectura y que, cuando se compila, no se trata como si fuera una variable, si no que el compilador ya mete directamente el valor esperado donde corresponda.

En este ejemplo, para crear enemigos simplemente he creado un proceso independiente en el que llamo a un bucle FROM para crear 5 instancias de cada enemigo. Cosas a tener en cuenta: A diferencia del bucle FOR, el FROM sólo permite operar con constantes, entre otras cosas porque lo que hace el compilador es repetir X veces el bloque de instrucciones que contenga dicho bucle. O dicho de otra forma, no hay un componente condicional que haga variar el número de iteraciones que tendrá el bucle.

// Función: crear_enemigos
// Descripción: Crea los procesos de enemigos al inicio de cada nivel.
// - Genera 5 enemigos tipo 1 (a la izquierda) y 5 tipo 2 (a la derecha).
PROCESS crear_enemigos();
PRIVATE
    i;  // Variable para el bucle
BEGIN
    // Crea 5 enemigos tipo 1 en posiciones espaciadas en la izquierda
    FROM i=0 TO 4;
        enemigo_tipo1(ESPACIADO_ENEMIGO1_X + i * ESPACIADO_ENEMIGO1_X, ESPACIADO_ENEMIGO1_Y_INICIAL + i * ESPACIADO_ENEMIGO1_Y);  // Posición x e y calculada
    END
    
    // Crea 5 enemigos tipo 2 en posiciones espaciadas en la derecha
    FROM i=0 TO 4;
        enemigo_tipo2(ESPACIADO_ENEMIGO2_X_INICIAL + i * ESPACIADO_ENEMIGO2_X, ESPACIADO_ENEMIGO2_Y_INICIAL + i * ESPACIADO_ENEMIGO2_Y);  // Posición x e y calculada
    END
END

Luego, defino también una función de de iniciar_nivel, que me permite llamar a ese crear enemigos, inicializar variables para la partida, invocar al jugador y le he implementado una cuenta regresiva de "3, 2, 1... GO!". Si os fijáis aquí, estoy definiendo una función y no un proceso, pero a dicha función le meto instancias de "FRAME". ¿Por qué? ¿Las funciones no son métodos que devuelven resultados? Pues esto es uno de los trucos que nos permite Div Games Studio: Las funciones, en la práctica, tienen un comportamiento identico a los procesos (aka "instancias"), pero bloquean la ejecución de su proceso padre. Es decir, hasta que incio_nivel no termine de ejecutarse, el proceso que lo llama (en este caso el bucle principal del juego) para su ejecución.

// Función: inicio_nivel
// Descripción: Inicializa un nuevo nivel mostrando una cuenta regresiva (3, 2, 1, GO!) y creando los procesos de enemigos y jugador.
// - Desactiva controles durante la cuenta y los activa al final.
// Los PROCESS se ejecutan en paralelo, mientras que las FUNCTION se ejecutan de forma secuencial
// - Aunque tenga FRAME dentro, es una función y bloquea el proceso que la llama (hack de DIV)
// - Es decir, hasta que no termine esta función, el proceso que lo llama queda bloqueado
FUNCTION inicio_nivel();
PRIVATE
    INT contador = 3;   // Cuenta regresiva: 3, 2, 1, GO!
    INT tiempo = 0;     // Contador de frames
    STRING contador_str;// String para mostrar contador
BEGIN
    // Desactivamos controles durante la cuenta regresiva
    controles_activos = 0;
    
    // Creamos naves pero sin movimiento
    crear_enemigos();  // Creamos enemigos
    jugador();  // Crear jugador
    
    // Esperar un momento para que se vean las naves
    FRAME;
    FRAME;
    
    // Cuenta regresiva 3, 2, 1, GO!
    WHILE (contador > 0)
        contador_str = itoa(contador);        // Convertimos el número a string (itoi = integer to ascii)
        write(0, CENTRO_X, CENTRO_Y, ALINEACION_CENTRADO, contador_str);  // 4 = centrado
        
        tiempo++;
        IF (tiempo >= FPS_JUEGO)
            // Ha pasado un segundo, actualizamos la cuenta atrás
            contador--;
            tiempo = 0;
            delete_text(all_text);  // Limpiamos todos los textos
            mostrar_textos_hud();   // Volmemos a dibujar los textos del HUD
        END
        
        FRAME; // Siguiente frame
    END
    
    // Mostramos el GO!
    write(0, CENTRO_X, CENTRO_Y, ALINEACION_CENTRADO, "GO!"); // 4 = centrado
    tiempo = 0;
    WHILE (tiempo < FPS_JUEGO / 2)
        FRAME;
        tiempo++;
    END  // Mostramos GO! por 0,5 segundos
    
    delete_text(all_text);  // Limpiamos todos los textos
    mostrar_textos_hud();   // Volmemos a dibujar los textos del HUD
    controles_activos = 1;  // Activar controles para empezar el juego
END

De hecho, también defino funciones "bloqueantes" para calcular las colisiones del jugador con las balas, con sus enemigos y de los enemigos con las balas y el jugador. El algoritmo de la colisiones o es muy complicado, pero necesita un punto de atención en get_id(type tipo_instancia). El funcionamiento de get_id es muy peculiar: Si tienes varias instancias de un tipo de enemigo, te devuelve sólo el ID de la instancia del primer enemigo... pero si vuelves a usar get_id te devuelve el del segundo enemigo... y si lo vuelves a usar te devuelve el del tercer enemigo... y llega un momento que devolverá 0 (cuando no queden más identificadores en la cola). La gracia es que cada vez que el proceso llama a "FRAME", esa cola de identificadores se reinicia y si lo usas vuelve a darte el primer enemigo de la cola. Sabiendo esto, podemos crear bucles que recorran todos los enemigos que hay en pantalla desde una función externa y comprobar si entra dentro de un área (las famosas "hitboxes) de los videojuegos:

// Función: comprobar_colision_jugador_enemigos
// Descripción: Verifica si la nave del jugador colisiona con algún enemigo.
// - Si hay colisión, suma puntos, crea explosiones y termina el juego.
// Parámetros:
//   - x: Posición x de la nave (por valor, ya que no se modifica).
//   - y: Posición y de la nave (por valor, ya que no se modifica).
// Los PROCESS se ejecutan en paralelo, mientras que las FUNCTION se ejecutan de forma secuencial
// - Es decir, hasta que no termine esta función, el proceso que lo llama queda bloqueado
FUNCTION comprobar_colision_jugador_enemigos(INT x, INT y);
PRIVATE
    id_enemigo;  // ID del enemigo para iterar
BEGIN
    // Comprobamos la colisión con enemigos de tipo 1
    // Si existen varios procesos del tipo que se ha especificado,
    // la función get_id() devolverá el resto de los identificadores en las sucesivas llamadas que se realicen a la misma.
    // Una vez se hayan devuelto todos los códigos identificadores, la función devolverá 0, hasta que se vuelva a ejecutar una sentencia FRAME
    // En cada frame, la lista que devuelve get_id() se reinicia, es por eso que aqui no ponemos ningún FRAME
    id_enemigo = get_id(type enemigo_tipo1);
    // Bucle, recorriendo todos los enemigos tipo 1, enemigo a enemigo
    WHILE (id_enemigo)
        // Calculamos distancia entre jugador y enemigo
        IF (fget_dist(x, y, id_enemigo.x, id_enemigo.y) < DISTANCIA_COLISION)
            // Significa que ambos han chocado y ambos mueren
            puntos += PUNTOS_POR_ENEMIGO;  // Sumamos los puntos
            explosion(id_enemigo.x, id_enemigo.y, COLOR_ENEMIGO1);  // Explosión del enemigo
            enemigo_muerto_id = id_enemigo;  // Marcar enemigo como muerto
            explosion(x, y, COLOR_NAVE);  // Explosión del jugador
            game_over = 1;  // Marcamos game over (lo leerá el process principal y actuará en cosnecuencia)
            RETURN;
        END

        // Siguiente enemigo, hasta que no hagamos FRAME, get_id() devolverá el siguiente ID
        // cuando no queden más, devolverá 0 y saldremos del bucle
        id_enemigo = get_id(type enemigo_tipo1);
    END
    
    // Comprobamos la colisión con enemigos de tipo 2
    // Si existen varios procesos del tipo que se ha especificado,
    // la función get_id() devolverá el resto de los identificadores en las sucesivas llamadas que se realicen a la misma.
    // Una vez se hayan devuelto todos los códigos identificadores, la función devolverá 0, hasta que se vuelva a ejecutar una sentencia FRAME
    id_enemigo = get_id(type enemigo_tipo2);
    WHILE (id_enemigo)
        // Calculamos distancia entre jugador y enemigo
        IF (fget_dist(x, y, id_enemigo.x, id_enemigo.y) < DISTANCIA_COLISION)
            // Significa que ambos han chocado y ambos mueren
            puntos += PUNTOS_POR_ENEMIGO;  // Sumar puntos
            explosion(id_enemigo.x, id_enemigo.y, COLOR_ENEMIGO2);  // Explosión del enemigo
            enemigo_muerto_id = id_enemigo;  // Marcar enemigo para morir
            explosion(x, y, COLOR_NAVE);  // Explosión del jugador
            game_over = 1;  // Terminar juego
            RETURN;
        END

        // Siguiente enemigo, hasta que no hagamos FRAME, get_id() devolverá el siguiente ID
        // cuando no queden más, devolverá 0 y saldremos del bucle
        id_enemigo = get_id(type enemigo_tipo2); 
    END
END

// Función: comprobar_colision_bala_enemigos
// Descripción: Verifica si la bala del jugador colisiona con algún enemigo. Si hay colisión, suma puntos, crea explosión y marca al enemigo para morir.
// Parámetros:
//   - x: Posición x de la bala.
//   - y: Posición y de la bala.
// Retorna: 1 si hay colisión, 0 si no.
// Los PROCESS se ejecutan en paralelo, mientras que las FUNCTION se ejecutan de forma secuencial
// - Es decir, hasta que no termine esta función, el proceso que lo llama queda bloqueado
FUNCTION comprobar_colision_bala_enemigos(x, y);
PRIVATE
    id_enemigo;  // ID del enemigo para iterar
BEGIN
    // Comprobamos si hay colisión con enemigos tipo 1
    // Para ello obtenemos el primer ID de enemigo tipo 1
    id_enemigo = get_id(type enemigo_tipo1);
    // Bucle, recorriendo todos los enemigos tipo 1
    WHILE (id_enemigo)
        // Obtenemos la distancia entre bala y enemigo
        IF (fget_dist(x, y, id_enemigo.x, id_enemigo.y) < DISTANCIA_COLISION)
            // Hay colisión
            puntos += PUNTOS_POR_ENEMIGO;  // Sumamos puntos
            explosion(id_enemigo.x, id_enemigo.y, COLOR_ENEMIGO1);  // Creamos explosión
            enemigo_muerto_id = id_enemigo;  // Marcamos el enemigo como muerto
            RETURN(1);  // 1 -> Indicamos colisión
        END
        id_enemigo = get_id(type enemigo_tipo1);  // Siguiente enemigo
    END
    
    // Comprobamos si hay colisión con enemigos tipo 2
    // Para ello obtenemos el primer ID de enemigo tipo 2
    id_enemigo = get_id(type enemigo_tipo2);
    // Bucle, recorriendo todos los enemigos tipo 2
    WHILE (id_enemigo)
        // Calcular distancia entre bala y enemigo
        IF (fget_dist(x, y, id_enemigo.x, id_enemigo.y) < DISTANCIA_COLISION)
            // Hay colisión
            puntos += PUNTOS_POR_ENEMIGO;  // Sumamos puntos
            explosion(id_enemigo.x, id_enemigo.y, COLOR_ENEMIGO2);  // Creamos explosión
            enemigo_muerto_id = id_enemigo;  // Marcamos enemigo para morir
            RETURN(1);  // 1 -> Indicamos colisión
        END
        id_enemigo = get_id(type enemigo_tipo2);  // Siguiente enemigo
    END
    
    RETURN(0);  // 0 -> No hay colisión
END

Con esto ya tenemos algo jugable. Ahora bien, queda feo tener un proceso por tipo de enemigo. Si mañana queremos tener 50, ¿creamos 50 procesos distintos en el código? Bueno, pues auqi viene el cuarto ejemplo, que a nivel funcional ofrece exactamente lo mismo que el anterior, pero con optiomizaciones (https://github.com/LeHamsterRuso/DIV2Examples/blob/main/PRG/VSHOOT04.PRG).

Para emepzar creo una variable de tipo local llamada "tipo". Las variables locales en Div Games Studio actuan como propiedades. Es decir, todos los procesos del programa (enemigo, iniciar_nivel, jugador...) pasan a tener una variable llamada "tipo", pero esta variable, en su contexto, es independiente: Puedes crear 50 instancias de un proceso y asignarle valores disntintos a cada uno de ellos.

// Variables locales
// Las variables locales son atributos presentes en TODOS los process.
// - Su valor puede ser modificado únicamente desde su propio process
// - No obstante, podemos consultarlas desde cualquier otro process -> TIPO = enemigo.tipo
// - Sirve para falsear la orientación a objetos, actuaría como una "propiedad" del objeto en modo read only
LOCAL
    INT tipo; // Tipo de enemigo (1 o 2), empleado sólo en el proceso genérico de enemigos

// Variables internas

Dicho esto, borro las definiciones de enemigo_tipo1 y enemigo_tipo2 y creo un único proceso que haga uso de esa variable local:

// Proceso: enemigo
// Descripción: Controla el comportamiento de un enemigo (tipo 1 o 2).
// - Se mueve según el tipo, dispara balas y verifica si muere.
// Parámetros:
//   - x: Posición inicial x.
//   - y: Posición inicial y.
//   - tipo: Tipo de enemigo (1 o 2).
// (OPTIMIZACIÓN: Proceso genérico para ambos tipos de enemigos.
// Reduce duplicación de código. Usa parámetro 'tipo' para diferenciar comportamiento.
// Mejora mantenibilidad: cambios en un lugar afectan a ambos tipos.)
PROCESS enemigo(x, y, tipo);
PRIVATE
    dir = 1;  // Para tipo 1
    ang = 0;  // Para tipo 2
    tiempo = 0;
    temp_id = 0;  // Para iterar en bucles
    enemigo_draws[5];  // 0: box/circulo para tipo1, 1-4: lineas para tipo2, 5: circulo tipo2
BEGIN
    // Dibujo inicial del enemigo
    IF (tipo == 1)
        dibujar_enemigo_tipo1(&enemigo_draws[0], &enemigo_draws[1], x, y);
    ELSE
        dibujar_enemigo_tipo2(&enemigo_draws[0], &enemigo_draws[1], &enemigo_draws[2], &enemigo_draws[3], &enemigo_draws[4], x, y);
    END

    LOOP
        IF (game_over == 1) RETURN; END

        // Verificar muerte
        IF (enemigo_muerto_id == id)
            // Borrar dibujos
            FROM temp_id=0 TO 4;
                IF (enemigo_draws[temp_id] != 0) delete_draw(enemigo_draws[temp_id]); END
            END
            enemigos_vivos--;
            enemigo_muerto_id = 0;
            RETURN;
        END
        
        // Dibujar y mover basado en tipo solo si controles activos
        IF (controles_activos == 1)
            IF (tipo == 1)
                dibujar_enemigo_tipo1(&enemigo_draws[0], &enemigo_draws[1], x, y);
                mover_enemigo_tipo1(&x, &y, &dir);
                IF (y > ALTO_PANTALLA + 10) RETURN; END
            ELSE
                dibujar_enemigo_tipo2(&enemigo_draws[0], &enemigo_draws[1], &enemigo_draws[2], &enemigo_draws[3], &enemigo_draws[4], x, y);
                mover_enemigo_tipo2(&x, &y, &ang);
            END
        END
        
        // Disparar si corresponde
        IF (controles_activos == 1)
            IF (tipo == 1)
                disparar_enemigo_tipo1(&tiempo, x, y);
            ELSE
                disparar_enemigo_tipo2(&tiempo, x, y);
            END
        END
        
        FRAME;
    END
END

¿Podría haberme limitado a usar una variable privada tipo y pasarlo como parámetro a enemigo? Pues sí, pero me apetecía explicar que las variables locales existen y para qué sirven. De hecho, ahora que definimos la variable como local, puede ser consultada de forma externa por otras funciones y procesos, cosa que no podríamos hacer si la variable fuera privada:

// Función: comprobar_colision_bala_enemigos
// Descripción: Verifica si la bala del jugador colisiona con algún enemigo. Si hay colisión, suma puntos, crea explosión y marca al enemigo para morir.
// Parámetros:
//   - x: Posición x de la bala.
//   - y: Posición y de la bala.
// Retorna: 1 si hay colisión, 0 si no.
// Los PROCESS se ejecutan en paralelo, mientras que las FUNCTION se ejecutan de forma secuencial
// - Es decir, hasta que no termine esta función, el proceso que lo llama queda bloqueado
FUNCTION comprobar_colision_bala_enemigos(x, y);
PRIVATE
    id_enemigo;       // ID del enemigo para iterar
    color_explosion;  // Color para la explosión del enemigo
BEGIN
    // Comprobamos si hay colisión con enemigos
    // Para ello obtenemos el primer ID de enemigo
    id_enemigo = get_id(type enemigo);
    // Bucle, recorriendo todos los enemigos
    WHILE (id_enemigo)
        // Obtenemos la distancia entre bala y enemigo
        IF (fget_dist(x, y, id_enemigo.x, id_enemigo.y) < DISTANCIA_COLISION)
            // Hay colisión
            puntos += PUNTOS_POR_ENEMIGO;  // Sumamos puntos
            // Determinamos el color de la explosión según el tipo de enemigo
            IF (id_enemigo.tipo == 1)
                color_explosion = COLOR_ENEMIGO1;
            ELSE
                color_explosion = COLOR_ENEMIGO2;
            END
            explosion(id_enemigo.x, id_enemigo.y, color_explosion);  // Creamos explosión
            enemigo_muerto_id = id_enemigo;  // Marcamos el enemigo como muerto
            RETURN(1);  // 1 -> Indicamos colisión
        END
        id_enemigo = get_id(type enemigo);  // Siguiente enemigo
    END
    RETURN(0);
END

Pero no es la única optimización que podríamos aplicar. De hecho, en el ejemplo 5 seguimos sin cambiar funcionalmente el juego y nos centramos en ir aún más lejos con las optimizaciones (https://github.com/LeHamsterRuso/DIV2Examples/blob/main/PRG/VSHOOT05.PRG). ¿Cómo? Pues con dos grandes conocidos del capítulo 2 (que os ha dado pesadillas): ¡Uso de estructuras y de un único hilo para dibujar a todos los enemigos!

Para empezar, ese hermosa variable local que habíamos creado nos la cepillamos y creamos una estructura genérica para los eneigos. En ella definimos su posición (x, y), el tipo de enemigo, si está vivo o muerto, la dirección de su desplazamiento, su ángulo de movimiento (para el tipo 2) y un array de enteros donde almacenar los ID de las primitivas gráficas que lo representan.

// Definición de struct para enemigo
STRUCT enemigo[10]
    INT x;       // Posición X
    INT y;       // Posición Y
    INT tipo;    // Tipo de enemigo (1 o 2)
    INT activo;  // Si está activo (1) o muerto/inactivo (0)
    INT dir;     // Dirección horizontal para tipo1 (1 derecha, -1 izquierda)
    INT ang;     // Ángulo para movimiento circular de tipo2
    INT draw[5]; // Array de IDs de dibujos (5 slots por enemigo)
END

Luego, borramos el proceso enemigo y creamos un "proceso_enemigos" para gestionar TODOS los enemigos en bucle. ¡Fijaros que reutilizamos los métodos ya existentes de dibujo y movimiento (gracias a la magia de los punteros), pero recorremos todos los enemigos que hay en la estructura para ver si están vivos o muertos y actuar en consecuencia:

// Proceso: proceso_enemigos
// Descripción: Controla el comportamiento de todos los enemigos usando un STRUCT array.
// - Maneja movimiento, disparos y eliminación de enemigos tipo 1 y 2.
// (OPTIMIZACIÓN: Proceso genérico para ambos tipos de enemigos.
// Reduce duplicación de código. Usa parámetro 'tipo' para diferenciar comportamiento.
// Mejora mantenibilidad: cambios en un lugar afectan a ambos tipos.)
PROCESS proceso_enemigos();
PRIVATE
    INT i, j;
    INT tiempo_disparo[10];  // Contador de tiempo para disparos de cada enemigo
BEGIN
    // Dibujo inicial de todos los enemigos
    FOR (i=0; i<10; i++)
        IF (enemigo[i].activo == 1)
            IF (enemigo[i].tipo == 1)
                // Dibujamos el enemigo
                dibujar_enemigo_tipo1(&enemigo[i].draw[0], &enemigo[i].draw[1], enemigo[i].x, enemigo[i].y);
            ELSE
                // Dibujamos el enemigo de tipo 2
                dibujar_enemigo_tipo2(&enemigo[i].draw[0], &enemigo[i].draw[1], &enemigo[i].draw[2], &enemigo[i].draw[3], &enemigo[i].draw[4], enemigo[i].x, enemigo[i].y);
            END
        END
    END

    LOOP
        // Si el juego ha terminado, salimos del proceso
        IF (game_over == 1) RETURN; END

        // Por cada enemigo
        FOR (i=0; i<10; i++)
            // Verificamos si está vivo
            IF (enemigo[i].activo == 1)
                // Verificamos si los controles están activos (p. ej., no durante la cuenta regresiva)
                IF (controles_activos == 1)
                    // Movemos en función del tipo
                    IF (enemigo[i].tipo == 1)
                        // Movemos el enemigo tipo 1
                        mover_enemigo_tipo1(&enemigo[i].x, &enemigo[i].y, &enemigo[i].dir);
                    ELSE
                        // Movemos el enemigo tipo 2
                        mover_enemigo_tipo2(&enemigo[i].x, &enemigo[i].y, &enemigo[i].ang);
                    END

                    // Verificar si sale de pantalla
                    IF (enemigo[i].tipo == 1 AND enemigo[i].y > ALTO_PANTALLA + TAMANO_ENEMIGO1)
                        enemigo[i].activo = 0;
                        FROM j=0 TO 4;
                            IF (enemigo[i].draw[j] != 0) delete_draw(enemigo[i].draw[j]); END
                        END
                    END

                    // Dibujamos el enemigo en función del tipo
                    IF (enemigo[i].tipo == 1)
                        dibujar_enemigo_tipo1(&enemigo[i].draw[0], &enemigo[i].draw[1], enemigo[i].x, enemigo[i].y);
                    ELSE
                        dibujar_enemigo_tipo2(&enemigo[i].draw[0], &enemigo[i].draw[1], &enemigo[i].draw[2], &enemigo[i].draw[3], &enemigo[i].draw[4], enemigo[i].x, enemigo[i].y);
                    END

                    // Disparar en función del tipo
                    IF (enemigo[i].tipo == 1)
                        disparar_enemigo_tipo1(&tiempo_disparo[i], enemigo[i].x, enemigo[i].y);
                    ELSE
                        disparar_enemigo_tipo2(&tiempo_disparo[i], enemigo[i].x, enemigo[i].y);
                    END
                END
            END
        END

        FRAME;
    END
END

Fijaros que también, a su vez, el código acaba siendo más sencillo cuando manejamos estructuras. Por ejemplo, reducimos aún más el tamaño de las funciones de detección colisiones:

// Función: comprobar_colision_bala_enemigos
// Descripción: Verifica si la bala del jugador colisiona con algún enemigo. Si hay colisión, retorna el index del enemigo.
// Parámetros:
//   - x: Posición x de la bala.
//   - y: Posición y de la bala.
// Retorna: Index del enemigo colisionado (0-4), o -1 si no hay colisión.
// Los PROCESS se ejecutan en paralelo, mientras que las FUNCTION se ejecutan de forma secuencial
// - Es decir, hasta que no termine esta función, el proceso que lo llama queda bloqueado
FUNCTION comprobar_colision_bala_enemigos(INT x, INT y);
PRIVATE
    INT i;  // Variable para el bucle
BEGIN
    // Comprobamos si hay colisión con enemigos iterando sobre el array
    FOR (i=0; i<10; i++)
        IF (enemigo[i].activo == 1)
            // Obtenemos la distancia entre bala y enemigo
            IF (fget_dist(x, y, enemigo[i].x, enemigo[i].y) < DISTANCIA_COLISION)
                RETURN(i);  // Retornamos el index del enemigo colisionado
            END
        END
    END
    RETURN(-1);  // No hay colisión
END

Bueno, pues ahora que tenemos un juego potable y algo optimizado, podemos empezar a trabajar con sprites y aquí entra el ejemplo 6 (https://github.com/LeHamsterRuso/DIV2Examples/blob/main/PRG/VSHOOT06.PRG). Este ejemplo es básicamente el anterior, pero adaptado para trabajar con sprites.

El mayor cambio reside en que, como he querido animar al personaje principal, he utilizado distintos gráficos para él en función de la tecla que pulsamos y de si estamos disparando o no. Es decir, si nos desplazamos o si disparamos, el gráfico va cambiando de forma dinámica.

Básicamente tenemos un fichero FPG para él con 16 gráficos. Los 8 primeros representan las 8 posiciones posibles en las que podemos depslazarnos (arriba, abajo, izquierda, derecha y diagonales) cuando no estamos disparando y las 8 siguientes es lo mismo, pero disparando. Sobre qué gráfico va primero, pues lo gestiono como si fueran las agujas del reloj -> 1 sería mirar arriba, 2 arriba/derecha, 3 derecha... y así hasta 8 izquierda/arriba.

// Función: calcular_grafico_jugador
// Descripción: Calcula el ID del gráfico según dirección y estado de disparo
// Retorna: ID del gráfico (1-18)
FUNCTION calcular_grafico_jugador(INT dir_x, INT dir_y, INT disparando);
PRIVATE
    INT base_grafico = 0;
    INT offset_direccion = 0;
BEGIN
    // Base: 0 si no dispara, 9 si dispara
    IF (disparando == 1)
        base_grafico = 9;
    ELSE
        base_grafico = 0;
    END

    // Calcular offset según dirección
    // Quieto
    IF (dir_x == 0 AND dir_y == 0)
        offset_direccion = 1;
    END
    // Arriba
    IF (dir_x == 0 AND dir_y == -1)
        offset_direccion = 2;
    END
    // Arriba derecha
    IF (dir_x == 1 AND dir_y == -1)
        offset_direccion = 3;
    END
    // Derecha
    IF (dir_x == 1 AND dir_y == 0)
        offset_direccion = 4;
    END
    // Derecha abajo
    IF (dir_x == 1 AND dir_y == 1)
        offset_direccion = 5;
    END
    // Abajo
    IF (dir_x == 0 AND dir_y == 1)
        offset_direccion = 6;
    END
    // Abajo izquierda
    IF (dir_x == -1 AND dir_y == 1)
        offset_direccion = 7;
    END
    // Izquierda
    IF (dir_x == -1 AND dir_y == 0)
        offset_direccion = 8;
    END
    // Arriba izquierda
    IF (dir_x == -1 AND dir_y == -1)
        offset_direccion = 9;
    END

    RETURN(base_grafico + offset_direccion);
END

Sobre los sprites en cuestión, decidí bastame en el universo de Saga of Tanya The Evil de Carlo Zen (su mangaka, Chika Tojo, me cae genial). Su protagonista, Tanya, la he modelado varias veces en Blender y decidí hacer uso de una versión modificada que subí a sketchfab en verano y que, pese a ser uno de mis modelos preferidos y de los que más orgulloso estoy, lleva la friolera de cero likes (https://sketchfab.com/3d-models/tanya-degurechaff-from-saga-of-tanya-the-evil-fb725e63784d4839928aa8ea6fe28e56).

Y esto me consumió batante tiempo, puesto que el modelo de Tanya no lo tenía animado conforme yo quería para este juego y tuve que "riguear" poses nuevas para luego renderizarlas.

Para los enemigos fue más sencillo. Generé modelos con Meshy.AI y luego los rendericé por Blender.

Y para los escenarios tiré de ChatGPT.

Ahora bien, el proceso de adaptar los gráficos para Div Games Studio fue bastante tortuoso. Lo primero es que, por comodidad, decidí emplear una única paleta de colores para todos los niveles. Esto me obligaba, por ejemplo, a crearme una paleta en Gimp para poder hacer uso de ella en el modo "Imagen/Modo/Indexado". Además, para mitigar la limitacion de 256 colores forcé el dithering activando el tramado de color posicionado:

Para crear la paleta en Gimp, lo que hice fue crear desde Div2 un dibujo random en formato PCX con la tableta "DIV2.PAL".

Por otro lado también implementé una pequeña explosión que se vea en el fusil de Tanya cuando dispara:

// Proceso: explosion_pequena
// Descripción: Crea una animación de explosión pequeña para efectos de disparo
// - Más pequeña y rápida que la explosión normal
// Parámetros:
//   - x: Posición x de la explosión.
//   - y: Posición y de la explosión.
//   - color: Color de la explosión.
PROCESS explosion_pequena(x, y, color);
PRIVATE
    i;  // Contador para el bucle
    radio = 3;  // Radio inicial más pequeño
    exp_draw;  // ID del dibujo de la explosión
BEGIN
    // Animamos la explosión pequeña
    FROM i=0 TO 3;  // Menos iteraciones para que sea más rápida
        IF (exp_draw != 0) delete_draw(exp_draw); END
        exp_draw = draw(5, color, OPACIDAD_DRAW, REGION_DRAW, x - radio, y - radio, x + radio, y + radio);
        radio++;  // Incremento menor
        FRAME;
    END
    delete_draw(exp_draw);
END

Ahora bien, con este ejemplo 6 me di cuenta de una cosa bastante básica y es que, si desplazaba al personaje a una esquina y dejaba que los enemigos dispararan... pues habían ralentizaciones, el juego tenía bajones de frames. Y es que, aunque habíamos optimizado los enemigos, ¡pero no las balas! Y justamente en un juego de tipo bullet-hell como el que estabamos creando ahora mismo, era obvio que en pantalla tendríamos más balas que enemigos. "Lo siento mucho, me he equivocado, no volverá a ocurrir".

Así me puse a implementar el ejemplo 7, que es, a nivel jugable, idéntico al anterior, pero optimizando las balas (https://github.com/LeHamsterRuso/DIV2Examples/blob/main/PRG/VSHOOT07.PRG). ¿Cómo? ¡Pues con estructuras y un proceso común para dibujarlas todas!

// Definición de struct para balas del jugador (OPTIMIZACIÓN: Lista enlazada separada)
// Almacena balas del jugador en array con lista enlazada para optimizar acceso
STRUCT bala_jugador[MAX_BALAS_JUGADOR]
    INT x;         // Posición X de la bala
    INT y;         // Posición Y de la bala
    INT activo;    // Si está activa (1) o inactiva (0)
    INT dx;        // Delta X precalculado para movimiento (siempre 0 para jugador)
    INT dy;        // Delta Y precalculado para movimiento (hacia arriba)
    INT tamano;    // Tamaño precalculado para dibujo
    INT color;     // Color precalculado para dibujo
    INT draw_id;   // ID del dibujo de la bala
    INT siguiente; // Índice del siguiente slot en la lista (-1 = fin de lista)
END

// Definición de struct para balas enemigas (OPTIMIZACIÓN: Lista enlazada separada)
// Almacena balas enemigas en array con lista enlazada para optimizar acceso
STRUCT bala_enemigo[MAX_BALAS_ENEMIGO]
    INT x;         // Posición X de la bala
    INT y;         // Posición Y de la bala
    INT tipo;      // Tipo de bala enemiga (1=enemigo1, 2=enemigo2)
    INT activo;    // Si está activa (1) o inactiva (0)
    INT angulo;    // Ángulo de movimiento (para balas enemigo tipo 2)
    INT dx;        // Delta X precalculado para movimiento
    INT dy;        // Delta Y precalculado para movimiento
    INT tamano;    // Tamaño precalculado para dibujo
    INT color;     // Color precalculado para dibujo
    INT draw_id;   // ID del dibujo de la bala
    INT siguiente; // Índice del siguiente slot en la lista (-1 = fin de lista)
END

Cosas a tener en cuenta: Veréis un INT de "Siguiente". Esto es debido a que, como tienen que haber tantas balas en pantalla, hace falta hacer un sistema de listas. Si digo al compilador que pueden haber 256 balas en pantalla como máximo, resulta contraproducente crear bucles donde se recorran las 256 posiciones del array de balas, existan o no, para cada verificación que tenga que ver con balas. Lo que sí que puedo hacer es marcar con un "-1" en siguiente para decirle a un bucle "no sigas recorriendo el array de balas, no ay más ahora mismo:

// Proceso: proceso_balas_jugador (OPTIMIZACIÓN: Proceso separado para balas del jugador)
// Descripción: Proceso dedicado que gestiona solo balas del jugador usando lista enlazada
// - Solo procesa balas activas del jugador siguiendo la lista enlazada
// - Mueve, dibuja y verifica colisiones con enemigos
// - Elimina balas que salen de pantalla o colisionan
PROCESS proceso_balas_jugador();
PRIVATE
    INT actual;             // Índice de la bala actual en la lista
    INT anterior;           // Índice de la bala anterior en la lista
    INT siguiente;          // Índice de la bala siguiente (guardado antes de posible eliminación)
    INT enemigo_index;      // Índice del enemigo colisionado
    INT color_explosion;    // Color de explosión
    INT debe_eliminar;      // Flag para marcar si debe eliminarse
BEGIN
    LOOP
        // Si el juego terminó, salimos
        IF (game_over == 1) RETURN; END

        // PROCESAR BALAS DEL JUGADOR
        anterior = -1;
        actual = primera_bala_jugador_activa;
        
        WHILE (actual != -1)
            // Guardar el siguiente antes de posibles modificaciones
            siguiente = bala_jugador[actual].siguiente;
            debe_eliminar = 0;
            
            IF (bala_jugador[actual].draw_id != 0)
                delete_draw(bala_jugador[actual].draw_id);
                bala_jugador[actual].draw_id = 0;
            END

            // Mover la bala según deltas precalculados
            bala_jugador[actual].x += bala_jugador[actual].dx;
            bala_jugador[actual].y += bala_jugador[actual].dy;
            
            // Verificar si sale de pantalla
            IF (bala_jugador[actual].y < 0 OR bala_jugador[actual].y > ALTO_PANTALLA OR bala_jugador[actual].x < 0 OR bala_jugador[actual].x > ANCHO_PANTALLA)
                debe_eliminar = 1;
            ELSE
                // Colisión con enemigos
                enemigo_index = comprobar_colision_bala_enemigos(bala_jugador[actual].x, bala_jugador[actual].y);
                IF (enemigo_index != -1)
                    puntos += PUNTOS_POR_ENEMIGO;
                    IF (enemigo[enemigo_index].tipo == 1)
                        color_explosion = COLOR_ENEMIGO1;
                    ELSE
                        color_explosion = COLOR_ENEMIGO2;
                    END
                    explosion(enemigo[enemigo_index].x, enemigo[enemigo_index].y, color_explosion);
                    enemigo[enemigo_index].activo = 0;
                    remover_enemigo_lista(enemigo_index);
                    enemigos_vivos--;
                    debe_eliminar = 1;
                END
            END
            
            // Eliminar bala de la lista si es necesario
            IF (debe_eliminar == 1)
                // Sacar de lista de activas
                IF (anterior == -1)
                    primera_bala_jugador_activa = siguiente;
                ELSE
                    bala_jugador[anterior].siguiente = siguiente;
                END
                
                // Marcar como inactiva
                bala_jugador[actual].activo = 0;
                
                // Devolver a lista de libres
                bala_jugador[actual].siguiente = primer_slot_libre_jugador;
                primer_slot_libre_jugador = actual;
            ELSE
                // Dibujar la bala
                bala_jugador[actual].draw_id = draw(TIPO_DIBUJO_CIRCULO_RELLENO, bala_jugador[actual].color, OPACIDAD_DRAW, REGION_DRAW, bala_jugador[actual].x - bala_jugador[actual].tamano, bala_jugador[actual].y - bala_jugador[actual].tamano, bala_jugador[actual].x + bala_jugador[actual].tamano, bala_jugador[actual].y + bala_jugador[actual].tamano);
                
                // Avanzar anterior solo si no eliminamos
                anterior = actual;
            END
            
            // Avanzar al siguiente
            actual = siguiente;
        END

        FRAME;  // Esperar al siguiente frame
    END
END

Ahora que hemos reoptimizado el código para evitar bajones de frames, deberíamos adaptar el juego para que sea más divertido. Quiero decir, ahora mismo tenemos un escenario inmovil con diez enemigos fijos... y en eso consiste nuestro ejemplo 8 (https://github.com/LeHamsterRuso/DIV2Examples/blob/main/PRG/VSHOOT08.PRG). En esta versión implementamos un scroll (con start_scroll, no el falso scroll del capítulo 2), repartimos 80 enemigos por todo el escenario e implementamos rutinas para revisar que los enemigos que están fuera de la pantalla no se dibujen y que las barras que salen de nuestra pantalla se destruyan (pensad que las coordenadas no son iguales si usamos scroll o no).

//------------------------------------------------------------------------------
// PROCESS: proceso_enemigos (MODIFICADO PARA SCROLL)
// DESCRIPCIÓN: Controla el comportamiento de todos los enemigos usando un STRUCT array.
//              Maneja movimiento, disparos y eliminación de enemigos tipo 1 y 2.
//              Ahora solo procesa y dibuja enemigos visibles en la pantalla actual del scroll.
//              Usa procesos hijos con ctype=c_screen para visualizar cada enemigo.
//------------------------------------------------------------------------------
PROCESS proceso_enemigos();
PRIVATE
    INT i, j;
    INT tiempo_disparo[NUM_ENEMIGOS_INICIAL];  // Contador de tiempo para disparos de cada enemigo
    INT enemigo_visible;     // Flag para verificar si el enemigo está visible
    INT procesos_enemigo[NUM_ENEMIGOS_INICIAL]; // IDs de procesos hijos para cada enemigo
BEGIN
    // Inicializar array de procesos
    FROM i=0 TO NUM_ENEMIGOS_INICIAL - 1;
        procesos_enemigo[i] = 0;
    END

    LOOP
        // Si el juego ha terminado, salimos del proceso
        IF (game_over == 1)
            // Terminar todos los procesos hijos
            FOR (i=0; i<NUM_ENEMIGOS_INICIAL; i++)
                IF (procesos_enemigo[i] != 0)
                    signal(procesos_enemigo[i], s_kill);
                    procesos_enemigo[i] = 0;
                END
            END
            RETURN;
        END

        // Por cada enemigo
        FOR (i=0; i<NUM_ENEMIGOS_INICIAL; i++)
            // Verificamos si está vivo
            IF (enemigo[i].activo == 1)
                // OPTIMIZACIÓN: Solo procesar enemigos visibles en el scroll actual
                // Un enemigo es visible si su Y está entre scroll.y0 - MARGEN y scroll.y0 + ALTO_PANTALLA + MARGEN
                enemigo_visible = 0;
                IF (enemigo[i].y >= scroll.y0 - MARGEN_VISIBLE_ARRIBA AND enemigo[i].y <= scroll.y0 + ALTO_PANTALLA + MARGEN_VISIBLE_ABAJO)
                    enemigo_visible = 1;
                END

                // Solo procesar si está visible
                IF (enemigo_visible == 1)
                    // Crear proceso hijo si no existe
                    IF (procesos_enemigo[i] == 0)
                        procesos_enemigo[i] = proceso_enemigo_visual(i);
                    END

                    // Solo mover y disparar si los controles están activos
                    IF (controles_activos == 1)
                        // Movemos en función del tipo
                        IF (enemigo[i].tipo == 1)
                            // Movemos el enemigo tipo 1
                            mover_enemigo_tipo1(&enemigo[i].x, &enemigo[i].y, &enemigo[i].dir);
                        ELSE
                            // Movemos el enemigo tipo 2
                            mover_enemigo_tipo2(&enemigo[i].x, &enemigo[i].y, &enemigo[i].ang);
                        END

                        // Verificar si sale del área visible por abajo
                        IF (enemigo[i].y > scroll.y0 + ALTO_PANTALLA + MARGEN_VISIBLE_ABAJO)
                            enemigo[i].activo = 0;
                            remover_enemigo_lista(i);
                            enemigos_vivos--;
                        END

                        // Disparar en función del tipo
                        IF (enemigo[i].tipo == 1)
                            disparar_enemigo_tipo1(&tiempo_disparo[i], enemigo[i].x, enemigo[i].y);
                        ELSE
                            disparar_enemigo_tipo2(&tiempo_disparo[i], enemigo[i].x, enemigo[i].y);
                        END
                    END
                ELSE
                    // Enemigo no visible, eliminar proceso hijo si existe
                    IF (procesos_enemigo[i] != 0)
                        signal(procesos_enemigo[i], s_kill);
                        procesos_enemigo[i] = 0;
                    END
                END
            ELSE
                // Enemigo muerto, eliminar proceso hijo si existe
                IF (procesos_enemigo[i] != 0)
                    signal(procesos_enemigo[i], s_kill);
                    procesos_enemigo[i] = 0;
                END
            END
        END

        FRAME;
    END
END

//------------------------------------------------------------------------------
// PROCESS: proceso_enemigo_visual (NUEVO)
// DESCRIPCIÓN: Proceso hijo liviano que solo se encarga de visualizar un enemigo.
//              Usa ctype=c_screen para coordenadas de pantalla.
//              Lee los datos del enemigo desde el struct enemigo[].
//------------------------------------------------------------------------------
PROCESS proceso_enemigo_visual(INT index);
BEGIN
    ctype = c_screen;  // Usar coordenadas de pantalla
    file = FPG_LEVEL;  // Archivo de gráficos

    LOOP
        // Si el enemigo ya no está activo o el juego terminó, salir
        IF (enemigo[index].activo == 0 OR game_over == 1)
            RETURN;
        END

        // Actualizar posición en pantalla (convertir de coordenadas de mapa a pantalla)
        x = enemigo[index].x - scroll.x0;
        y = enemigo[index].y - scroll.y0;

        // Actualizar gráfico según tipo
        IF (enemigo[index].tipo == 1)
            graph = GRAFICO_ENEMIGO1;
            // Rotar según dirección de movimiento
            IF (enemigo[index].dir == 1)
                angle = ANGULO_ROTACION_ENEMIGO;  // Rotar 15° a la derecha
            ELSE
                angle = ANGULO_ROTACION_ENEMIGO_OPUESTA;  // Rotar 15° a la izquierda
            END
            size = ESCALA_ENEMIGO;
        ELSE
            graph = GRAFICO_ENEMIGO2;
            angle = 0;
            size = 100;
        END

        FRAME;
    END
END

Con todo esto ya vamos teniendo un juego más o menos potable, pero siempre podemos ir a más. En el siguiente ejemplo, el 9, (https://github.com/LeHamsterRuso/DIV2Examples/blob/main/PRG/VSHOOT09.PRG), vamos más lejos e implementamos un sistema de niveles distintos, cada uno con su propio fichero FPG. En cada nivel, además, incrementamos el número de enemigos: Empezamos con 40, después 50, después 60... y así vamos sumando de diez en diez en cada fase. Además, el reparto de enemigos lo hacemos de forma escalonada, haciendo que haya pocos enemigos de inicio y muchos al final. También se implementa un sistema de vidas, para que el personaje del jugador no muera al primer toque e incluso cambiamos su fichero FPG en función del número de toques recibido (para dibujarlo sin casco al recibir el primer balazo y sin mochila al recibir el segundo).

//------------------------------------------------------------------------------
// FUNCIÓN: cargar_fpg_nivel
// DESCRIPCIÓN: Carga el FPG correspondiente al nivel actual
//              Descarga el FPG anterior si existe y carga el nuevo
//------------------------------------------------------------------------------
FUNCTION cargar_fpg_nivel(INT nivel_fpg);
PRIVATE
    STRING ruta_fpg;  // Ruta del FPG a cargar
    STRING numero_str;  // Número del nivel como string
BEGIN
    // Descargar el FPG anterior si existe
    IF (FPG_LEVEL != 0)
        unload_fpg(FPG_LEVEL);
    END

    // Construir la ruta del FPG según el nivel
    // LEVEL000.FPG, LEVEL001.FPG, ..., LEVEL009.FPG, LEVEL010.FPG, LEVEL011.FPG, LEVEL012.FPG
    numero_str = itoa(nivel_fpg);

    // Agregar ceros a la izquierda según sea necesario
    IF (nivel_fpg < 10)
        ruta_fpg = "TANYA/LEVEL00" + numero_str + ".FPG";
    ELSE
        ruta_fpg = "TANYA/LEVEL0" + numero_str + ".FPG";
    END

    // Cargar el nuevo FPG
    FPG_LEVEL = load_fpg(ruta_fpg);
END

// Proceso: proceso_balas_jugador (OPTIMIZACIÓN: Proceso separado para balas del jugador)
// Descripción: Proceso dedicado que gestiona solo balas del jugador usando lista enlazada
// - Solo procesa balas activas del jugador siguiendo la lista enlazada
// - Mueve, dibuja y verifica colisiones con enemigos
// - Elimina balas que salen de pantalla o colisionan
PROCESS proceso_balas_jugador();
PRIVATE
    INT actual;             // Índice de la bala actual en la lista
    INT anterior;           // Índice de la bala anterior en la lista
    INT siguiente;          // Índice de la bala siguiente (guardado antes de posible eliminación)
    INT enemigo_index;      // Índice del enemigo colisionado
    INT color_explosion;    // Color de explosión
    INT debe_eliminar;      // Flag para marcar si debe eliminarse
BEGIN
    LOOP
        // Si el juego terminó, salimos
        IF (game_over == 1) RETURN; END

        // PROCESAR BALAS DEL JUGADOR
        anterior = -1;
        actual = primera_bala_jugador_activa;

        WHILE (actual != -1)
            // Guardar el siguiente antes de posibles modificaciones
            siguiente = bala_jugador[actual].siguiente;
            debe_eliminar = 0;

            // Mover la bala según deltas precalculados
            bala_jugador[actual].x += bala_jugador[actual].dx;
            bala_jugador[actual].y += bala_jugador[actual].dy;

            // Verificar si sale del área visible del scroll (eliminar balas fuera de pantalla)
            IF (bala_jugador[actual].y < scroll.y0 - MARGEN_VISIBLE_ARRIBA OR
                bala_jugador[actual].y > scroll.y0 + ALTO_PANTALLA + MARGEN_VISIBLE_ABAJO OR
                bala_jugador[actual].x < 0 OR
                bala_jugador[actual].x > ANCHO_PANTALLA)
                debe_eliminar = 1;
            ELSE
                // Colisión con enemigos
                enemigo_index = comprobar_colision_bala_enemigos(bala_jugador[actual].x, bala_jugador[actual].y);
                IF (enemigo_index != -1)
                    puntos += PUNTOS_POR_ENEMIGO;
                    IF (enemigo[enemigo_index].tipo == 1)
                        color_explosion = COLOR_ENEMIGO1;
                    ELSE
                        color_explosion = COLOR_ENEMIGO2;
                    END
                    explosion(enemigo[enemigo_index].x, enemigo[enemigo_index].y, color_explosion);
                    enemigo[enemigo_index].activo = 0;
                    remover_enemigo_lista(enemigo_index);
                    enemigos_vivos--;
                    debe_eliminar = 1;
                END
            END

            // Eliminar bala de la lista si es necesario
            IF (debe_eliminar == 1)
                // Sacar de lista de activas
                IF (anterior == -1)
                    primera_bala_jugador_activa = siguiente;
                ELSE
                    bala_jugador[anterior].siguiente = siguiente;
                END

                // Marcar como inactiva
                bala_jugador[actual].activo = 0;

                // Devolver a lista de libres
                bala_jugador[actual].siguiente = primer_slot_libre_jugador;
                primer_slot_libre_jugador = actual;
            ELSE
                // Dibujar la bala (convertir coordenadas de mapa a pantalla)
                bala_jugador[actual].draw_id = draw(TIPO_DIBUJO_CIRCULO_RELLENO, bala_jugador[actual].color, OPACIDAD_DRAW, REGION_DRAW,
                    (bala_jugador[actual].x - scroll.x0) - bala_jugador[actual].tamano,
                    (bala_jugador[actual].y - scroll.y0) - bala_jugador[actual].tamano,
                    (bala_jugador[actual].x - scroll.x0) + bala_jugador[actual].tamano,
                    (bala_jugador[actual].y - scroll.y0) + bala_jugador[actual].tamano);

                // Avanzar anterior solo si no eliminamos
                anterior = actual;
            END

            // Avanzar al siguiente
            actual = siguiente;
        END

        FRAME;  // Esperar al siguiente frame
    END
END

// Proceso: proceso_balas_enemigo (OPTIMIZACIÓN: Proceso separado para balas enemigas)
// Descripción: Proceso dedicado que gestiona solo balas enemigas usando lista enlazada
// - Solo procesa balas activas enemigas siguiendo la lista enlazada
// - Mueve, dibuja y verifica colisiones con el jugador
// - Elimina balas que salen de pantalla o colisionan
PROCESS proceso_balas_enemigo();
PRIVATE
    INT actual;             // Índice de la bala actual en la lista
    INT anterior;           // Índice de la bala anterior en la lista
    INT siguiente;          // Índice de la bala siguiente (guardado antes de posible eliminación)
    INT id_player;          // ID del jugador
    INT debe_eliminar;      // Flag para marcar si debe eliminarse
    INT dx, dy;             // Diferencias para cálculo de distancia
    INT dist_cuadrado;      // Distancia al cuadrado (optimización)
BEGIN
    id_player = get_id(type jugador);
    LOOP
        // Si el juego terminó, salimos
        IF (game_over == 1) RETURN; END

        // PROCESAR BALAS ENEMIGAS
        anterior = -1;
        actual = primera_bala_enemigo_activa;

        WHILE (actual != -1)
            // Guardar el siguiente antes de posibles modificaciones
            siguiente = bala_enemigo[actual].siguiente;
            debe_eliminar = 0;

            // Mover la bala según deltas precalculados
            bala_enemigo[actual].x += bala_enemigo[actual].dx;
            bala_enemigo[actual].y += bala_enemigo[actual].dy;

            // Verificar si sale del área visible del scroll (eliminar balas fuera de pantalla)
            IF (bala_enemigo[actual].y < scroll.y0 - MARGEN_VISIBLE_ARRIBA OR
                bala_enemigo[actual].y > scroll.y0 + ALTO_PANTALLA + MARGEN_VISIBLE_ABAJO OR
                bala_enemigo[actual].x < 0 OR
                bala_enemigo[actual].x > ANCHO_PANTALLA)
                debe_eliminar = 1;
            ELSE
                // Colisión con jugador (solo si no está inmune)
                IF (id_player != 0 AND jugador_inmune == 0)
                    // Bounding box rápida
                    IF (abs(bala_enemigo[actual].x - id_player.x) < MARGEN_BOUNDING_BOX AND abs(bala_enemigo[actual].y - id_player.y) < MARGEN_BOUNDING_BOX)
                        // Calcular distancia al cuadrado
                        dx = bala_enemigo[actual].x - id_player.x;
                        dy = bala_enemigo[actual].y - id_player.y;
                        dist_cuadrado = dx * dx + dy * dy;
                        IF (dist_cuadrado < DISTANCIA_COLISION_CUADRADO)
                            // El jugador recibe un impacto
                            vidas_jugador--;
                            explosion(id_player.x, id_player.y, COLOR_NAVE);

                            // Verificar si el jugador murió
                            IF (vidas_jugador <= 0)
                                // Tercera bala = muerte
                                game_over = 1;
                            ELSE
                                // Activar inmunidad temporal y parpadeo
                                jugador_inmune = TIEMPO_INMUNIDAD;

                                // Cambiar FPG según vidas restantes
                                IF (vidas_jugador == 2)
                                    // Primera bala: cambiar a PLAYERME.FPG
                                    id_player.file = FPG_PLAYERME;
                                ELSE
                                    // Segunda bala: cambiar a PLAYERLO.FPG
                                    id_player.file = FPG_PLAYERLO;
                                END
                            END

                            debe_eliminar = 1;
                        END
                    END
                END
            END

            // Eliminar bala de la lista si es necesario
            IF (debe_eliminar == 1)
                // Sacar de lista de activas
                IF (anterior == -1)
                    primera_bala_enemigo_activa = siguiente;
                ELSE
                    bala_enemigo[anterior].siguiente = siguiente;
                END

                // Marcar como inactiva
                bala_enemigo[actual].activo = 0;

                // Devolver a lista de libres
                bala_enemigo[actual].siguiente = primer_slot_libre_enemigo;
                primer_slot_libre_enemigo = actual;
            ELSE
                // Dibujar la bala (convertir coordenadas de mapa a pantalla)
                bala_enemigo[actual].draw_id = draw(TIPO_DIBUJO_CIRCULO_RELLENO, bala_enemigo[actual].color, OPACIDAD_DRAW, REGION_DRAW,
                    (bala_enemigo[actual].x - scroll.x0) - bala_enemigo[actual].tamano,
                    (bala_enemigo[actual].y - scroll.y0) - bala_enemigo[actual].tamano,
                    (bala_enemigo[actual].x - scroll.x0) + bala_enemigo[actual].tamano,
                    (bala_enemigo[actual].y - scroll.y0) + bala_enemigo[actual].tamano);

                // Avanzar anterior solo si no eliminamos
                anterior = actual;
            END

            // Avanzar al siguiente
            actual = siguiente;
        END

        FRAME;  // Esperar al siguiente frame
    END
END

Por último tenemos el ejemplo 10, el que contiene el juego acabado. Aquí creamos el enemigo de tipo 3, añadimos un ranking por puntuación, cargamos cinemáticas (escenas estilo Visual Novel) entre niveles y añadimos efectos de sonido y música (https://github.com/LeHamsterRuso/DIV2Examples/blob/main/PRG/VSHOOT10.PRG). Este es el que presenta mayor dificultad de todos, ya que si haceís un diff con el anterior veréis que cambia casi por completo. Para estas cinemáticas recurri a varias IA generativas: Meshy (Nano Banana), ChatGPT y Grok.

Cosas a tener en en cuenta:

- El sistema de estructuras para las cinemáticas. Como ya he mencionado en otras entradas, Div Games Studio no permite hacer un array de strings, pero nos permite crear un array de un struct que contenga uno o varios strings:

   // Estructuras de datos para cinematicas
    STRUCT cinematics[10]
        INT num_cg;
        INT siguiente_nivel;
        STRUCT cgs[5]
            STRING fpg_ruta;
            STRING pal_ruta;
            STRING wav_ruta;
            INT num_paginas;
            STRUCT paginas[10]
                STRING linea1[50];
                STRING linea2[50];
                STRING linea3[50];
                STRING linea4[50];
            END
        END
    END

En este ejemplo tenemos 10 cinemáticas:

Cada una indica a qué nivel hay que saltar cuando acabe (siguiente_nivel). Además, tenemos una lista de CG (una CG = una imagen).
Cada CG tiene su propio fichero FPG, su propia paleta, su propia melodía y una lista de hasta diez págicas.
Cada página tiene 4 líneas de texto.
Cada línea de texto tiene un tamaño máximo de 50 caracteres.

- Las funciones ligadas al ranking: Cuando añades una puntuación en una posición X, tienes que tener especial cuidado con el algoritmo que empleas para reordenar los posiciones X+1 a N: Si te limitas a hacer X+1 = X, es bastante fácil que acabes clonando puntuaciones erroneamente. Para evitar esto, hago lo contrario -> Desde N hazta X => y = y-1.

//------------------------------------------------------------------------------
// FUNCION: cargar_top_scores
// DESCRIPCION: Carga las 10 mejores puntuaciones desde el archivo TOP.DAT
//              Si el archivo no existe, inicializa con valores por defecto
//              (1000, 900, 800, 700, 600, 500, 400, 300, 200, 100)
//------------------------------------------------------------------------------
FUNCTION cargar_top_scores();
PRIVATE
    INT file_handle;
    INT data_size;
    INT i;
BEGIN
    // Intentar abrir el archivo para lectura
    file_handle = fopen("TOP.DAT", "r");

    IF (file_handle == 0)
        // El archivo no existe, inicializar con valores por defecto
        FROM i = 0 TO 9;
            top_scores[i].score = 1000 - (i * 100);
        END
        RETURN;
    END

    // Leer la estructura completa de puntuaciones
    data_size = sizeof(top_scores);
    fread(OFFSET top_scores, data_size, file_handle);

    // Cerrar el archivo
    fclose(file_handle);
END

//------------------------------------------------------------------------------
// FUNCION: guardar_top_scores
// DESCRIPCION: Guarda las 10 mejores puntuaciones en el archivo TOP.DAT
//------------------------------------------------------------------------------
FUNCTION guardar_top_scores();
PRIVATE
    INT file_handle;
    INT data_size;
BEGIN
    // Abrir el archivo para escritura (crea o sobrescribe)
    file_handle = fopen("TOP.DAT", "w");

    IF (file_handle == 0)
        // Error al crear el archivo
        RETURN;
    END

    // Escribir la estructura completa de puntuaciones
    data_size = sizeof(top_scores);
    fwrite(OFFSET top_scores, data_size, file_handle);

    // Cerrar el archivo
    fclose(file_handle);
END

//------------------------------------------------------------------------------
// FUNCION: actualizar_top_scores
// DESCRIPCION: Actualiza el ranking de puntuaciones con una nueva puntuacion
//              Inserta la puntuacion en la posicion correcta si esta entre las 10 mejores
// PARAMETROS:
//   nueva_puntuacion - La puntuacion a comparar con el top 10
//------------------------------------------------------------------------------
FUNCTION actualizar_top_scores(INT nueva_puntuacion);
PRIVATE
    INT i;
    INT j;
    INT posicion_insercion;
BEGIN
    posicion_insercion = -1;

    // Buscar la posicion donde insertar la nueva puntuacion
    FROM i = 0 TO 9;
        IF (nueva_puntuacion > top_scores[i].score)
            posicion_insercion = i;
            BREAK;
        END
    END

    // Si la puntuacion esta en el top 10, insertarla
    IF (posicion_insercion != -1)
        // Desplazar las puntuaciones inferiores hacia abajo (de abajo hacia arriba)
        FOR (j=9; j>posicion_insercion; j--)
            top_scores[j].score = top_scores[j-1].score;
        END

        // Insertar la nueva puntuacion
        top_scores[posicion_insercion].score = nueva_puntuacion;
    END
END

//------------------------------------------------------------------------------
// FUNCION: mostrar_top_scores
// DESCRIPCION: Muestra las 10 mejores puntuaciones en la parte superior izquierda
//              de la pantalla del menu principal
//------------------------------------------------------------------------------
FUNCTION mostrar_top_scores();
PRIVATE
    INT i;
    INT pos_y;
    STRUCT ranking_lines[10]
        STRING line;
    END
BEGIN
    // Titulo del ranking
    write(0, ANCHO_PANTALLA - 10, 10, 5, "RANKING:");  // 5 = alineacion izquierda

    // Preparar las 10 lineas del ranking
    FOR (i=0; i<10; i++)
        ranking_lines[i].line = itoa(i + 1) + ". " + itoa(top_scores[i].score);
    END

    // Mostrar cada puntuacion
    FOR (i=0; i<10; i++)
        pos_y = 20 + (i * 10);  // Espaciado de 10 pixels entre lineas
        write(0, ANCHO_PANTALLA - 10, pos_y, 5, ranking_lines[i].line);  // 5 = alineacion izquierda
    END
END

Sobre la música, se tratan de canciones generadas con SUNO (una plataforma de música generada por IA) que he convertido a wav. En mi caso tengo un mac y esto me permite hacerlo con un simple comando:

afconvert -f WAVE -d UI8@11025 -c 2 CANCION.MP3 CANCION.WAV

Este comando lo que hace es generar un wav en sonido estéreo a 11025Hz. Es una calidad bastante mala para los estándares actuales, pero me permite tener canciones de menos de 3 MB (el formato wav abulta mucho y las máquinas con MS-DOS no pueden permitirse malgastar RAM).

Y para finalizar, aquí os dejo el gameplay completo del juego:

Prometo que intentaré que el próximo capítulo sea de un juego más fácil y menos complicado de programar.

¿Aprendiendo a programar para MS-DOS con DIV2 Games Studio? ¡Hagámos un JRPG! (capítulo 2)

2026-01-13T23:11:00.009+01:00

¡Hola a todos los entusiastas de la programación retro! Hoy vamos a sumergirnos de nuevo en el fascinante mundo de DIV Games Studio, un motor de juegos para MS-DOS de 1998 que nos permite crear videojuegos de la época con relativa facilidad. En esta entrada, crearemos un JRPG simple que demuestra conceptos fundamentales como el manejo de procesos, gráficos primitivos, tiles, NPCs y diálogos. El objetivo es enseñar los principios básicos de programación en DIV, ideal para principiantes que quieran dar sus primeros pasos en desarrollo de juegos. Aunque bueno, a lo largo de esta entrada veremos conceptos bastante avanzados.

¿Qué es DIV Games Studio?

DIV Games Studio es un entorno de desarrollo gratuito para crear juegos en MS-DOS. Utiliza un lenguaje similar al PASCAL, con énfasis en procesos (como hilos ligeros) para manejar lógica de juego, gráficos y audio. Es perfecto para prototipos rápidos y aprendizaje, ya que no requiere compiladores complejos. Si te pica el gusanillo, recuerda que este es el segundo capítulo que dedico a este lenguaje de programación. El primero lo tienes en el siguiente enlace: https://www.elgeneralfailure.com/2025/06/aprendiendo-programar-para-ms-dos-con.html

Estructura General del Código

El primer ejemplo que veremos es el JRPG_01.PRG (disponible en mi github: https://github.com/LeHamsterRuso/DIV2Examples/blob/main/PRG/JRPG_01.PRG). Si analizamos el código, veremos que este programa crea un mundo tileado (dividido en casillas) donde el jugador controla un personaje circular, interactúa con NPCs y navega por terrenos variados. Vamos a desglosarlo sección por sección.

¿Por qué un juego donde la única salida por pantalla son primitivas gráficas y texto? Pues para recordaros un poco los tiempos de las priemras Atari, donde rara vez los juegos venían con sprites.

1. Configuración inicial y estructuras globales

Al inicio, definimos constantes y estructuras globales:

Constantes y Variables Globales: MAX_NPC limita los NPCs. Variables como offset_x y offset_y manejan el desplazamiento de la cámara.
Structs: Son como clases simples, pero sin lógica. Puedes verlo como la definición de una clase, pero sin implementación lógica (no tienen métodos, ni constructor):

Controls asigna teclas que utilizaremos en el juego;
Map almacena los tiles (celdas) del mapa; Se trata de una matriz que representa un tablero.
DialogState gestiona el estado de diálogos;
NPCData guarda info de NPCs (posicionamiento en los ejes x e y, sus diálogos, étc.);
Colors define paletas (bosques, ciudades, pasto, agua, montañas...);
ZLevels controla capas de dibujo;
ScreenConfig configura resolución y FPS.

Inicio del Programa: set_mode() establece la resolución (320x240), set_fps() fija 30 FPS. Luego inicializamos controles, mapa y NPCs, y lanzamos procesos.

Las variables globales permiten comunicación entre procesos, mientras que el uso de structs es para organizar la capa de datos. Puedes ver los structs como clases de objetos, pero sin implementación (no poseen métodos ni constructores).

2. Inicialización de datos

Tres procesos inicializan datos:

InitNPCData(): Rellena NPCData con nombres, diálogos, posiciones y colores.
InitMap(): Crea un mapa tileado (32x24 tiles de 32x32 píxeles). Asigna colores basados en posiciones: campos verdes, montañas marrones, ríos azules, etc. Incluye caminos y ciudades.
InitControls(): Asigna constantes de teclado (_LEFT, _RIGHT, etc.).

Como ya habréis intuído, DIV no es un lenguaje orientado a objetos, por lo que las estructuras que definimos no tienen un constructor, ni métodos. Esto hace que tengamos que crear procesos de inicialización, para que estos actúen como constructores de clase para dichas estructuras.

En cuanto al uso de bucles FROM para rellenar los distintos arrays de las estructuras, ten en cuenta que, a diferencia de los bucles como FOR o WHILE, los bucles FROM no son condicionales y el valor final a alcanzar debe de ser una constante. Puedes emplear en un FROM una operación con una constante (por ejemplo "MAX_NPC - 1"), pero no una variable dinámica que cambie de valor en tiempo de ejecución. De ser el caso, el compilador te remontará un error.

Respecto al tamaño del mapa, ¿por qué celdas de 32x32 píxeles? ¿Por qué no de 16x16 o de 8x8? Pues se trata de una decisión de diseño debido a que DIV cuenta con una limitación y es que nos deja sólo manejar al mismo tiempo un total de 256 primitivas gráficas (1 byte). Y, aunque tengamos 768 tiles (32x24), gracias al algoritmo implementando (si un tale está fuera de la pantalla, no lo dibujo), a las dimensiones de las tiles (32x32) y al tamaño de la resolución de pantalla (320x240), no nos encontraremos con esa limitación de sobrepasar las 256 primitivas simultáneas en pantalla.

Por cierto, el uso de primitivas gráficas está muy mal optimizado en DIV y DIV2, debido a que las rutinas empleadas son las suyas propias y tienen un costo alto (parece que dibujan las geometrías pixel a pixel, lo que tiene un costo muy elevado en comparación con cargar un sprite y hacer uso de él), especialmente si se usan transparencias. En consecuencia este ejemplo debería de ir terriblemente lento en hardware real de la época, pero si tenéis un DoxBox configurado con cycles = MAX, el juego debería de iros a 30 frames por segundo (velocidad máxima que he definido con el set_fps).

3. Proceso de dibujo del mapa: map_drawer()

Este proceso renderiza el mapa visible:

Bucle Principal: En cada frame, borra dibujos antiguos con delete_draw() y cuenta y almacena IDs en draw_ids[].
Cálculo de Visibilidad: Determina qué tiles (celdas) mostrar basándose en offset_x/y, simulando un escenario con scroll.
Dibujo: Usa draw(3, color, 15, 0, x1, y1, x2, y2) para rectángulos rellenos y hacemos uso de draw_z con la estructura ZLevels para establecer la capa de profundidad.

Claramente este bucle está poco optimizado, puesto que hacemos limpieza y redibujado de la pantalla en cada frame. Para distinguir los distintos niveles de profundidad (mapa, npc o jugador), utilizamos la variable global de draw_z. No obstante, el manejo de draw_z es bastante problemático en DIV. Realmente no existe un z-buffer para las funciones de primitivas en la que puedas indicar "esto va detrás", "esto va en primer plano", como sí que existe en los sprites. Draw_z es una variable global, que afecta a TODAS las primitivas gráficas a la vez y es importante que, si juegas con esta variable, su valor modificado esté muy cerca en código al draw que dibuja el objeto, puesto que, al no contar con mutex (semáforos), en caso de que el procesador priorice otro proceso, puedes encontrarte con cambios no deseados de profundidad (del estilo dibujar el mapa encima del jugador). Este problema se hace especialmente notorio en máquinas potenters, que procesan un mayor número de frames por segundo.

El principal problema que hay con draw_z es que, al ser una variable global del propio framework, en el momento que todos los procesos ejecutan el comando FRAME, encargado de dibujar todo un fotograma completo en pantalla, todas las primitivas que vayan a dibujarse por pantalla tendrán realmente la misma profundidad. Para bypasear este problema la única solución seria que hay es forzar una impresión puramente secuencial, forzando a dibujar primero por lógica el mapeado y después los personajes (cosa que no hago en este ejemplo), lo cual entra en conflicto con la idea de usar procesos independientes para cada cosa. Por suerte este problema no lo tenemos con los sprites o imágenes de fondo.

Si os fijáis, este tema del z-buffer con primitivas no es algo tan raro, en juegos de Atari, por ejemplo, era bastante común tener efectos de parpadeos de personajes si esto se implementaba mal (del estilo asegurarse a dibujar el personaje en un fotograma distinto al escenario), o incluso en la primera PlayStation el manejo de los juegos 3D daban problemas notorios de perspectiva, al no saberse interpretar correctamente qué texturas tenían que sobreponerse sobre otras.

4. Proceso del jugador: player()

Maneja movimiento, colisiones y interacciones:

Movimiento: Ajusta velocidad por terreno (bosques/montañas ralentizan) y evita agua con checks de colisión.
Cámara: offset_x/y centran la vista en el jugador.
Dibujo: Dibuja un círculo con draw(5, 15, 15, 0, ...).
Interacción: Calcula la distancia a NPCs; presiona ENTER para dialogar con el más cercano.

En player capturamos los controles y verificamos si la casilla de destino es una montaña o un bosque para relentizar la velocidad del jugador y de paso evitamos que se pueda cruzar por una casilla de agua. En lo que concierne a la rutina para calcular cual es el NPC más cercano, aunque DIV tiene funciones para calcular la distancia entre dos procesos (distancia = get_dist(<código identificador>) o distancia = fget_dist(x, y, id2.x, id2.y)), hago uso de una simple función algebraica basada en el Teorema de Pitágoras para obtenerla (distancia = sqrt((player_x - NPCData[i].x) * (player_x - NPCData[i].x) + (player_y - NPCData[i].y) * (player_y - NPCData[i].y)).

5. Proceso de NPCs: npc(id_char)

Renderiza los NPC como círculos:

Visibilidad: Solo dibuja si el NPC está en pantalla.
Dibujo: Similar al jugador, con draw_z = ZLevels.npc.

6. Sistema de diálogos: dialogue(name, text)

Abre una ventana de texto:

Animación: Construye una cadena de texto con el diálogo del NPC juntando letra a letra.
Input: ENTER para auto-completar el texto y/o cerrar el diálogo.
Dibujo: Uso de draw() para el fondo y write() para texto.

Ejemplo 2

Con todo esto ya tendríamos algo funcional: Un personaje que se pasea por un mapa y que habla con distintos NPC. Este código demuestra lo esencial de DIV: Procesos concurrentes, dibujo primitivo y manejo de estado. Pero a nivel jugable, poco podemos hacer y, para extenderlo y hacerlo más disfrutare, podríamos agregar un inventario y más mapas... Y ahí surge el segundo ejemplo que os traigo hoy, el "JRPG_02.PRG" (https://github.com/LeHamsterRuso/DIV2Examples/blob/main/PRG/JRPG_02.PRG).

En esta segundo ejemplo, nos en una versión optimizada que introduce mejoras significativas. Veremos cómo estas optimizaciones no solo mejoran el rendimiento y la jugabilidad, sino que también enseñan conceptos más avanzados de programación en DIV.

JRPG_01.PRG era funcional, pero tenía limitaciones: redibujaba el mapa entero cada frame (causando flickering), usaba procesos separados para NPCs (ineficiente, imaginad un mapa con 100 npc), y carecía de mapas múltiples o inventario. Esta nueva resuelve estos problemas con optimizaciones que reducen el overhead de CPU y añaden más funcionalidades. Vamos a desglosar las mejoras clave:

1. Dirty Rectangles Approach para redibujar el mapa sólo si es necesario

El Dirty Rectangles Approach (enfoque de rectángulos sucios) es una técnica de optimización en programación gráfica 2D diseñada para reducir la carga de procesamiento al evitar el redibujado innecesario de toda la pantalla, siguiendo a su vez la premisa del "lazy evaluation" (no hagas trabajo innecesario).

En la función de map_drawer, el problema con nuestro enfoque inicial era que el proceso redibujaba todo el mapa visible cada frame, incluso si la cámara no se movía. Esto consumía recursos innecesariamente. Para aplicar esta estrategia, hago uso de variables globales para rastrear cambios de estado y redibujamos el mapa sólo cuando cambian los valores de offset_x, offset_y o current_map:

2. Renderizado consolidado en un solo proceso

En el código inicial teníamos el renderizado de cada proceso por separado (map_drawer, npc y player), lo cual suele ser lo normal en los juegos que programamos con DIV, pero trae dos problemas principales en nuestro diseño: Al usar sólo primitivas gráficas en lugar de sprites, podemos sufrir de flickering y superposiciones mal gestionadas por estar todo en la misma coordenada del z-buffer; Además, trae problemas de escalabilidad, puesto que cuantos más NPC pongamos en el mapa, más llamadas ralentizaremos nuestro juego (imaginaros 100 procesos NPC compitiendo con el map_drawer o el proceso del player).

Con esta nueva versión todo el dibujo se consolida en map_drawer y eliminamos el proceso de NPC al ser redundante (ahora entendéis por qué usaba el teorema de Pitágoras para obtener el NPC más cercano al jugador).

3. Múltiples mapas y transiciones suaves

En esta nueva versión tenemos tres mapas: Un mamamundi de 32x24 tiles y dos ciudades de 8x8. Para gestionar esto transformamos el struct MapData en un array y creamos una variable global "current_map" que nos indica en qué mapa nos encontramos.

Por ahora las áreas de teletransporte (si entro en X voy al mapa Y) las defino por código hardcode y también filtro así qué NPC están en cada mapa, pero la idea es que en el código final (el del siguiente ejemplo) veáis un enfoque mejor estructurado (definiendo estas áreas y filtros directamente en las estructuras de datos). Otra cosa que me gusta señalar, es el uso de fade_on y fade_off para forzar fundidos de pantalla cuando cambiamos de mapa.

4. Sistema de inventario

En esta nueva versión disponemos de un inventario de hasta 10 objetos. Estos objetos básicamente son un array de 10 strings (cadenas de texto). El sistema tiene mucho margen de mejora y, por ejemplo, podemos crear un struct objeto y meterle un integer de cuantía, pero no quiero adelantar acontecimientos del próximo ejemplo.

Los strings en DIV son unidimensionales, por lo que no podemos crear un array de strings de forma implícita, ni siquiera forzando la definición de una matriz (array de arrays), pero podemos crear un array de una estructura que contenga únicamente un string para poder crear un falso array de strings:

La gestión de strings en div requieren una mención especial, puesto que cuando hacemos una definición del estilo "string cadena[256]" no estás creando un array de 256 strings, si no un string de 256 caracteres (la talla del string). Además, cabe mencionar que el operando "=" copia por referencia en los strings, es decir, la asignación "a = b" hace que las cadenas a y b apunten a la misma región de memoria:

string a = "123";

string b = "456";

a = b;

b[0] = "5"; // -> a y b valen ahora "556".

Esto suele ser un quebradero de cabeza para cualquiera que no esté acostumbrado a trabajar con punteros, por lo que si quieres copiar el contenido de un string sin que ambas variables apunten a la misma región de memoria, lo ideal es usar la función strcpy (uso -> strcpy(cadena_destino, cadena_origen).

Esto por suerte sólo pasa con las cadenas de texto, el reto de tipo de datos de DIV suelen copiarse por valor y no por referencia. Y bueno, por ahora la única forma de obtener objetos es aceptando el ofrecimiento de un NPC que se encuentra en el mapamundi, pero la idea es que al final podamos recogerlos del suelo, comprarlos o obtenerlos de cofres del tesoro. Además, si pulsamos la tecla "escape" veremos un inventario con la lista de objetos que tenemos acumulados.

6. Música de fondo

En este ejemplo no he añadido aún efectos de sonido, pero si os fijáis se hace uso de load_Song() y play_song() para ejecutar una de las canciones que vienen con la instalación de DIV2. La función de "load_song()" soporta formatos los MOD, S3M y XM. Estos formatos pertenecen a la familia de los archivos de módulos (Tracker music) y, a diferencia de un MP3 que es una grabación de audio digital, estos archivos funcionan como una partitura digital con sus propios instrumentos incluidos. Un archivo de módulo no contiene una onda de sonido continua (como un wav, un pcm, un mp3 o un ogg), si no que contiene "samples" de sonido (una nota de piano, un golpe de batería, etcétera) y un secuenciador (una lista de instrucciones que indica qué nota tocar, en qué momento, con qué efecto (volumen, vibración) y en qué canal). Estos ficheros ocupan muy poco espacio (KB o pocos megas) manteniendo una calidad de sonido alta, ya que el audio se genera en tiempo real.

7. Diálogos interactivos con recompensas

Otra de las adaptaciones de este ejemplo es la inclusión de dialogos básicos con elecciones de "Sí/No" que además permiten obsequiar con objetos. Para ello hago uso de flags de estados y extiendo las estructuras de diálogos y NPC.

Ejemplo 3

¿Y qué más podemos hacer para mejorar nuestro juego? Bueno, en la descripción del ejemplo anterior vimos varias posibles mejoras:

Definir los NPC que salen en cada mapa dentro de la estructura de mapas.
Definir los teletransportes (si estoy en la casilla X -> voy al mapa Y) dentro de la estructura de mapas.
Adaptar el sistema de inventario para permitir cuantías (en vez de ver el mismo ítem en varias líneas) y además obtener una descripción.

Y dicho y hecho, el ejemplo 3 que encontraréis en mi github (https://github.com/LeHamsterRuso/DIV2Examples/blob/main/PRG/JRPG_03.PRG) realiza justamente todas esas adaptaciones en el código:

Ejemplo 4

¿Y qué más podemos hacer para mejorar nuestro juego? Bueno, en vez de definir los mapas, los teletransportes y los NPC en hardcode dentro del código, podemos aprovechar que lo tenemos ya todo definido en una única estructura de datos (MapData) para guardar toda esa lógica en un fichero externo (imaginaros un futuro donde creamos un editor de niveles) y crear funciones en nuestro código para leer dicho fichero.

Con esto en mente he creado este cuarto ejemplo (https://github.com/LeHamsterRuso/DIV2Examples/blob/main/PRG/JRPG_04.PRG), que a nivel funcional es idéntico al tercer ejemplo, pero que carga los mapas y los ítems a través de ficheros ".dat" que genero con un programa que he creado únicamente para ese fin (https://github.com/LeHamsterRuso/DIV2Examples/blob/main/PRG/MAPGEN.PRG). ¿Por qué es necesario crear un programa para crear el fichero ".dat"? Bueno, podríamos crear nuestro propio tipo de fichero en texto plano, modificarlo con un editor de texto y adaptar el código de nuestro juego para interpretarlo, pero lo fácil es coger una estructura ya existente y grabarlo "tal cual" para recuperarlo. El problema es que cuando escribimos una estructura de memoria al disco, estamos volcando código en binario, imposible de manipular con editores de texto.

El hecho de guardar estructuras y objetos en formato binario dentro de un fichero no es algo raro y se hace a día de hoy (de hecho, así funciona la mayoría de los famosos ficheros "save" de los juegos comerciales). A este proceso se le conoce como serialización y desserialización de un objeto. La diferencia es que aquí, en vez de hacer un "save" de nuestra partida, lo hacemos sobre la configuración de los mapas, NPC y objetos.

Ejemplo 5

¿Y qué más podemos hacer para mejorar nuestro juego? Bueno, ¡podemos emplear sprites en vez de primitivas y añadirle animaciones a nuestro personaje.

Sobre la estrategia a subir manejando sprites, hay que tener en cuenta que DIV y DIV 2 trabajaban en modos VGA, que permiten mostrar en pantalla un máximo de 256 colores simultáneos, algo que en frameworks actuales de desarrollo de videojuegos se queda muy corto. Esto significa que, antes de empezar a crear un fichero FPG y añadirle a porrón todos los sprites que queramos, tenemos que pensar en cómo gestionaremos los colores de nuestra paleta.

Por ejemplo, podemos hacer que la mitad de los colores (128) sean para dibujar los escenarios, es decir, reservarlo para los tiles. Una forma de optimizar al máximo esa limitación de colores, sería crear un sistema de diferentes ficheros FPG por nivel, es decir, hacer uso de un fichero FPG de tiles por mapa (uno para el mapamundi y otros dos para cada ciudad), cada uno de ellos con sus propios 128 colores. No obstante, por comodidad, en este ejemplo utilizaré una única paleta de colores, pero simplemente que sepáis que es algo que podéis abordar para vuestros juegos.

Con los otros 128 colores restantes, debemos reservar uno (el de la posición 0) para el color transparente y podemos reservar otros 15 para las fuente del texto y los fondos (diálogos y menú). El resto de colores (112) los destinaríamos a 7 los personajes (1 jugador y 6 NPC), lo que nos daría un total de 16 colores por personaje. Para crear las tres paletas, podemos hacer uso de herramientas como GIMP, que nos permiten indexar un máximo de colores por imagen (Imagen> Modo> Indexado) y hacer uso de las distintas soluciones que ofrece el entorno DIV. En cuanto a los formatos, DIV y DIV2 tienen problemas para interpretar la versión actual de BMP, es incompatible con PNG y el formato JPG degrada calidad... Por lo que lo ideal es exportar los ficheros a PCX una vez ya hayas hecho en él todas las conversiones específicas (escalado e indexado).

Imagen original en HD (1920x1080)

Me gusta activar el dithering (difuminado): Mezcla patrones de píxeles para sombrear.

Imagen modificada a 114x64 y 16 colores.

También tenemos que pensar en cómo organizar los personajes: Quiero tener dos estados, uno quieto y otro andando. El único personaje que puede andar, ahora mismo, es nuestro personaje, pero estaría bien dejar preparada la lógica para permitir andar también a los NPC en el futuro. Además, cada estado se representa gráficamente en cuatro direcciones, dependiendo de dónde esté mirando nuestro personaje (norte/sur/oeste/este, aunque cuando programamos juegos preferimos arriba/abajo/izquierda/derecha). Además, podemos hacer que cada personaje tenga su propio fichero FPG y que los códigos id de cara estado/dirección sean los mismos para cada personaje. Esto nos permite tener un código más modular y mantenible.

Para mi solución, los personajes quietos tendrán gráficos estáticos, pero quiero que cuando anden tengan una animación de 6 sprites en bucle.

Con estas premisas, podemos organizar los id de los FPG de personajes de la siguiente manera:

1: Idle mirando arriba -> NPC y jugador.
2: Idle, mirando derecha -> NPC y jugador.
3: Idle, mirando abajo -> NPC y jugador.
4: Idle, mirando izquierda -> NPC y jugador.
5-10: Andar, mirando arriba -> Sólo jugador por ahora.
11-16: Andar, mirando derecha -> Sólo jugador por ahora.
17-22: Andar, mirando abajo -> Sólo jugador por ahora.
23-28: Andar, mirando izquierda -> Sólo jugador por ahora.

¿Por qué ese orden de arriba, derecha, abajo izquierda? Por nada en especial, por seguir simplemente el sentido horario. Otra cosa a tener en cuenta es que DIV puede espejar sprites, por lo que podemos realmente usar el mismo gráfico para mirar derecha/izquierda o andar derecha/izquierda (por eso he subrayado esas líneas). La decisión de espejar los gráficos o no, debería de depender únicamente del diseño de tus personajes. En mi caso prefiero tener gráficos separados de derecha/izquierda por si implemento personajes asimétricos (por ejemplo con una manga de cada color, o cojo o manco de una mano)... Si nuestro personaje es diestro y maneja una espada, difícilmente lo representaremos correctamente con gráficos espejados (dependiendo de dónde mire, sería diestro o zurdo).

Una vez aclarado esto, os presento el quinto ejemplo de hoy (https://github.com/LeHamsterRuso/DIV2Examples/blob/main/PRG/JRPG_05.PRG), el cual, para funcionar, requiere de diversos ficheros FPG donde almaceno todos los sprites que utilizaremos (https://github.com/LeHamsterRuso/DIV2Examples/tree/main/FPG/DIABLO) y ejecutar previamente una nueva versión del MAPGEN para generar los ficheros MapV2.dat e ItemsV2.dat (https://github.com/LeHamsterRuso/DIV2Examples/blob/main/PRG/MAPGEN02.PRG).

Amaño de JRPG sobre Isekai Maou programado en MS-DOS con DIV2 Games Studio. Lo que veis es todo el gameplay, se trata de un tutorial que pienso publicar la semana que viene. pic.twitter.com/y3fzaoq0As
— Le Hamster ruso (@Hamster_ruso) January 12, 2026

El salto entre este ejemplo y el anterior no solo es visual, sino también estructural y técnico. Aquí detallo las diferencias más importantes:

1. Conversión completa a sprites y utilización de ficheros FPG:

- Los anteriores ejemplos utilizaban primitivas gráficas (draw()) para renderizar el mapa, los NPCs y el jugador.
- JRPG_05: Todo el renderizado se realiza con sprites FPG (put() y xput()), permitiendo gráficos mucho más ricos, animaciones fluidas y efectos visuales como sombras transparentes. Si os fijáis, esto no suele la programación típica de DIV Games Studio con sprites, donde por lo general hacemos procesos y cada uno tiene su propio gráfico con sus primitivas locales de x/y... Si no que utilizamos un sólo hilo para renderizarlo todo. Esto puede parecer que, en principio, aportamos una capa de complejidad a nuestro código, pero al hacer uso de estructuras donde definimos qué es qué (mapa, NPC, jugador...) realmente estamos optimizando mucho el rendimiento. Otra cosa a tener en cuenta es que, al abandonar draw en detrimento de put/xput, ya no nos hace falta almacenar id's en un array para borrarlos, puesto que el funcionamiento de estas primitivas no requiere de liberación de memoria.

- En las versiones anteriores los NPCs eran simples círculos de color, sin orientación ni animación.
- En este nuevo ejemplo cada NPC tiene un sprite para cada una de las 4 direcciones y el motor decide hacia dónde mira el NPC según la posición del jugador (priorizando la distancia horizontal o vertical según las distancias).

- En las versiones anteriores las cajas de diálogo y el inventario eran simples rectángulos dibujados con draw().
- En este nuevo ejemplo empleamos sprites dedicados para las cajas de diálogo, el fondo del inventario e incluso implementamos sombras transparentes en los pies del personaje y de los NPC, logrando una presentación mucho más atractiva.

2. Sistema de animación del jugador

- En las versiones anteriores el jugador era un círculo estático.
- Este nuevo ejemplo implementa un sistema de animación bastante completo basado en estados: Nuestro personaje podrá estar parado ("Idle") o andando. Ambos estados cuentan a su vez con otros cuatro subestados, dependiendo de dónde esté mirando el personaje (norte/sur/este/oeste). Por otro lado, cada una de las cuatro animaciones de andar consta a su vez de 6 cuadros (sprites) que se reparten de forma cíclica durante 30 frames (cada 5 frames, cambiamos el gráfico). El tema hacer avanzar la animación 1 vez cada 5 frames lo hago únicamente para que sea más agradable al ojo humano.

3. Arquitectura data-driven para los gráficos

- En las versiones anteriores los gráficos estaban “hardcodeados” y cualquier cambio requería recompilar el juego principal.
- En esta nueva versión los nombres de los archivos FPG se cargan dinámicamente desde los datos del mapa (MapsV2.dat), permitiendo cambiar gráficos o añadir nuevos sin tocar el código fuente del motor. Aún así ahora mismo tenemos que recompilar el MAPGEN, que es donde indicamos los ficheros correspondientes, pero el día de mañana podríamos implementar un editor para el juego que nos evite este proceso.

Ejemplo 6

¿Y qué más podemos hacer para mejorar nuestro juego? Bueno, por ahora, aunque hayamos mejorado mucho la arquitectura de nuestro juego, realmente sólo tenemos a un personaje que pasea y habla con personajes. Podemos ir un paso más y crear un sistema de quests. De hecho, el ejemplo de a continuación implementa un sistema de quests que se activa hablando con un NPC (https://github.com/LeHamsterRuso/DIV2Examples/blob/main/PRG/MAPGEN03.PRG y https://github.com/LeHamsterRuso/DIV2Examples/blob/main/PRG/JRPG_06.PRG).

En este ejemplo, defino un sistema de quests que tienen estado (NOT_STARTED, ACTIVE y COMPLETED) y para poder explotarlo he tenido también que adaptar el sistema de diálogos, permitiendo frases condicionales en función del estado de una quest (si ha empezado, si cumplimos las condiciones para acabarla, si no las cumplimos o si la quest ha acabado). A su vez, completar una quest lleva acciones y consecuencias, como restar ítems de tu inventario y recibir dinero. Por ahora, a nivel de estructuras, las quest están embebidas por NPC, pero es algo que podríamos externalizar en el futuro.

De paso he tenido que modificar la pantalla de menú (la que vemos al pulsar ESC) para que podamos seleccionar si ver ítems o las quests aceptadas (por que sí, no sólo podemos rechazar una quest, también podemos rechazarla).

Y para acabar con este ejemplo, también he aplicado un zoom en los diálogos (con transición) para que el juego luzca más juicy. Para ello recalculamos el tamaño y la posición de los tiles y personajes que hay en pantalla y los restablecemos sus dimensiones y coordenadas originales al finalizar el diálogo.

Ejemplo 7

¿Y qué más podemos hacer para mejorar nuestro juego? Bueno, todo buen JRPG de la época del MS-DOS tenía un sistema de galería de imágenes y eso es lo que he implementado en este séptimo ejemplo (https://github.com/LeHamsterRuso/DIV2Examples/blob/main/PRG/MAPGEN04.PRG, https://github.com/LeHamsterRuso/DIV2Examples/blob/main/PRG/JRPG_07.PRG y https://github.com/LeHamsterRuso/DIV2Examples/blob/main/FPG/DIABLO/CG.FPG). Como en los anteriores ejemplos, éste trae también su versión de MAPGEN que tendréis que lanzar antes de ejecutar el JRPG_07 y además trae un fichero CG.FPG que contiene 3 imágenes que iremos desbloqueando en el juego.

Básicamente algunos diálogos lanzarán una imagen, que a modo de evento, se verá en pantalla completa, como si se tratara de una visual novel y su implementación no es nada complicada. Básicamente en las estructuras de diálogo, además de un string para el texto añadimos un INT para indicar un ID de imagen que corresponderá a la imagen que hay que mostrar dentro del fichero CG.FPG: Y si el valor de ese ID es cero, no se mostrará ninguna imagen de fondo.

Además, la partida memorizará si hemos visto ya esa escena y la podremos visualizar a través del menú del juego, en una nueva sección dedicada a las CG.

Ejemplo 8

¿Y qué más podemos hacer para mejorar nuestro juego? Bueno, sólo nos quedan por hacer dos cosas para dar nuestro juego por acabado: Un sistema de combates por turnos y poder guardar y cargar la partida. Además de esto, el ejemplo también mejora la gestión del audio, permitiendo cambiar la canción del fondo dependiendo del mapa y cada mapa además tendrá su propia música también para los combates (si los tiene).

Para hacer funcionar este ejemplo os hará falta:

- Bajar y ejecutar el MAPGEN05.PRG (https://github.com/LeHamsterRuso/DIV2Examples/blob/main/PRG/MAPGEN05.PRG) para generar todos los ficheros ".dat" en formato binario.

- Descargar el MONSTERS.FPG (https://github.com/LeHamsterRuso/DIV2Examples/blob/main/FPG/DIABLO/MONSTERS.FPG).

- Descargar todos los FPG previos (https://github.com/LeHamsterRuso/DIV2Examples/tree/main/FPG/DIABLO).

- Descargar y compilar el JRPG_08.PRG (https://github.com/LeHamsterRuso/DIV2Examples/blob/main/PRG/JRPG_08.PRG).

La lógica de los combates es demasiado complicada como para entrar al detalle a nivel de código. De hecho, la rutina ("battle_screen") ocupa unas 800 líneas. Pero en fin, a modo de resumen, dicha rutina comienza inicializando el estado de batalla: selecciona aleatoriamente entre 1 y 3 enemigos (en este caso, slimes), asignando sus estadísticas de salud máxima y actual desde una base de datos de monstruos.Se muestra un mensaje inicial de aparición de enemigos y se cambia la música a la canción de batalla. En esta rutina se emplean conceptos básicos de programación como la inicialización de arrays y estructuras, el uso de números aleatorios con rand() y el manejo de recursos gráficos y de audio con funciones como put() y ChangeSong(). Además, se establece un temporizador para mostrar el mensaje inicial, ilustrando el control de tiempo en bucles con estimatedSeconds (función que estima los segundos en función de los fps de la structura ScreenConfig) y FRAME.

El núcleo de la rutina es un bucle principal que maneja los turnos alternos entre el jugador y los enemigos. Durante el turno del jugador, se presenta un menú con opciones como "Atacar", "Magia", "Defender" y "Huir", usando condicionales y manejo de entrada con KEY() para navegar y seleccionar. Si se elige atacar, se activa un modo de selección de objetivo, destacando el enemigo seleccionado con cambios visuales (tamaño y transparencia). Para la magia, se muestra una lista de hechizos disponibles, permitiendo elegir uno si hay suficiente MP. Los enemigos, por su parte, atacan aleatoriamente al jugador en su turno. En esta parte se hace uso de variables de estado (como player_turn, selecting_target), bucles anidados para dibujar elementos dinámicos y cálculos de daño basados en estadísticas. También incluye animaciones de muerte para enemigos (con transparencia y escalado vía xput), enseñando sobre temporizadores y flags booleanos para controlar secuencias complejas.

La rutina verifica continuamente las condiciones de victoria (todos los enemigos derrotados) o derrota (salud del jugador en cero), actualizando el estado del juego en consecuencia. En caso de victoria, se otorgan recompensas como oro e ítems, actualizando el inventario del jugador mediante búsquedas en arrays. Se muestra un mensaje de victoria con temporizador antes de restaurar la música normal y salir del combate. Si el jugador huye o muere, se maneja la derrota de manera similar. Finalmente, se limpian todos los textos y gráficos dibujados, restableciendo flags como in_battle para volver al mapa principal. Esta parte resalta la importancia de la gestión de estado global y el manejo de inventarios con operaciones de array (como agregar ítems).

En cuanto al sistema de guardado, veréis por el código que no hay mucho misterio, es aplicar el mismo mecanismo de escritura de los ficheros "dat" de los MAPGEN, pero llevado a un fichero "save".

Y así queda nuestro juego:

Ya parece hasta que sea un juego :-) #MSDOS #DIV2GAMESSTUDIO #ISEKAIMAOU. https://t.co/KM3HuDNa7V pic.twitter.com/HTRaQSQfMg
— Le Hamster ruso (@Hamster_ruso) January 13, 2026

Bonus: Uso de punteros en DIV

Esta noche he modificado el código del ejemplo JRPG_08.PRG, en el que he revisado la complejidad ciclomática de varios métodos complejos y de paso he retocado varias funciones haciendo uso de punteros. Y me gustaría mencionar esto porque en DIV Games Studio el uso de punteros no es muy evidente, en especial si venís del mundo de C.

Los punteros permiten manipular direcciones de memoria de manera eficiente, facilitando el acceso indirecto a variables y estructuras de datos.

En DIV, los punteros se gestionan principalmente con OFFSET para crear referencias a variables, permitiendo acceso indirecto sin copiar datos grandes, como se ve en llamadas como OFFSET(PlayerStats.hp) para pasar la dirección de la vida del jugador.
El operador * desreferencia estos punteros para leer o modificar el valor original, por ejemplo, *hp_offset += 10 en una función para incrementar la HP directamente, evitando retornos explícitos.
Los arrays se manejan con [] para indexar elementos fijos, como Enemies[i].alive para acceder al estado de un enemigo específico, mientras que operadores como ^ o & no aparecen en el código, ya que DIV no soporta punteros a arrays dinámicos ni referencias implícitas como en otros lenguajes.

Pasar variables entre funciones en DIV se basa en OFFSET para lograr paso por referencia, esencial para modificar structs o arrays sin duplicarlos, como en FUNCTION handle_player_action(INT selected_action_offset, ...), donde selected_action_offset permite cambiar la selección de acción dentro de la función. Para paso por valor, se pasan copias directas, como INT num_enemies, pero para structs complejos como PlayerStats, usar OFFSET evita sobrecarga; Un ejemplo es actualizar estadísticas con actualizar_hp(OFFSET(jugador.hp)), donde la función hace hp_offset += cantidad, reflejando cambios globales. Esta técnica, visible en funciones como handle_interactions(OFFSET(closest_npc)), optimiza el rendimiento y mantiene la modularidad, aunque requiere cuidado con la gestión de memoria para evitar errores de desreferencia.

El caso es que la gestión de punteros es rara de narices en DIV. Por ejemplo, podemos definir una variable "INT msg_timer = 0" e incluso crear un puntero que apunte a él "INT *msg_timer_offset = OFFSET msg_timer", pero no podemos crear un puntero, "tal cual", en la cabecera de una función. Tomemos por ejemplo la cabecera de la función handle_turns:

FUNCTION handle_turns(INT num_enemies, INT player_turn_offset, INT battle_active_offset, INT message_text_id_offset, INT msg_timer_offset, STRING battle_msg, INT input_timer_offset)

Si nos fijamos en esa función 5 de los 7 parámetros son punteros (los que acaban en "_offset"), pero en la cabecera de la función los definimos como de tipo entero (INT) y no de tipo puntero a entero (INT *). ¿Por qué? Pues sencillamente porque no compila. Y esto sorprende mucho, porque la gracia de los punteros, aparte de de para gestionar memoria dinámicamente, radica en poder hacer cambios en una variable desde distintos métodos. Y bueno, battle_msg, ¡tambien es un puntero!, puesto que cuenta como array de chars pese a no existir los CHAR en DIV.

De hecho, si os fijáis en el código, para esas variables estamos empleando el operador OFFSET en las llamadas a hundle_turns:

handle_turns(num_enemies, OFFSET(player_turn), OFFSET(battle_active), OFFSET(message_text_id), OFFSET(msg_timer), battle_msg, OFFSET(input_timer));

Entonces, ¿qué pasa aquí? ¿Por qué las llamadas usamos OFFSET para pasarle la dirección de memoria de las variables si en la cabecera NO esperamos un número entero? ¡Pues porque el funcionamiento de DIV es copiar por valor el número de referencia en un entero y luego acceder a su contenido con el operador "*". Y esto abre las puertas al polimorfismo, si toda referencia se pasa como un INT, luego podemos manipular su contenido como queramos.

Por cierto, aquí tenéis mi ejemplo favorito: (*msg_timer_offset)--;

Esta línea me tiene maravillado, porque es algo que funciona en C y que no me esperaba que funcionara en DIV: Esto, señoras y señores, decrementa el valor guardado en la dirección que tenemos entre paréntesis. Es simple, es hermoso y funciona.

[ENG] Act Man publica un vídeo sobre las malísimas ventas de Xbox en el último black friday

2026-01-04T11:45:00.001+01:00

[Blog] Datos curiosos y nada útiles de 2025

2026-01-04T11:44:00.005+01:00

Cumpliendo con el mismo tipo de entrada que hice en 2024, 2023 y en 2022, quisiera compartiros una serie de estadísticas nada útiles para hacer balance de este 2024:

Este año este blog ha recibido más de 389.000 visitas, 2.050 de ellas han llegado aquí usando ipods.

La palabra clave más usada este año en Google para llegar hasta aquí ha sido "firefox dinasty". Este año hemos tenido el honor además de recibir 243 personas referidas de algún sitio del MIT.EDU y 106 de GNU.ORG.
Según las cookies de las personas que han accedido al blog (y las han aceptado), el público medio son varones (74%), está en una franja de edad entre los 18-24 años (36,54%) y es de habla inglesa (47,52%).

Acceso por franja de edad:

18-24: 36,54%.
45-54: 21,79%.
25-34: 14,10%.
35-44: 10,26%.
55-64: 10,26%.
+64: 7,05%.

Acceso por franja de idioma:

Inglés: 47,52%.
Español (en todas sus variantes): 32,59%.
Chino: 16,07%.
Catalán: 0,75%.
Portugués: 0,53%.
Francés y Alemán: 0,44%.

En cuanto al contenido:

Con 1.090 vistas, la entrada escrita en 2025 que más visitas ha recibido ha sido "Firefox Dynasty: El genial port del Firefox actual para Macs obsoletos (Mac OS X 10.8 o superior)".
Con 1.970 visitas, la entrada más vista del año ha sido "Instalando Jelly Bean (CyanogenMod 10) en Folio 100". La escribí en 2012 y lleva acumuladas más de 27,4K vistas.
Desde que se creó el blog, la entrada con más visitas (41,5K), sigue siendo "Programando en Android: Tu propia calculadora con App Inventor".
La guía de juegos más consultada este año, con más de 1.270 visitas, ha sido la "Localización de objetos de misión de Sword Art Online: Alicization Lycoris". De hecho, este año ha recibido más del doble de lecturas que respecto al resto de mis guías.

En cuanto a los videojuegos:

El primer juego que he comprado este año ha sido el Breath of Fire III de PSP y el último el Dot Hack://G.U. Last Recode de PS4.
Entre regalos y adquisiciones, este año añadí 123 juegos a mi colección.
Este año me marqué como objetivo mejorar mi colección de PS3, pero al final sólo he comprado dos juegos para esta plataforma. Eso sí, son dos Ateliers: Ayesha y Meruru.
En este 2025 sólo un vendedor se negó en Vinted a venderme un juego que le compré y el motivo fue que seleccionaba un punto de recogida en vez de mi dirección real. Lo que me molestó del vendedor es que no comunicaba, se dedicaba a cancelar la venta y a publicar el anuncio una y otra vez, sin decir nada. Tuve que mandarle un par de privados para que me explicara que pasaba.
El Final Fantasy VII de PC (en caja grande) y la versión española del Oni de Mac siguen siendo mi Rosebud.

En cuanto a mangas y ánimes:

Este año me han encantado la segunda temporada de Solo Leveling, la segunda temporada de Dan Da Dan y la tercera de Re:Zero y de Firefoce. Si tuviera que quedarme con una, creo que elegiría Re:Zero como mi preferida.

La gran decepción del año ha sido, para mí, Ubel Blatt. El anime presenta un altísimo nivel de censura en comparación con el manga, además el desarrollo de los personajes y la narración de los eventos y de los sucesos no está a la altura. En pocas palabras, pese a ser palomitera, su anime ha salido rana.

En cuanto a los animes que no han sido novedad pero que me ha encantado ver este año y que recomiendo encarnizadamente: JoJo's Bizarre Adventure. Es probablemente el mejor anime que he visto nunca.

En cuanto a mangas, mis preferidos en 2025 siguen siendo Backstabbed in a Backwater Dungeon (qué pena que en España no haya llegado ni el anime ni el manga), In/Spectre (Stranger Case en Francia), Diario de Guerra: Saga of Tanya The Evil (Yōjo Senki) y Gate,(Gēto jieitai kanochi nite, kaku tatakaeri). Me sorprende que en España las editoriales se quejen de que el mercado está sobreexplotado, cuando la mayoría de mis series preferidas no salen aquí y tengo que comprarlas de importación en Francia o Reino Unido.

En cuanto a novedades de 2025, la única que me ha llamado la atención y que considero que merece destacar es "Blade & Bastard", de Ediciones Babylon.

Por cierto, la gran decepción en cuanto en manga para mí ha sido la calidad de impresión de la mayoría de editoras españolas. Tenemos uno de los precios más altos de toda Europa (aquí rara vez valen menos de 9€ el tomo) y absolútamente todas han tenido problemas de moiré en bastantes tiradas (con tirón de orejas especial a Devir por su desastre con las primeras tiradas de Los Diarios de la Boticaria y a Ivrea por toda la publicación de Nagatoro).

Ivrea: - "Dame 9€".
Lector: - "Pero si toda la tirada está defectuosa".
Ivrea: - "Dámelos".

En cuanto modelado 3D:

El modelo que este año más he disfrutado haciendo es nueva versión de Tanya Degurechaff que hice imitando la presentación del tomo 11: https://sketchfab.com/3d-models/tanya-degurechaff-from-saga-of-tanya-the-evil-fb725e63784d4839928aa8ea6fe28e56

Mi revisión de Ankha de 2021, con más de 23,1K vistas, sigue siendo mi modelo con más éxito en sketchfab https://sketchfab.com/3d-models/ankha-zone-version-37819f223f26467e8b3247e83b507805.

Y para finalizar, Expedition 33 ganándolo todo ha sido el momentazo del año:

[Anime] La edición física de The Dawn of the Witch

2025-12-16T00:29:00.005+01:00

Hoy he recibido en mi domicilio la edición europea de "The Dawn of the Witch" (título original: "Mahōtsukai Reimeiki" 魔法使い黎明期, que se traduce literalmente como "El amanecer del mago").

Esta serie, estrenada en 2022 a través de plataformas de streaming como Crunchyroll, constituye una secuela de "El Mágico Libro de Zero". Cabe destacar que esta secuela se centra en un nuevo elenco de personajes, cinco años después de los acontecimientos de la serie original, situándose realmente entre un spinoff y una secuela en el sentido tradicional.

Esta edición física, lanzada en julio de 2023, se distribuyó exclusivamente en el Reino Unido, Francia y Alemania. Incluye doblajes en francés, inglés y alemán, así como la opción de disfrutarla en VOSE (versión original japonesa con subtítulos en los idiomas mencionados). Lamentablemente no se realizó ninguna distribución para Portugal, España o Italia, haciendo que esta sea la única versión que podamos conseguir para toda Europa.

En cuanto al empaquetado, lo primero que nos llama la atención es la sobrecubierta de cartón, escrita en varios idiomas, la cual envuelve al estuche de plástico típico de todos los bu-ray... todo a su vez envuelto en un precinto genérico, sin sello, así que si lo encontráis en una tienda de segunda mano, andaros con ojo (si os lo ofrecen como "nuevo" y "nunca abierto", difícilmente puede demostrarse que sea cierto). El precinto, a su vez, viene bastante ajustado, por lo que es tremendamente sencillo encontrarse con una unidad con las esquinas de la sobrecubierta de cartón dañadas. Este tipo de sobrecubiertas de cartón era característico de Funimation, empresa adquirida por Sony y posteriormente fusionada con Crunchyroll.

En cuanto al lomo, destaca la presencia de Loux Krystas. Sin embargo, si la presencia de una bruja loli de más de 300 años de edad no resulta de tu agrado, se puede girar la caja 180 grados y reemplazar a nuestra amada profesora por el emo de Saybil.

Tras retirar la sobrecubierta de cartón, nos encontramos con un estuche de plástico convencional. Cabe destacar que la portada presenta un diseño reversible, exhibiendo por un extremo una versión en francés e inglés, y por el otro, la misma portada, pero en alemán. Este tipo de detalles me encantan. Cabe destacar que el código de barras varía en la portada alemana: Siendo 3700091033433 para el Reino Unido y Francia, y 7630017531858 para Alemania. Observando la caja de cartón, se aprecia un recorte que permite visualizar el EAN, lo que sugiere que en Alemania se distribuye la misma versión del producto, pero con la portada de papel invertida (para mostrar el EAN alemán).

En cuanto a los discos, si bien no son los más bonitos del mercado, presentan un acabado visualmente atractivo. Cabe destacar que, además de la ingente presencia de círculos mágicos, los sellos de control de edad (el "15" y el "FSK ab 16") parecen estar superpuestos en distintas capas del disco, creando un efecto relieve que no había visto antes en otros blu-rays.

Es importante mencionar que los discos son de región A y B, lo que sugiere que Crunchyroll los utiliza "tal cual" también para el mercado estadounidense. De hecho, al buscar en varias webs con el código de barras de la distribución americana (704400107832) y con el de la versión australiana (704400702617), se observa que ambas versiones también incluyen los doblajes en inglés, francés y alemán. Por lo tanto, para esta serie, parece que puedes comprarla sin miedo en Estados Unidos, Europa o Australia, ya que a priori traen exactamente los mismos discos.

En cuanto al anime, The Dawn of the Witch narra la historia de Saybil, un estudiante de magia amnésico y sin talento, que es enviado a una peligrosa misión de tres años de entrenamiento en las hostiles tierras del sur. Este viaje, ordenado por la directora de la academia y realizado en compañía de una bruja misteriosa y otros inadaptados, lo sumerge en el corazón del conflicto latente entre la Iglesia y las brujas, quinientos años después de que terminara la guerra.

La trama se centra en el crecimiento personal de Saybil y sus compañeros mientras viajan por un mundo dividido por la intolerancia y los prejuicios. A medida que enfrentan desafíos mágicos y morales, la historia desvela gradualmente los secretos del pasado de Saybil y el verdadero propósito de su viaje, que busca la reconciliación y la comprensión en una era donde la paz es frágil.

Como ya ha mencionado anteriormente, nos encontramos ante una secuela de "El Mágico Libro de Zero". Sin embargo, no es estrictamente necesario haber visionado la serie original para disfrutar plenamente de esta nueva entrega. Si bien, en todo caso, se recomienda la visualización previa de la serie original, dado que varios personajes relevantes de la primera serie hacen acto de presencia en esta secuela. Pero esto no es imperativo, puesto que, pese a ser técnicamente una continuación, realmente ambas series se centran en protagonistas y épocas distintas.

Por cierto, si os pica el gusanillo, que sepáis que esta serie se encuentra actualmente disponible para su visualización en streaming a través de la plataforma Crunchyroll. Cabe destacar que "El Mágico Libro de Zero", en cambio, se encuentra disponible exclusivamente en Jonu Play, donde se ofrece con doblaje al castellano y que, a través de su tienda en línea, puedes comprarla en Blu-ray (enlace).

La edición física del Atelier Ryza Secret Trilogy DX de PS4

2025-12-14T22:03:00.007+01:00

Esta semana he recibido la "Premium Box" del Atelier Ryza Secret Trilogy DX para PlayStation 4, que incluye una versión revisada de los tres juegos de Atelier Ryza junto con todos sus contenidos descargables. Entre las mejoras se encuentran varios episodios adicionales que permiten jugar con Agatha, Romy, Empel y Lila en el primer título, Empel y Lila en la secuela, y Clifford, Serri y Kilo en el tercer juego. Asimismo, se han incorporado nuevos indicadores en pantalla, un modo de "Combate personalizado" que permite seleccionar combinaciones de monstruos y niveles para ajustar la dificultad, un sistema de síntesis renovado para una mayor visualización e intuición y nuevas monturas para facilitar la exploración en Ryza 2 y Ryza 3. Adicionalmente, la versión para PlayStation 5, disponible de forma gratuita mediante la instalación desde la versión de PlayStation 4 utilizando una cuenta japonesa como proxy, permite disfrutar de los tres títulos a una resolución de 4K y una velocidad de fotogramas de 60fps.

La razón principal por la cual adquirí esta versión, en lugar de la de PlayStation 5, fue para poder ejecutar la versión nativa de los discos en mi PlayStation 4 e instalar la actualización a PlayStation 5 en mi PlayStation 5. Cabe destacar que, al insertar un juego de PlayStation 4 "actualizable" en una PlayStation 5, el sistema operativo generalmente notifica al usuario y recomienda la instalación de la actualización. Sin embargo, éste no es el caso en las PlayStation 5 europeas, ya que únicamente se ofrece la instalación de la versión de PlayStation 4. Para instalar la actualización es necesario utilizar una cuenta japonesa, la cual se puede crear fácilmente en aproximadamente diez minutos (apenas nos pedirá que aceptemos una serie de eulas, un nuevo email sin registrar y un código de postal japonés valido, sin necesidad de cambiar el idioma de la consola al japonés). Una vez instalada la actualización, se puede volver a la cuenta habitual y jugar a la versión de PlayStation 5 sin ningún inconveniente.

Si esta edición te resulta interesante, te sugiero considerar los siguientes aspectos:

Los archivos de guardado de las versiones originales y de estas versiones DX son incompatibles, por lo que será necesario recomenzar los tres juegos desde cero.
El primer Atelier Ryza no contaba con ninguna actualización para PlayStation 5, pero esta versión sí la incluye. Rejugar al primer juego en su versión de PlayStation 5 es altamente recomendable, ya que la mejora visual es considerable. De hecho, hace unos años adquirí la versión de PlayStation 4 del primer Ryza a pesar de poseer la versión para Nintendo Switch con el fin de disfrutar de una experiencia gráfica superior. El salto visual de PlayStation 4 a PlayStation 5 de esta primera versión me resulta más evidente que el de Nintendo Switch a PlayStation 4.
Al igual que las versiones originales de los Atelier Ryza, estas versiones "revisadas" también incluyen los textos en inglés. No están traducidas al castellano y sólo uno, el Atelier Ryza 2, cuenta con la traducción al francés. En pocas palabras, toca disfrutarlos sí o sí en inglés.
A diferencia de las versiones de PlayStation 5 y Nintendo Switch (que cuentan con una versión taiwanesa con carátulas en inglés), el Atelier Ryza Secret Trilogy DX de PlayStation 4 en formato físico solo está disponible en Japón.

En cuanto al contenido físico, esta caja es de gran tamaño (31,5 cm de alto, 23,5 cm de ancho y 4,5 cm de profundidad) e incluye una spinecard que ocupa aproximadamente un tercio del área. En la fotografía de a continuación, se muestra junto a la versión taiwanesa de esta trilogía para Nintendo Switch y junto a un juego de PlayStation 4, y como se puede apreciar, la spinecard es casi tan grande como el juego de PlayStation 4.

El embalaje del producto se presenta con un precinto genérico que carece de cualquier sello de autenticidad, lo cual representa un riesgo potencial para las reventas por internet. Cabe destacar que mi unidad presentaba un ligero desperfecto en la parte inferior, aunque la caja puede abrirse con facilidad y es poco probable que se produzcan daños significativos por abrirlos mucho. Esto contrasta con la edición taiwanesa (en mi caso de la consola Switch), donde los juegos se encuentran embutidos, requiriendo una presión considerable para su extracción (tienes que meter los dedos dentro y sacarlos a la fuerza).

Al abrir el embalaje, se observa en primer lugar una franela de gran tamaño, promocionada como "póster de tela", acompañada de un código de descarga un ASRM de Ryza (miedo me da descargar eso), un libro ilustrado de pistas y un disco físico que contiene la banda sonora de los tres juegos. Todos los elementos se encuentran cuidadosamente empaquetados. Adicionalmente, la calidad de impresión de la franela es notablemente alta y dan ganas de usarla, por ejemplo, para cubrir el teclado del ordenador.

El empaquetado es de alta calidad y la cantidad de material proporcionado es considerable, lo que sin duda satisfará a los aficionados a la saga. Sin embargo, se observa una notable omisión en el diseño de las carátulas, que carecen de ilustraciones interiores, a diferencia de lo que ocurría con los Ryza 2 y 3 originales. Esta ausencia representa el único aspecto que impide que esta reedición alcance la perfección.

En cuanto a las portadas de estas versiones DX, si bien son visualmente atractivas, resulta notable que presenten una paleta cromática más desaturada (menos vibrante) en comparación con las versiones originales. En términos simples, se utilizan colores más "lavados" y menos cálidos.

El precio de este pack en Japón asciende a aproximadamente 18.200 yenes, equivalentes a día de hoy a unos 102 euros. A este importe se deben añadir unos 27 euros adicionales por concepto de transporte y aduanas. Por lo tanto, el coste total de adquisición y envío de esta versión a España es de aproximadamente 129 euros. Que conste que esto no lo comento por fardar, si no para que andéis con ojo con los especuladores que hay por internet.

Nombre japonés: ライザのアトリエ～秘密トリロジー～ DX プレミアムボックス.

Fecha de lanzamiento: 13/11/2025.

Código de barras: 4988615211119.

El manga "Diario de Guerra: Saga of Tanya The Evil" vuelve a España

2025-12-08T17:38:00.004+01:00

Hace varios meses, la división editorial de manga de Devir anunció su expansión en el mercado español, destacando la adquisición de la licencia de "Los Diarios de la Boticaria". Esta decisión ha suscitado críticas debido a deficiencias en los controles de calidad, tales como la presencia de patrones de moiré en las impresiones (enlace) y la omisión de un globo en el tomo 9 (enlace).

En el marco del Salón del Manga de Barcelona, Devir ha revelado la adquisición de nuevas licencias, entre las que se encuentra "Diario de Guerra: Saga of Tanya The Evil", anteriormente distribuida por la difunta ECC. Por ahora Devir ha confirmado la reanudación de la serie a partir del número 21, sin especificar si se procederá a la reimpresión de los tomos anteriores. Esta posibilidad sería especialmente relevante, dado que tomos como el 4 presentan una alta demanda y son imposibles de encontrar incluso de segunda mano.

Decompilan y portan Lylat Wars (Star Fox 64) a Sega Dreamcast

2025-12-06T11:28:00.001+01:00

El canal de Youtube "The Sega Guru" acaba de subir un video donde muestra un port plénamente funcional del Lylat Wars (conocido fuera de Europa como Star Fox 64) funcionando en una Sega Dreamcast. El port en cuestión ha sido elaborado por el usuario jnmartin84 de GitHub (enlace) y se trata de una versión modificada del proyecto "sf64", que a su vez es un proyecto que decompila la rom americana de Nintendo 64 (enlace).

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

2025-11-30T21:27:00.012+01:00

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

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

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

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

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

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

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

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

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

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

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

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

Decompilan y portan Super Mario 64 a PS1

2025-11-23T14:23:00.004+01:00

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

2025-11-18T19:00:00.026+01:00

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

2025-11-04T20:00:00.090+01:00

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

2025-11-02T13:54:00.008+01:00

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

2025-10-21T19:00:00.015+02:00

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

2025-10-09T18:32:00.006+02:00

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

2025-09-27T11:42:00.013+02:00

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.

¿Por qué esos lapsos tan enormes de 20/50 años o 40/100 años? Pues sencillamente porque cómo cuides tu disco influye mucho. No es lo mismo tener tus discos apilados en una tarrina que guardarlos en sus cajas, lejos de la luz y en ambientes secos.

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)

2025-09-25T23:46:00.016+02:00

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.

De hecho, me gusta la metáfora de las ruedas de la bici, puesto que si usas un cartucho éste también muere. Una de las causas de la fuga de electrones es la alteración por lectura (Read Disturbance), donde una lectura intensiva de celdas en un mismo bloque puede afectar las celdas adyacentes y causar errores temporales que se deben corregir con técnicas de ECC (el controlador de memoria flash para la realización de corrección de errores). De hecho, cuando los influencers hablan de "refresh" de un cartucho, realmente no es que haya una función en la consola que te refresque las células de electrones de la memoria, si no que símplemente se hace una llamada al ECC del chip del controlador del cartucho y éste actuará únicamente si detecta una corrupción: No es como una vacuna que previene la enfermedad (refrescar una célula para que no pierda su valor de 1 o 0), es más bien una operación que se realiza una vez el paciente ya está afectado (si no sabe leer el valor, intenta interpretar si había un 0 o un 1 y lo machaca).

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

2025-09-24T19:00:00.095+02:00

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

2025-09-10T18:25:00.006+02:00

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)

2025-08-28T22:47:00.001+02:00

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.

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

2025-08-19T00:34:00.012+02:00

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

[Blender] [Sketchfab] Tanya Degurechaff, Saga of Tanya The Evil (portada del tomo 11)

2025-08-17T22:14:00.002+02:00

Acabo de publicar un nuevo modelo en mi perfil de Sketchfab: Tanya Degurechaff (de "Diario de Guerra: Saga of Tanya The Evil"). La intención inicial de este modelo era emular la portada del volumen 11 de la obra de Chika Tojo, publicada originalmente en 2018. Y bueno, la realización de este modelo me ha permitido adquirir nuevos conocimientos en Blender, como la vinculación de nurbspaths a armatures, añadir un modificador de skin sobre segmentos para hacer los marcos o el “bakeo” de texturas. Espero que sea de vuestro agrado: https://skfb.ly/pAozS.

Este es el segundo modelo de Tanya que publico en Sketchfab. Sin embargo, hace tres años mis conocimientos en Blender eran más limitados y siempre he considerado que el modelo anterior tenía mucho margen de mejora. Del mismo modo, considero que este modelo actual también es susceptible de mejoras, pero en términos de calidad supera por mucho al anterior.

En este modelo, al basarme en la portada de uno de los mangas de Tanya, opté por emular también la maquetación empleada por la difunta ECC (distribuidora española del manga que quebró en 2024). Y la verdad es que esta rotulación aporta un valor añadido al resultado final, puesto que le da un toque mucho más llamativo.

Tanya Degurechaff, from Saga of Tanya the Evil by hamster_ruso on Sketchfab

A continuación, os comparto también una serie de capturas de pantalla que muestran el resultado final del modelo subido a Sketchfab.

[Blender] [Sketchfab] Gally, Battle Angel Alita (portada del tomo 5)

2025-07-29T23:41:00.002+02:00

Acabo de publicar un nuevo modelo en mi Sketchfab: Gally (Alita), intentando imitar la portada del volumen 5 del maestro Yukito Kishiro que se publicó originalmente en 1993. Se trata de un modelo que empecé en 2023 y con el que me quedé atascado durante mucho tiempo. Dos años más tarde he decidido publicarlo "tal cual", sin acabar.

Gally, Battle Angel Alita (Volume 5 Cover) by hamster_ruso on Sketchfab

Captura del modelo final publicado en Sketchfab.

Capturas de la escena en Blender.

Captura de una de las primeras versiones que hice de Gally en 2023.