El general Failure, leo tu disco duro

[DIV2/Godot] Replicando el sistema de combates de Breath of Fire 2

2026-09-12T10:40:44.191+02:00

Últimamente he estado jugando al Brave Battle Saga de Mega Drive (Genesis en América), un juego cuyo sistema de combates me ha recordado mucho al Breath of Fire 2 de SNES. Así que me picó el gusanillo y me propuse programar un sistema de combates parecido y en esta entrada lo enfocaremos desde dos frameworks distintos: DIV2 (para programar juegos en MS-DOS) y Godot 4.7 para .NET (multiplataforma).

Ahora bien, para los incautos, que sepáis que en esta entrada hay muuucha IA (decisiones, generación de gráficos y audios) y no habrá código fuente explicado, porque el proyecto, pese a ser sólo un combate, ha acabado siendo enorme (en el caso de DIV2, el PRG ocupa más de 5.200 líneas). Lo que sí podéis hacer es leer los readmes de sendos proyectos que he subido en GitHub (https://github.com/LeHamsterRuso/BOF2LikeGodot y https://github.com/LeHamsterRuso/BOF2LikeDIV2), donde explico de forma global la arquitectura del proyecto y para qué sirve cada cosa.

En el caso de DIV2, al estar todo el código fuente en el mismo fichero, he escrito también un fichero ".md" de unas 500 líneas que detalla cómo funciona el código y está escrito en castellano exprésamente (https://github.com/LeHamsterRuso/BOF2LikeDIV2/blob/main/PRG/BOF2.md)... Por cierto, los assets de la versión de DIV2 son autogenerados con un script de parsing (es decir, un script que pilla los assets de Godot y los bakea a imagen/sonido, generando los ficheros FPG necesarios, más info https://github.com/LeHamsterRuso/BOF2LikeDIV2/tree/main/tools).

Lo primero es lo primero, enfocar un escenario para el "poc" (proof of concept) y para ello pregunté a varias inteligencias artificiales cual era, en Breath of Fire 2, el combate preferido o memorable según los jugadores y la crítica, para intentar replicar dicho combate. Y bueno, si lo que queréis ver es cómo ha quedado y no leer todo esto, pues os animo a ir directamente al final de esta entrada.

Valga decir que he jugado bastante al Breath of Fire 2, por lo que lo conozco bastante bien: Lo compré de lanzamiento, me hice todos los finales y lo he vuelto a jugar varias veces a lo largo de mi vida. Con esto dicho, a mi memoria vienen varios combates épicos:

En el prólogo tenemos dos reseñables: El primero contra Gonghead, donde Ryu niño intenta salvar a su hermana y acaba rescatado por Ganer; El combate en la cueva contra Barubary, donde nos aniquila de un golpe; El primero resulta interesante porque saltan eventos (Yua nos va curando y Ganer nos salva), pero desde el punto de vista práctico, no lanzamos magias y estamos solos, por lo que no podemos aprovechar todas las mecánicas del sistema de combates.

En el inicio de la aventura tenemos el combate contra Baba y contra Katt, pero tenemos el mismo problema, son combates donde Ryu se enfrenta solo a ellos, sin compañeros en la party. No obstante, el de Katt es muy interesante puesto que, además de producirse en un coliseo y esto siempre es épico, saltan eventos en los que Katt lanza frases aleatorias (algunas incluso son guiños a personajes de Clint Eastwood). También está el combate contra las tres arpías, que sería una buena opción (tenemos a Bow en la party y saltan eventos de diálogo).

Ya en la parte avanzada en la historia tenemos el combate contra Tiga, el "noviete" de Katt, pero también es a descartar puesto que es un 1 vs 1 y encima tiene vida infinita (el combate está programado para ser una derrota obligatoria por exigencias del guion); Y el combate contra Ganer, donde dependiendo del resultado la historia diverge, pudiendo obtener finales distintos.
Y por último, ya en la fase final tenemos la revancha con Barubary y el enfrentamiento final contra Deathevn, que son probablemente las dos batallas más épicas, puesto que tenemos que hacer alarde de todo nuestro potencial mágico. Además, en el de Barubary se nos da a elegir entre pelear solo contra él o con la party, en plan "chicos, dejádmelo a mí, esto es personal" y el mero hecho de que exista esa opción ya nos muestra el mimo con lo que cuidaban los JRPG en la época de los 16 bits.

Respecto a las IA, esta ha sido su respuesta:

Google: El combate contra Deathevan, el duelo individual contra Barubary, la pelea contra Ray y la pelea contra Augus. La pelea contra Ray es interesante, pero no la consideraría memorable... aunque es cierto de que se trata de uno de los pocos duelos de dragón vs dragón que existen en la saga de Breath of Fire; En cambio, la pelea contra Augus, el director del coliseo, me parece interesante, porque se produce al inicio del juego, es uno de los primeros jefes difíciles y en ella tenemos a Ryu y Rand en la party (y opcionalmente a Katt, según los eventos).
Grok: Sorpresivamente Grok me propuso los mismos combates más el de Kuwadora, pero priorizando el duelo contra Barubary antes que el de Deathevan. El combate contra Kuwadora es interesante por varios motivos: Transcurre en la mitad del juego, su combate se divide en fases, tiene vigor "infinito" (por lo que siempre ataca primero) y cuando lo programaron le dejaron varios bugs (nunca pasa a su "fase 3" por programar mal la gestión de números negativos en una rutina de ensamblador).

ChatGPT: Por su lado ChatGPT me sorprende para bien. A los típicos Barubary y Deathevan, le suma el Golden Fly (una mosca que tenemos que capturar a mitad del juego), el trío de las arpías y boses como Terapin, Trubo y Augus. La del Golden Fly no la vi venir. Terapin es una especie de hormiga reina gigante y azul, que, al más puro estilo reina alien, pobló el pozo de Captian de facehugger y creons. Por su lado Trubo era el Guardia Imperial del clan de los monos de Highfort (la ciudad natal de Sten).

Deepseek: En cuanto a Deepseak, a los ya típicos combates contra Barubary y Deathevan, propone también el combate contra Terapin.

Uff... cuantas opciones. Los combates contra Deathevan y Barubary son interesantes, pero me da miedo que tenga que implementar demasiadas cosas para un simple tutorial. Visto lo visto, creo que me quedaré con el combate contra Augus.

En ese combate deberíamos de estar entre los niveles 7 y 10, por lo que necesitaré verificar qué magias y stats tienen Ryu, Rand y Katt en esos niveles. Ahora bien, el primer problema que identifico es que stats en Breath of Fire 2 es que son semi-aleatorios.

Por un lado se definen una serie de franjas:

Ryu en el nivel 1 debe de tener: 30 HP, 10 MP, 20 STR, 16 STA, 16 AGI, 8 WIS y 12 LUCK.
Ryu en el nivel 25 debe de tener: 209 HP, 53 MP, 84 STR, 64 STA, 71 AGI, 77 WIS y 74 LUCK.
Esto nos da que en cada nivel debería de crecer +7,083 HP, +2,667 MP, +2 AGI, +2,291 AGI, +2,875 WIS y +2,583 LUCK.

Ahora bien, las consolas de 16 bits y los decimales no se llevan muy bien y queda muy raro decir que has subido +7,083 HP. Para facilitar los cálculos, se metía alguna variación aleatoria, del estilo subir entre 6 y 8 HP, por ejemplo... y el sistema del juego iba cuadrando las subidas de nivel para que al llegar a las franjas (niveles 25, 40, etc...) los valores convergieran de forma aproximada a los valores esperados.

Otra cosa graciosa de este sistema es que las magias también se desbloqueaban por nivel, algo bastante común en los JRPG de aquella época y que poco a poco hemos ido substituyendo en juegos modernos por sistemas de perks costumizables en árboles de habilidades.

Una cosa graciosa con estos dos sistemas de franjas y aprendizaje de magias daba como lugar que personajes como Katt podían aprender a usar Firebolt en el nivel 11... pero no tenía suficiente puntos de magia para usarla hasta el nivel 25 aproximadamente. Es decir, podías llegar hasta la segunda mitad del juego sin poder lanzar un magia que aprendió Katt justo al inicio.

Bueno, con todo esto dicho, ya tenemos definido el rango de nuestra demo:

El enemigo será Augus (https://bof.fandom.com/wiki/Augus_(Boss)).

Según las wikis, sus stats son: 680 HP, 16 AP, 43 OFF, 18 DEF, -1 MAGIC VULN, 12 AGI, 28 LUCK, puede atacar doble en el mismo turno, puede conjurar Cure 1 y dropea Herb (hierbas medicinales), 150 puntos de experiencia y 300 monedas.

Nuestra party será Ryu, Rand y Katt, todos de nivel 9.

Ryu debería de tener aprox: 90 HP, 24 MP, 41 STR, 32 STA, 34 AGI, 31 WIS, 33 LUCK y debería de poder conjurar TimeWarp, Cure 1 (Heal en GBA) y Cure 2 (Restore en GBA).
Rand debería de tener aprox: 130 HP, 40 MP, 48 STR, 42 STA, 17 AGI, 33 WIS, 24 LUCK y debería de poder conjugar Cure 1 (Heal en GBA) y CurePsn (Purify en GBA).
Y por último Katt debería de tener aprox: 87 HP, 9 MP, 53 STR, 25 STA, 55 AGI, 19 WIS, 41 LUCK y no debería de poder conjurar ninguna magia (aunque en la versión de GBA puede conjurar Slow).

Sobre las magias:

Cure 1 (Augus, Ryu y Rand), también conocida como Heal en la versión de GBA, sirve para curar vida: Consume 4 AP y reestablece 40 HP.
TimeWarp (Ryu) no consume puntos de magia, pero no se puede usar en combate (sirve únicamente para pasar de noche al día y del día a la noche) y sólo puede usarse en el mapapundi, que no implementaremos en esta demo.
Cure 2 (Ryu), también conocida como Restore en GBA, es una magia de curación más potente que Cure 1 / Heal: Consume 12 AP y reestablece 100 HP.
CurePsn (Rand) sirve para quitar los estados alterados (veneno, zombie, etc) y consume 8 AP.

Además de todo esto, los personajes tienen habilitades únicas y su efecto depende de distintos factores:

Ryu tiene la habilidad única Gust, que le permite recargar vida sin consumir puntos de AP. Su éxito depende de la cantidad de HP que tengamos en ese instante. Cuanto menos porcentaje de vida tengamos, será más probable ejecutar esta habilidad con éxito: Si fallamos, sólo "recargaremos" un punto de HP; Si tenemos éxito recuperaremos entre un 10% y un 50% de nuestros HP (cuanto menos vida tengamos, más alto será el porcentaje).
Rand tiene Wake, que permite resucitar un compañero muerto. Su porcentaje de éxito es del 50% aprox, pero intentarlo varias veces suele ser más barato que consumir un LifePL (que si la memoria no me falla tiene un precio de 500 monedas). Realmente su tasa de éxito depende del atributo Gust ("agallas").
Katt tiene Dare, que, en caso de éxito, permite provocar al enemigo para que éste centre sus ataques en ella. Tiene una tasa de éxito del 100%, pero funciona siempre a menos que te enfrentes a ciertos jefes finales de mazmorra o enemigos especiales que cuentan con inmunidad total a las provocaciones o alteraciones de comportamiento por fases. Augus, por ejemplo, es una de esas excepciones y la habilidad de Dare no le hace efecto.

Los contra-ataques:

Ryu y Katt son los dos únicos personajes jugables del juego que pueden realizar contra-ataques al ser atacado. Remarco lo de jugables, puesto que también pueden ejecutarlos determinados enemigos y, por suerte, Augus no es uno de esos.
Cabe destacar que sólo pueden activarse como respuesta a ataques de típico físico y no a magias. Su porcentaje de éxito (el que se produzca o no el evento de contra-ataque) depende de cada personaje:

La tasa de probabilidad de Ryu es de 1 entre 8, o lo que es lo mismo, del 12,50%. Es decir, cada 100 ataques físicos Ryu debería de haber realizado 12,50 contra-ataques aprox.
La tasa de probadilidad de Katt es de 1 entre 16, o lo que es lo mismo, del 6,25%. Esto se ve que se hizo aposta para que los jugadores no abusaran de "Dare".

Las agallas. Los puntos de "Guts" suelen ser los grandes desconocidos de este juego:

Cuando un personaje recibe un golpe mortal que debería dejarlo inconsciente (0 HP), el juego realiza una tirada oculta de probabilidad basada en su valor de Guts. Si la tirada tiene éxito, el personaje sobrevive al impacto y resucita instantáneamente con 1 HP, mostrando una animación especial de su sprite levantándose con furia.

La probabilidad máxima (7 llamas de guts) es del 25%. Cuantas más llamas de Guts tengas, más cercano estarás del 25% de éxito en esa tirada.

Por un lado los puntos de guts varían según el nivel del personaje y se representan con 7 llamas en la pantalla del estado del personaje. No obstante, al igual que los otros parámetros, realmente son valores que van del 0 al 255 (un byte) y su representación gráfica es una regla de 3. En el nivel 9 Ryu debería de tener unos 128 puntos de Guts (4 llamas), Rand 90 puntos (2 llamas) y Katt unos 75 puntos (2 llamas).

Es decir, si teines 75 puntos como es el caso de Katt, tu probabilidad de "resucitar" tras un golpe letal es del 7,35% (75/255*100*0,25) y si tienes 255 puntos tu probabilidad será del 25% (255/255*100*0,25).

Por otro, varían en función del combate:

Si un personaje muere en combate, su valor de Guts se reduce a 0 inmediatamente. Si el personaje resucita durante esa misma batalla, lo hará sin llamas de Guts.
Sufrir un daño masivo o un golpe crítico por parte de un enemigo puede disminuir temporalmente el valor de agallas del personaje afectado.
No existen condiciones que permitan ganar puntos de Guts (como hacer críticos al enemigo o realizar un contra-ataque).
Al terminar el combate, el valor temporal de Guts se restablece automáticamente a su valor base permanente.

Habilidades como Wake, de Rand, tienen una bonificación en función de los puntos de Guts que tenga en ese momento. La fórmula para obtener la probabilidad de éxito es: (128 + Guts de Rand)/256. Esto significa que será más fácil revivir personajes con Wake siempre que Rand no haya muerto antes durante el combate.

Otro punto "desconocido" para la mayoría de usuarios es la condición, que tiene cuatro valores: Poor, Normal, Good y Super.

En personajes como Ryu y Katt influyen, por ejemplo, en la tasa de activación de contra-ataques:

Poor -> 1 a 16 (valor por defecto de Katt)
Normal -> 1 a 8 (valor por defecto de Ryu)
Good -> 1 a 4 (25%)
Super -> 1 a 2 (50%)

Influye en la probabilidad de evasión, de críticos y de ser afectados por estados alterados.

Uf... vaya tela. Tremenda especificación acabamos de largar en esta parrafada. Pero aún no hemos acabado:

Los combates son por turnos, pero en cada turno el orden de acción de los personajes depende de sus puntos de agilidad. Es decir, en cada turno tendrás que seleccionar las acciones de toda tu party (Ryu ataca al enemigo A, Rand recarga vida, Katt usa Dare...) pero en cuanto definas la última acción de tu grupo es cuando empezará la ronda y, tanto el orden de ejecución de tus personajes como el de la CPU dependerá de los puntos de agilidad de cada uno. Si tuvieramos un personaje con agilidad máxima (255), un enemigo con agilidad 128 y un compañero de agilidad 20, el orden de ejecución será 255, 128 y 20 en todos los turnos. Esto difiere de juegos como Brave Battle Saga o Final Fantasy VII, donde hay una barra de tiempo y los personajes con una agilidad absurdamente alta pueden atacar varais veces más que un personaje de agilidad baja. Por ejemplo, en estos dos juegos que acabo de mencionar, un personaje de agilidad 255 seguramente habría atacado 12 veces más que el de agilidad 20.
Además de atacar, hacer uso de habilidades únicas y mágias, los combates tienen permiten consumir ítems (de ataque y de curación) y seleccionar auto (auto-atacar) y huir (que contra jefes tienen 0% de éxito). Pero también tienen otras opciones ocultas como "defenderse" o "cambiar estrategia" (que cambia el posicionamiento de los miembros del equipo) que son accesibles pulsando R y L respectivamente en el menú de selección durante el combate.

Defender reduce el daño en un 50% e incrementa la probabilidad de contra-ataque de Ryu y Katt, llegando a duplicarla e incluso tripicarla en función del contexto. Es decir, que si tienes a Ryu o a Katt en condición Super y los pones a defender, es muy probable que devuelvan con contra-ataques todo el dáño físico que reciben. Y si pones en vanguardia a Katt y ejecutas Dare, muy seguramente será siempre atacada por los enemigos.

Existen otros parámetros que hemos mencionado pero no descrito:

WIS (Inteligencia), afecta al daño que ejerces con lanzando conjuros/magias. Aunque diga que Cure 1 cura 40 puntos de vida, ese es el valor máximo que puedes curar en función del valor de WIS.
LUK (Suerte) es una stat "rota", no sirve para nada y el juego nunca la emplea. Debería de utilizarse en el sistema de chamanes, pero no es el caso por errores de código (tiene varios el juego) y no influye tampoco para el dropeo de ítems, ni en en la prevención de estados (como caer envenenado o ser dormido) y no se emplea tampoco para calcular críticos, ni para calcular si tienes éxito para huir. Para la mayoría de personajes de la party, sólo sirve para el daño de los ataques normales: Cuando se calcula el daño, hay varios rangos posibles (Low / Mid / High). Dentro de cada rango el juego elige entre varios multiplicadores, y cuanto más alto sea el Luck del atacante, más probabilidad tiene de salir el multiplicador más alto. En enemigos influye en la probabilidad de hacer un ataque "Slammed" (el crítico/especial de los enemigos). En Bow incluso pasa una cosa curiosa, se utiliza el luck del enemigo para alterar la precisión del habilidad de Shot / Snipe. Es decir, en vez de mirar la suerte de Bow, el juego mira la suerte del que va a recibir el disparo: A más suerte, menor será la precisión de Bow con su habilidad.
STA (Stamina) sirve para mitigar el daño físico en los combates.
DEF (Defensa) es la defensa TOTAL, contando stamina y los valores defensivos de tu equipamiento (armadura/casco/escudo).
De la misma forma, STR (fuerza) es el daño físico de tu personaje, pero OFF (ataque) es la suma de STR con el daño físico que ejerce tu arma.
Antes he dicho que el turno de quién ataca primero es de la agilidad: Mentí como un bellaco. Realmente este valor depende de VIGOR y se calcula con "Agilidad + Bonos de chamán - Peso total de equipamiento" y está restringido para tener valor mínimo 0 y máximo 511. En la práctica, VIGOR atrapa valores entre el 0 y el 511 y los personajes con más agilidad suelen ser los personajes con más vigor. En caso de empate (mismo punto de vigor), el orden se decide por la posición de la party del personaje (el personaje en posición 1 ataca antes que el de posición 2, el 2 antes que el 3 y el 3 antes que el 4). La fórmula varía para los enemigos: Agilidad + número al azar entre el 0 y el 7. En caso de empate de Vigor entre un personaje del jugador y un enemigos, siempre atacan antes los personajes de los jugadores.
VIGOR, OFF y DEF son los únicos stats que tienen valores entre 0 y 511. El resto de campos ocupan un sólo byte (de 0 a 255).
Los ítems de ataque y curación son realmente "magias", pero con otro nombre. Herb en el fondo es Cure 1, por ejemplo, pero de un sólo uso, sin quitar puntos de AP y sin ser afectados por WIS.
Existen 4 tipos de estrategia: Scramble (ataque), Normal, Defense y Parallel... y a pesar de sus nombres, los modificadores que aportan son bastante engañosos. Por ejemplo, "Normal" penaliza bastante a casi toda la party para que el líder sea la estrella y Parallel no aplica modificadores idénticos a todos los miembros del grupo de vanguardia o a todos los miembros del grupo de defensa:

Scramble añade un 20% de ataque en las posiciones 1 y 2, pero también reciben un 20% más de daño. La posición 4 recibe una penalización del 5% en ataque, pero también recibe un 10% menos de daño. La posición 3 no recibe modificadores.
La normal aplica un bonificador de 30% de ataque en la posición 1, pero recibe también un 30% más de daño. En la posición 2 recibe una penalización del 5% de ataque, pero recibe una bonificación del 10% en defensa. La posición 3 recibe una penalización del 10% de ataque, pero una bonificación del 15% de defensa. La posición 4 recibe una penalización del 25% de ataque, pero también una bonificación del 25% de defensa.
Defense aplica penalizaciones del 17% de ataque en las posiciones 2 y 3, pero a su vez las bonifica un 20% en defensa, mientras que en la posición 4 recibe una penalización del 25% de ataque y una bonificación del 25% en defensa. La posición 1 no recibe modificadores.
Por último, Parallel, aplica un bonificador del 20% en ataque y una penalización del 20% de defensa; la posición 2 no recibe modificadores; la posición 3 recibe una penalización del 10% de ataque y una bonificación del 15% de defensa y la posición 4 recibe una penalización del 17% de ataque y una bonificación del 20% de defensa.
Sea cual sea la táctica, la probabilidad de recibir un ataque debería ser:

Posición 1: 50%
Posición 2: 31%
Posición 3: 12%
Posición 4: 6%

Con estos números parece que Normal es peor que Scramble, pero nada más lejos de la realidad, si calculamos cálculos de ratio de modificadores ofensivos/defensivos, el que tiene mejor ratio sería Normal (1,026), Parallel (1,021), Defense (1,018) y por último Scramble (1,012). Pero claro, como todos los personajes tienen stats distintas, el ratio da absolutamente igual y lo que te importa es poder usar una estrategia que sea acorde a los puntos fuertes y débiles de tu parte. Por ejemplo, en una táctica donde manejamos a Ryu, Katt y Rand, conviene usar Scramble.

Flipando, ¿verdad? Es increíble la cantidad de detalles que no salen explicados en el manual de instrucciones. Tenemos ya las reglas definidas y ahora nos haría falta fabricar los assets:

Si nos fijamos en la escena, nos haría falta:

Modelar o dibujar el escenario de combate. En este caso es el despacho de Augus.
Dibujar una interfaz (las ventanas).

La ventana principal de combate donde vemos los miembros de nuestra party, sus puntos de vida, de magia, una barra de vida su nivel.
Una popup con la selección de comandos.
Una popup con los diálogos que salen durante el combate.

Modelar o dibujar a los personajes:

Augus.
Katt.
Ryu.
Rand.

Dibujar las partículas de las magias y habilidades:

Cure 1 y Cure 2.
CurePsn.
Gust.
Dare.
Wake.

Música del combate, música de victoria y efectos de sonido.

Ahora analicemos las reglas de gestión a implementar para un combate, que básicamente es enumerar todo lo que he explicado arriba, pero con reglas claras y concisas. Ahora bien, me ha salido un documento gigantesco de casi 3.000 líneas que tendréis disponible en mi GIT (https://github.com/LeHamsterRuso/BOF2LikeGodot/blob/main/Conception/Functional-Specification.md), pero digamos que estos son los puntos más importantes a destacar:

Las entidades

Tenemos dos, Personaje (jugable) y Enemigo, ambas bastante parecidas:

Character {

ID, Name, Level
HP, MaxHP
AP, MaxAP
Str, Stmna, Agi, bWis, bLuck, Guts // básicos
Off, Def, Vigor, Wis, Luck // derivados
Condition (0-255) → visual: Ill/Poor/OK/Good/Super
ElementalResistances[0..3]
Equipment
FormationPosition (1-4)
StatusEffects[]
Skills[]
CanCounter : bool

}

Enemy {

ID, Name
HP, MaxHP
AP, MaxAP
Off, Def, Agi, Wis, Luck
MagicSusceptibility (Ms) // -3 a +4
ElementType
StatusImmunities
Actions[]
AI
Rewards (Exp, Zenny, Items)

}

- Básicos: Str, Stmna, Agi, bWis, bLuck, Guts

- Derivados:

Off = [Str + poder de arma + bonos chamán + equipo] ×2 si Pwr.Up o Rotting (máx. 511)
Def = [Stmna + poder armadura/escudo/casco + bonos] ÷2 si Def.Dn / ×1.2 si Def.Up (máx. 511)
Vigor = [Agi + bonos chamán + equipo] (máx. 511) − peso de armadura ÷2 si Agi.Dn
Wis = [bWis + bonos chamán + equipo] ×2 si Wis.Up
Luck = [bLuck + bonos de equipo]

Flujo de combate:

Fase 0 – Inicio de ronda

Actualizar Condition de todos los miembros del party.
Procesar status de fin de ronda anterior (Rotting → Zombie, etc.).
Comprobar quién puede actuar.

Fase 1 – Selección de acciones del party

El jugador elige acción y objetivo para cada personaje que pueda actuar.
Se puede cambiar formación en cualquier turno con Swch (actualiza Risk Levels inmediatamente).

Fase 2 – Selección de acciones enemigas

Cada enemigo ejecuta su AI y guarda su acción + objetivo.

Fase 3 – Cálculo del orden de ejecución

Calcular Vigor de todos los combatientes vivos.

Si "humano": [Agi + bonos chamán + equipo] (máx. 511) − peso de armadura ÷2 si Agi.Dn.
Si "enemigo":

BOSS: Agi ÷2 si Agi.Dn.
Por defecto: (Agi + rand(0, 7)) ÷2 si Agi.Dn.

Ordenar de mayor a menor Vigor.
Aplicar reglas de empate: Party pos. 1 → 2 → 3 → 4 → Enemigos.

Fase 4 – Resolución de acciones (Turno A → Turno B)

FOR each Action in TurnOrder:

IF Actor no puede actuar (p. ej. acaba de morir) → CONTINUE
ValidateAction()
ExecuteAction()
ApplyDamage / Healing / Status
Mostrar números y animaciones
// Eventos inmediatos entre Turno A y Turno B
CheckDeath()
CheckCounterAttack() // solo ataques físicos enemigos
CheckWakeUpFromSleep()
CheckBattleEnd()
Actualizar objetivos de acciones pendientes

Fase 5 – Fin de ronda

Si el combate continúa → volver a Fase 0.

Acción de defenderse

// 1. El personaje renuncia a su acción en esta ronda
No realiza ningún ataque ni hechizo este turno.

// 2. Durante toda la ronda, el daño que reciba se reduce según el tipo:

Si el daño es físico (normal o especial físico):
Damage = Damage × uno de los siguientes valores (aleatorio):
{ 0.85 , <0.75 , 0.65 , <0.50 }

Si el daño es mágico o especial defendible:
Damage = Damage × uno de los siguientes valores (aleatorio):
{ 0.95 , 0.85 , 0.75 , 0.65 }
(Cuanto más alto sea el Wis del defensor, más probabilidad tiene de obtener el multiplicador más bajo)

// 3. Casos en los que Defense NO tiene efecto:
Si el ataque está marcado como “indefendible” (Undefendable):
Damage no se modifica.

Ataque físico de la party:

Pwr = Off_atacante - Def_objetivo
si Pwr < 0 → Pwr = 0

si Pwr < 63: Damage = LowRangeTable(Pwr, Luck)
si 63 ≤ Pwr < 99: Damage = Pwr × {0.85, 0.90, 0.97, 1.03} (Luck)
si Pwr ≥ 99: Damage = Pwr × {0.58, 0.64, 0.70, 0.76} (Luck)

si puede ser Special y éxito → Damage ×= 2

si objetivo usa Defense → Damage ×= DefendPhysical() // {0.85, <0.75, 0.65, <0.50}

Damage ×= attack_modifier(riesgo atacante)
Damage ×= defend_modifier(riesgo defensor)

Aplicar elementos
si Pwr.Dn → Damage ×= 7/8

Damage = MAX(1, MIN(999, floor(Damage)))

Ataque físico de los enemigos:

Pwr = Off_atacante - Def_objetivo

si Pwr < 0 → Pwr = 0

si Pwr < 63: Damage = LowRangeTable(Pwr, Luck)
si 63 ≤ Pwr < 99: Damage = Pwr × {0.85, 0.90, 0.97, 1.03} (Luck)
si Pwr ≥ 99: Damage = Pwr × {0.58, 0.64, 0.70, 0.76} (Luck)

// Ajuste exclusivo de enemigos
Damage = Damage + (Luck_enemigo × {1/8, 2/8, 3/8, 4/8}) + Random(0,1)

si puede ser Special y éxito → Damage ×= 2

si objetivo usa Defense → Damage ×= DefendPhysical() // {0.85, <0.75, 0.65, <0.50}

// Los enemigos siempre tienen Risk = 0, por lo que no aplican attack_modifier
Damage ×= defend_modifier(riesgo del defensor)

Aplicar resistencias elementales (si el ataque tiene elemento)

si el atacante tiene Pwr.Dn → Damage ×= 7/8

Damage = MAX(1, MIN(999, floor(Damage)))

Magia

// 1. Cálculo del daño base (igual para todos)
BaseDamage = SpellPower + Random(0..7)

// 2. Si el objetivo es un ENEMIGO:
Damage = BaseDamage × (1.0 + Ms × 0.04)

Donde Ms (Magic Susceptibility) del enemigo puede ser:
-3 → ×0.88
-2 → ×0.92
-1 → ×0.96
0 → ×1.00
+1 → ×1.04
+2 → ×1.08
+3 → ×1.12
+4 → ×1.16

// 3. Si el objetivo es un PERSONAJE del party:
Damage = BaseDamage
(No se aplica el modificador de Ms)

// 4. Well Cast (solo cuando el lanzador es del party)
Si el hechizo es de daño y se produce Well Cast:
Damage = Damage × 1.5

// 5. Aplicar elementos
Si el objetivo es enemigo → aplicar debilidades/resistencias del tipo del enemigo
Si el objetivo es del party → aplicar resistencias elementales del equipamiento

// 6. Defensa
Si el objetivo está usando Defense y el hechizo es defendible:
Damage = Damage × uno de {0.95, 0.85, 0.75, 0.65}

// 7. Límite final
Damage = MAX(1, MIN(999, floor(Damage)))

Estados alterados principales

Poison: No daña en combate, pero te coloreaba morado. Restaba 1 HP por paso en el mapa.
Sleep: El personaje no actúa. Se despierta con daño físico
Rotting: Tras 1 ronda completa → Zombie
Zombie: Puede atacar aliados. Al final del combate → Dead
Pwr.Up: Off ×2 (máx 511)
Pwr.Dn: Daño físico × 7/8
Def.Up: Def ×1.20 (máx 511)
Def.Dn: Def ÷2.
Agi.Dn: Vigor ÷2
Agi.Up: Estaba bugeado en SNES (no hacía nada), pero lo corrigieron en GBA. Aplica Vigor x2 (máx 511).
Hushed: Impide magia
Curse: Fuerza Condition a ILL

Los modelos 3D

Y con todos estos ingredientes me puse a trabajar en los gráficos. Ahora bien, no me calenté la cabeza, hice con Blender el escenario 3D y delegué en Meshy.AI la generación de los personajes (entrada NO patrocinada). Respecto al escenario, aunque lo modelé yo, también delegué en Meshy para su texturización.

Usar IA para generar modelos 3D tiene sus contras. Además del debate moral sobre saber de dónde han sacado los datos para entrenar los modelos, está el tema de la optimización. Como podréis observar cada personaje tiene unos 15.000 polígonos, lo cual sería inviable si hiceramos un JRPG de verdad (con sus aldeas y sus NPC paseando y comprando), pero en nuestro contexto es viable teniendo en cuenta que la escena sólo tendrá 4 personajes y un escenario simple. Otro punto importante es el RIG, como podréis observar en la demo, éste hace agua para cualquiera que sepa modelar en 3D.

Además está el tema de la comodidad: A mí me gusta modelar en 3D, es una de mis aficiones, pero cada modelo me puede llevar varias semanas. Hacer una demo con 4 personajes que apenas me dará visibilidad, que sólo la modelación me puede llevar meses y que encima no puedo comercializar, pues fue una de las motivaciones por las que me hico apostar por Meshy.AI (repito, entrada NO patrocinada).

Las meoldías

Para la música he tirado de Suno, utilizando prompts como:

- "classic SNES rock, 16-bit boss battle, fast shredding guitar riff intro, heavy palm-muted power chords, layered guitar harmonies, tight drums, groovy bassline, raw SNES sound chip, energetic and thrusting, short and repetitive, instrumental" para el tema principal;

- "16-bit SNES RPG victory fanfare, upbeat and cheerful, triumphant brass and synth melody, playful sound, short looping jingle, energetic and rewarding, retro SNES samples, light and joyful, instrumental, Treasures Won vibe" para la música de victoria;

- "16-bit SNES RPG game over theme, somber and melancholic, sad piano and soft strings, emotional and defeated atmosphere, slow tempo, retro sound, poignant melody, instrumental, Give Me a Chance vibe" para el Game Over.

La demo

Y con todos estos elementos, os presento cómo han quedado ambas versiones:

Jugadores perdidos, héroes falsos y muertos inquietos: Arqueología del lore en Overlord

2026-06-28T12:56:02.803+02:00

Overlord es una serie de anime, manga y novelas ligeras que ha capturado la atención de muchos, pero su verdadero tesoro radica en el vasto y complejo lore (información, historias, trasfondos y detalles que conforman el universo de una obra de ficción) que la acompaña. Aunque el anime ofrece una visión general, es en el manga, las novelas ligeras e incluso la novela web original donde se revelan detalles profundos y fascinantes que enriquecen el universo de Overlord: Desde las intrincadas historias de fondo hasta las relaciones sutiles, como la de Tuare y Ninya, hasta la existencia de varias oleadas de jugadores, el lore de Overlord es un universo en sí mismo, lleno de misterios y descubrimientos.

Inspirada por un short del canal Nazarick Archives (https://www.youtube.com/@NazarickArchives), o de las anécdotas triviales encontradas en sitios como overlord.fandom.com u overlordmaruyama.fandom.com, la siguiente entrada pretende satisfacer la curiosidad del aficionado a la saga, aquel que ha visto las cuatro temporadas del anime, la OVA y que considera conocer todos los secretos de Nazarick. Y es que, El trasfondo argumental de Overlord, es uno de los más intrigantes, cautivadores, ocultos y geniales que existen.

Portada de la novela 16 de Overlord (versión inglesa).

(Las llaman "ligeras", pero cada una tiene como 500 páginas).

Un guion elaborado y muy revisado.

Aunque parezca lógico, nunca está de más resaltar que todo el trasfondo de Overlord no ha sido escrito en un proceso inmediato, no nació así de la noche a la mañana. Kugane Maruyama, el autor original, es un gran aficionado a Dungeons & Dragons que comenzó a escribir Overlord en 2010 bajo el pseudónimo Muchimuchi Puririn en el popular sitio web japonés Shōsetsuka ni Narō (traducido como “Vamos a ser novelistas”, [enlace]). Allí, su obra llamó la atención de Enterbrain (la empresa detrás de RPG Maker), quien adquirió los derechos para publicar las conocidas novelas ligeras que acabaron saliendo a la venta en julio de 2012.

El autor se pasaba 5 horas al día en el club de literatura... jugando al rol.

Es importante mencionar que Enterbrain formaba parte de Kadokawa y que en 2013 se llevó a cabo una importante reestructuración corporativa para unificar todas sus editoriales bajo una sola entidad, denominada Kadokawa Corporation. La novela obtuvo un éxito moderado en su lanzamiento (aunque no excepcional), debido en gran medida a la sólida base de aficionados que ya poseía de la plataforma Shōsetsuka ni Narō. Sin embargo, gracias al boca a boca en cada nuevo volumen se experimentó un aumento en las ventas. No sólo las ventas no menguaban en cada nuevo volumen... ¡subían!

Ante el auge de la novela ligera, Kadokawa encargó al mangaka Satoshi Ōshio la adaptación al manga (publicada en 2014 en la revista Kadokawa Mensual Comp) y a Madhouse la creación del anime (estrenado en 2015). El anuncio del anime impulsó considerablemente las ventas de los libros y en 2022 ya alcanzaban las 14 millones de copias vendidas (menos que las 30 millones de Sword Art Online, pero más que las 13 millones de Re:Zero, [enlace]).

En conclusión, la obra de un autor influenciado por Dungeons & Dragons evolucionó desde una web novel aficionada hasta convertirse en una franquicia revisada y publicada por importantes empresas de la industria japonesa, como Enterbrain, Kadokawa y Madhouse, lo que permitió una mayor profundización y desarrollo de su trasfondo.

Para ilustrar este punto, os presento el proceso creativo de adaptación de la novela ligera al manga. Este extracto pertenece al tomo 4 de la versión española del manga (publicado por ECC en enero de 2018). Como podréis apreciar, el proceso no se limitaba a "tengo una novela, dibújala", si no que ya durante el story-boarding se le iba preguntando a Maruyama sobre detalles futuros del guion.

El guionista, Satoshi Ôshio, elabora la trama, la cual es posteriormente revisada por el autor de la novela, Kugane Maruyama. Tras seleccionar escenas de la novela original, se redacta el guion del manga. El autor de la novela lo revisa y corrige aquellos puntos que requieran matización.
El editor encargado y el dibujante, Hugin Miyama, se reúnen con el guion en mano: Una vez que se obtiene el guion con las correcciones del autor de la novela, se celebra una reunión. En ocasiones, el editor realiza un bosquejo para transmitir la imagen que tiene de la obra.
Hugin Miyama dibuja el boceto preliminar: El mangaka dibuja el boceto preliminar basándose en la imagen acordada con el editor en la reunión. El editor le indica qué aspectos debe corregir y, simultáneamente, selecciona la tipografía de los diálogos y las narraciones, que encarga al responsable de la rotulación.
Se pasa el boceto a limpio y se realiza el dibujo base: Una vez corregido el boceto, se realiza el dibujo base. Cabe destacar que la cuarta viñeta de la página derecha en esta imagen difiere ligeramente de la versión final. Esto se debe a que se realizan experimentos para lograr un resultado más eficaz e impresionante.
Se da el acabado final a la obra: El acabado final se consigue mediante el entintado del dibujo, la aplicación de tramas y el relleno de espacios. Las letras que se encargaron en el paso 3 se incorporan a la obra terminada para obtener el producto final que disfrutará el lector.

Maruyama: - “Bastan tres palabras para escribir "cien mil soldados",

pero en el anime y en el manga hay que mostrarlo con dibujos.”

Maruyama: - “No recuerdo haber creado un personaje femenino tan mono.

Me sorprendió lo guapa que es la Albedo del manga.”

Maruyama, durante el desarrollo del manga: - "Es complicado que (los estiletes de Clementine) puedan atravesar la armadura (de Momón), así que puede que lo mejor sea que vaya a por los ojos que quedan descubiertos con el casco." - Dicha decisión acabó sirviendo a su vez para el anime.

El anime y el manga tienen story-boards distintos,

pero al estar Maruyama involucrado en ambos, el desarrollo de uno sirve para el otro.

Cabe reseñar que el manga empezó a publicarse bastante antes que el anime. No obstante, el éxito de éste segundo ha propiciado que la trama avance más rápido en el anime, haciendo que el último tomo publicado del manga hasta la fecha, el 19, acabe con la conquista de E-Rantel, mientras que el anime ha continuado con la OVA de El Reino Sagrado.

Foto realizada de la portada de la edición sencilla de la OVA de Overlord (Selecta Visión, 2025).

Aún no hay fecha confirmada para la temporada 5 del anime, pero las aventuras de Ainz Ooal Gown continúan. Gracias a las novelas ligeras sabemos que aún quedan por descubrir varios arcos épicos y momentos clave, como los intensos combates contra las Escrituras Negras de la Teocracia de Slane, las delicadas negociaciones con el Reino Élfico, y el desarrollo de alianzas y conflictos que pondrán a prueba la astucia y poder de Nazarick. Además, nuevas amenazas emergen en el Nuevo Mundo que desafiarán la supremacía de Ainz y sus subordinados, ampliando aún más la complejidad y profundidad de esta saga.

Sin embargo, el objetivo de esta entrada no es anticipar el futuro de la obra, sino analizar lo que ya ha sucedido y que, en circunstancias habituales, no hemos logrado conectar.

Ninya (de las Espadas de la Oscuridad) se llama realmente Celicia y es la hermana menor de Tuare (la sirvienta humana rescatada por Sebas).

Ninya era una hechicera con el talento de aprender hechizos rápidamente. Formaba parte del grupo de Espadas de la Oscuridad (nombre creado como homenaje al Caballero Oscuro de los trece héroes, el cual portaba 4 espadas), un grupo de aventureros de E-Rantel (capital del reino de Re-Estize) que colaboraba con Momón y Nabe en el arco argumental “El Guerrero Oscuro” y que Ainz quería utilizar para impulsar la fama de Momón. Sin embargo, el grupo acaba siendo asesinado por Clementine. Cabe destacar que ninguno de los miembros del grupo conocía la verdadera identidad de Ninya y fue tras su muerte cuando se descubrió que se trataba de una mujer. Ocultó su género porque necesitaba dinero para buscar y rescatar a su hermana raptada y una de las normas de Espadas de la Oscuridad era que todos sus miembros debían ser varones.

La razón del nombre de "Espadas de la oscuridad" y el objetivo principal del grupo.

En el manga, a diferencia del anime, no se descubre el género de Ninya cuando ella muere.
Sin embargo, en los glosarios se utiliza el femenino al referirse a ella.

Un dato desconocido es que, en la novela web original, Ninya era hombre y que nunca fue asesinado por Clementine. Pero esto cambió con las novelas ligeras, que posteriormente sirvieron de base para el anime y el manga. Otro dato desconocido que se revela en el juego “Mass for the Dead” es que Ninya es su nombre falso, siendo su nombre real Celicia Veyron (capítulo 1, episodio 3).

Tuare: "Voy a intentar encontrar a mi hermana. Se rumorea que mi ciudad natal fue atacada (...).

Celicia. Se llama Celicia Veyron. Su apodo es Celi".

Gracias al tuitero リクシア (https://x.com/tillln/status/1315953334637920256/photo/3)

En el arco de “Los Hombres en el Reino”, Sebas Tian, el mayordomo principal de la Gran Tumba de Nazarick, salva la vida de una joven moribunda que había sido abandonada por el burdel donde trabajaba. Acto seguido la lleva a su mansión, donde Solution Epsilon la cura, sana sus heridas y, como compensación, Sebas propone que Tuaren se convierta en la criada de la casa.

Sin embargo, Solution sospecha de Sebas y alerta al ser supremo, Ainz Ooal Gown, de una posible traición. Ainz acude a la mansión para investigar, descubre a la sirvienta, pone a prueba la lealtad de Sebas y decide borrarle la memoria. No obstante, finalmente desiste al insistir Tuaren en querer recordar el nombre de su salvador. Durante este interrogatorio, se revela que su nombre completo es Tuareninya Veyron y Ainz se percata entonces que se trata de la hermana de Ninya.

Más tarde y siempre en el mismo arco, Tuare es secuestrada por los Six Arms y acto seguido es rescatada por Sebas, Lockmyer, Climb y Brain Unglaus. Posteriormente es trasladarla a la Gran Tumba de Nazarick, donde es acogida como sirvienta. Hasta la fecha desconoce que su hermana menor, Cecilia, ha muerto. No obstante, siempre que piensa en ella le vienen a la mente malos recuerdos.

Sebas Tian es un dragón y posee el aspecto real del ser supremo Touch Me.

Una de las características más destacables del mayordomo principal de Nazarick es su increíble fuerza. De hecho, en el arco argumental “Los Hombres en el Reino”, se evidencia rápidamente que posee una fuerza sobrehumana. Esto se debe a que, al igual que los demás NPC de Nazarick, no es humano, sino un dragontino.

Shalltear recordando a Sebas que un dragón no puede medirse a un vampiro genuino.

Parte de esta confusión acerca de si Sebas es humano o no proviene de que, a diferencia de la mayoría de los guardianes de piso o de las Pléyades, no desprecia a los humanos ni los considera inferiores. Más bien, cree en su naturaleza bondadosa y considera que es deber de los fuertes, como él, proteger a los débiles. Otro dato que se sabe gracias a las novelas ligeras (volumen 7, capítulo 2) es que su físico fue creado a imagen y semejanza de su creador, el ser supremo Touch Me.

Touch Me, por otro lado, fue el predecesor de Momonga (Ainz) como líder de la Gran Tumba, y era reconocido por su honestidad e integridad, valores que influyeron notablemente en la personalidad de Sebas. De hecho, la decisión de Momonga de proteger Villa Carne surge de la reflexión sobre qué acción tomaría Touch Me en su lugar, al observar a Sebas durante el ataque.

Hamesuke (el Rey Sabio del Bosque) es hembra.

Un dato que parece haberse perdido con la traducción de Overlord, tanto en la localización de Selecta Visión (ánime) como la de ECC (manga), es que Hamesuke, el Rey Sabio del Bosque, es hembra. Y por cierto, este personaje no existe en la novela web original.

Respecto a Hamesuke, se trata de un hamster ruso gigante de nivel 30, con atributos demasiado elevados si lo comparamos a los humanos, e infunde tanto terror que los monstruos no se acercaran a su territorio, lo que también produce que los aventureros pierdan interés en sus tierras (al no haber monstruos, no habían misiones de cacería ni posibilidad de farmear/levear). No obstante, esa paz se rompe cuando Ainz la recluta, dejando un vacío de poder que es reclamado por distintas facciones de monstruos que anelan sus tierras.

Por otro lado Ainz la lleva a la gran tumba para experimentar y decide entrenar a caballeros no-muertos con ella con el fin de descubrir si los monstruos del "nuevo mundo" pueden aprender habilidades (cosa que no pasa en YGGDRASIL). Recordemos que es un mounstruo de nivel 30 con habilidades de clase experto, por lo que le interesa que sus tropas puedan aprender de ella, a la vez que consigue que Hamesuke se haga más fuerte.

Arche Eeb Rile Furt fue alumna de Fluder Paradyne (el gran mago de la corte imperial del Imperio Baharuth) y sus hermanas acabaron siendo vendidas como esclavas.

Arche es recordada por muchos como la pobre joven hechicera que fallece injustamente a manos de Shalltear en la tercera temporada del anime. Pertenecía al grupo de aventureros Foresight, localizados en el Imperio Baharuth, y aunque tenía sangre noble, la revocación de los títulos nobiliarios por parte del emperador la obligó a dejar sus estudios y a trabajar para mantener a su familia. Sin embargo, a pesar de sus esfuerzos, sus padres siguieron insistiendo en mantener su anterior nivel de vida. Aún así, su principal objetivo era acumular la máxima cantidad de dinero posible para abandonar a sus padres y escapar con sus hermanas.

Un aspecto que no se aborda en el anime ni en el manga es que, antes de la revocación de los títulos nobiliarios, Arche era aprendiz de Fluder Paradyne, el mago más poderoso del Imperio Baharuth y además se especulaba con que ella podría llegar a alcanzar su nivel de poder. Vamos, que tenemos toda un prodigio convertida en un mero personaje secundario.

Como es sabido, en el arco argumental “Los Invasores de la Gran Tumba”, cuatro grupos de aventureros de clase mithril se adentran en la Gran Tumba de Nazarick con el objetivo de explorarla y expoliarla. Cabe destacar que dependiendo de la traducción, se hablará de grupos de aventureros o grupos de trabajadores. La diferenciara radica en que los aventureros rinden a un gremio y aceptan trabajos de éste, mientras que los trabajadores son "freelancers" y aceptan encargos bajo demanda. En este sentido, los aventureros que se adentran en la Gran Tumba no pertenecen a ningún gremio y trabajan como autónomos.

Desafortunadamente el grupo de Arche, los Foresight, se encuentra con el ser supremo, Ainz Ooal Gown. Como consecuencia, Arche muere a manos de Shalltear mientras intenta escapar de la Gran Tumba; Sus compañeros, Hekkeran e Imina, son enviados a la residencia de Gashokukochuuou, donde presumiblemente morirán para ser devorados por sus larvas; Y el único superviviente resulta ser el clérigo Roberdyck, a quien se le reescriben los recuerdos. Realmente Hekkeran e Imina no mueren, si no que son mantenidos vivos con magia de curación para farmear larvas. Sobre Roberdyck, se le mantiene vivo para experimentar sobre el origen de su magia (si se trata de fe o de habilidades adquiridas).

Hablando de Arche, un aspecto que no se explica con suficiente claridad en el anime es la recuperación de la voz de Entoma Vasilissa Zeta, la pléyade con aspecto insecto, la cual pierde su voz durante su combate contra Evileye en el arco “Los Hombres en el Reino”. Sin embargo, más tarde la recupera e incluso Albedo le llega a preguntar al señor Ainz si su nueva voz le resulta desagradable. ¿Qué nos hemos perdido? Bueno, tras la muerte de Arche, su cuerpo queda desmembrado: Entoma se queda con su voz, Demiurgo se queda con su piel y el Demonio Sombra de Seda se apropia de su cabeza. Este demonio guarda similitudes con el Demonio Circlet al que se enfrenta Baraja en el arco “El Reino Sagrado”, pero con la capacidad de poseer cuatro cabezas en lugar de dos. Realmente en el anime sí que se explica que se ha desmembrado el cadáver de una chica para aprovechar todas sus partes, pero no se menciona que se esté hablando de Arche, aunque en el doblaje japonés esto es obvio, debido a que utilizan su actor de voz para la escena.

En cuanto al destino de la familia de Arche tras su fallecimiento, el autor revela en su web que sus hermanas acaban siendo vendidas como esclavas y posteriormente fallecen debido a su explotación.

Cabe mencionar que en la novela web original (que a día de hoy no es canon), Arche no muere. Es más, se le concede la oportunidad de vivir, junto a sus hermanas, en el sexto piso de Nazarick. De hecho, según diversos seguidores de Overlord, el Ainz de la novela ligera (que sirve como base para el anime y el manga) habría estado dispuesto a perdonarle la vida de Arche, pero no lo hizo debido a la grave provocación de Hekkeran (quien intentó hacer creer a Ainz que habían sido invitados por otro ser supremo de la Gran Tumba). Vamos, que Arche acabó muerta por culpa de Hekkeran.

Clementine sigue viva y Quaiesse (5º Asiento de la Escritura Negra) es su hermano.

Como se ha mencionado anteriormente, Clementine elimina a todos los miembros del grupo Espadas de la Oscuridad en el arco argumental “El Guerrero Oscuro”. En este arco se revela que esta dirigente del grupo secreto Zurrernorn fue miembro de la Escritura Negra, la unidad de élite más poderosa de la Teocracia Slane (una teocracia que profesa la supremacía humana sobre otras razas y que se encuentra en conflicto con los Elfos).

En el episodio 10 de la primera temporada se presenta a Quaiesse en una escena que, debido a su gran parecido físico con Clementine, llevó a algunos a pensar brevemente que estábamos ante ella. De hecho, son físicamente tan similares que, según la novela web original, Clementine llegó a actuar como doble de su hermano.

Otro dato poco conocido es que Clementine sigue viva. Entiendo que esta afirmación puede causar debate, debido a qué implica que el juego "Escape from Nazarick" sea canon. Kugane Maruyama intervino en su historia y los sucesos concuerdan con la línea temporal del anime, por lo que para mí es canon.

Pero volvamos a las novelas ligeras/manga: Cuando Momón entrega los cuerpos de Clementine y Khajiit a las autoridades, estos desaparecen poco después del inicio del arco argumental “La Valquiria Sangrienta” (famoso por su memorable combate final entre Shalltear y Ainz). Esto generó temor en Ainz, ya que, en ese momento, ella era una de las dos únicas personas que sabían que Momón no es humano (la otra es el curandero Nfirea). Sin embargo, gracias al videojuego “Overlord: Escape From Nazarick” para Nintendo Switch y Steam, se revela que Clementine fue trasladada a Nazarick para evaluar las capacidades defensivas de La Gran Tumba (recordemos que Ainz tiene la capacidad de resucitar personajes). Una vez alcanzado el verdadero final del juego, se descubre que se encontraba en una falsa Nazarick creada por Mare y se le permite escapar (bajo la protección desde las sombras de Aura) para que esparza información falsa sobre los niveles de seguridad de La Gran Tumba.

Quisiera comentar que hay varios detalles en el anime que nos dan a entender que los eventos del juego son canon. Por un lado, al vencer a Clementine y Khajiit Dale Badantel, Momón y Nabe se ven obligados a entregar sus cuerpos a las autoridades para poder recoger la recompensa, pero también se menciona que estos desaparecen al poco tiempo. Además, al finalizar el combate entre Shalltear y Ainz en el episodio 13 de la primera temporada, éste acaba preguntando a Albedo qué tal van los preparativos de "la falsa Nazarick".

Foto extraída de mi colección de juegos (Selecta Play, 2024).

En relación con la decisión de liberar a Clementine a pesar del riesgo de que pueda revelar la verdadera naturaleza de Momón, es importante considerar que varios personajes de Nazarick, como Neuronist Painkill, Demiurgos o el propio Ainz, poseen la capacidad de modificar recuerdos. A esto se suma que Clementine despierta en el juego con amnesia, lo que sugiere que se ha experimentado previamente con ella. De hecho, en el juego, al recuperar todos sus recuerdos asocia a Ainz como un no muerto invocado por por Momón y no por ser la misma persona. Además, otra razón por la que presumiblemente Ainz la mantiene con vida es porque cada vez que se enfrenta a ella aprende cosas del “Nuevo mundo”.

Por cierto, me he pasado el juego con su final bueno sólo para hacer estas capturas.
Estuve buscando gameplays en Youtube, pero todo el mundo juega a la versión de Steam (con textos en inglés).
Por si no lo sabíais, la versión de Switch es la única con textos en castellano.

Cabe destacar que en el anime y el manga se aprecia un detalle que pasa desapercibido: la armadura de Clementine está decorada con las insignias de todos los héroes que ha matado. De hecho, así es como Ainz consigue localizarla en el arco del “Guerrero Oscuro”, utilizando un hechizo de localización de objeto sobre las chapas de sus compañeros de Espadas de la Oscuridad. Este tipo de detalles se aprecian mejor en el manga, donde las armaduras suelen dibujarse con mayor detalle que en el anime.

Fotos de mi colección de mangas (ECC 2017-2024).

También cabe destacar que, en la escena inicial de la serie, se observa al señor Ainz caminando sobre diversos tapices, entre los que se encuentra la Escritura Negra. En este último, se puede apreciar a Quaiesse en la esquina inferior izquierda, junto al señor Ainz.

Captura de pantalla realizada a partir del Blu-Ray original (Selecta Visión, 2023-2025).

Albedo odia a todos los seres supremos menos a Ainz.

Albedo alberga un profundo resentimiento hacia los demás seres supremos, a quienes acusa de abandonar a Nazarick y a Momonga (Ainz). En su opinión, Ainz fue el único que permaneció fiel a su deber y protegió a los NPCs, lo que, junto a su devoción "forzada" (recordemos que Momonga reescribió su ficha al inicio de la historia), ha ayudado a cimentar su lealtad absoluta hacia él. Tras los acontecimientos de “Los Invasores de la Gran Tumba”, Albedo aprovecha la estratagema de Hekkeran (que intentó engañar a Ainz insinuando que había sido invitado por otro ser supremo) para proponer la creación de una unidad especial encargada de la búsqueda del resto de seres supremos en el “Nuevo Mundo”. Ainz acepta la iniciativa, convencido de que el objetivo es reunificar el gremio de La Gran Tumba.

Sin embargo, Albedo considera que los otros seres supremos representan una amenaza potencial para Ainz, ya que podrían desviar la lealtad de los NPCs y poner en peligro su autoridad. Este grupo, liderado por ella misma, se mantiene en secreto ante los guardianes de los pisos, ya que no descarta la posibilidad de eliminar al resto de seres supremos. La unidad está compuesta por su hermana Rubedo (considerada la entidad más poderosa de Nazarick), dos NPCs de nivel 100 (ella misma y Pandora’s Actor) y quince no-muertos de nivel 80.

Eclair, el pingüino que quiere el trono de Nazarick, es de nivel 1.

En el primer episodio de la segunda temporada del anime se presenta a Eclair Ecleir Eicler, un pingüino dedicado a la limpieza del castillo que sueña con ocupar el lugar del ser supremo Ainz. Sin embargo, lo que los aficionados de Overlord desconocen es que se trata de un NPC de nivel 1. En otras palabras, es probable que sea el habitante más débil de toda la Gran Tumba de Nazarick. Esto se debe a que fue creado como una broma por la ser supremo Ankoro Mocchi Mochi.

Ankoro Mocchi Mochi también es la creadora de Pestonya Shortcake Wanko, la perra humanoide que ocupa el cargo de jefa de servicio de Nazarick bajo las órdenes de Sebas y que actualmente se encarga, junto a Nigredo (la hermana mayor de Albedo), de la dirección del orfanato del Reino Hechicero.

Nigredo y Pestonya fueron presas para evitar que los guardianes se "humanizaran".

Durante la aniquilación de Re-Estize, observamos a Nigredo y Pestonya confinadas en una prisión helada dentro de La Gran Tumba de Nazarick. Aiz menciona a Sebas que es comprensible que Nigredo desee hablar con él, dado que fue él quien ordenó su cautiverio. También se menciona que le habría gustado invitar a Albedo a la reunión, pero que no era conveniente debido a que no aceptó bien el castigo.

En cuanto al motivo del castigo de Nigredo y Pestonya, en el arco de “Los invasores de la Gran Tumba”, el señor Ainz ordenó la eliminación de todos los intrusos. Sin embargo, tanto Nigredo como Pestonya intentaron interceder por ellos, argumentando que no debían eliminar humanos innecesariamente, especialmente si eran útiles como muestra o para estudios. Esto se interpretó como insubordinación, ya que cuestionaban las decisiones de Ainz y el sistema jerárquico de Nazarick. Aunque aún no las consideró completamente traidoras, decidió confinarlas en una prisión dentro de Nazarick para evitar que sus valores “humanistas” influyeran negativamente en otros NPCs. Debido a esta decisión, le resulta difícil reconocer en el arco de “El Reino Sagradado” que él permite escapar a humanos a propósito y omite a los guardianes de piso la petición que le hicieron Nigredo y Pestonya.

Evileye es una vampiro, tiene más de 250 años, es princesa de Inveria y fue miembro de los Trece Héroes.

Keno Fasris Inberun, conocida como Evileye, es un personaje secundario recurrente en la trama de “Los Hombres en el Reino” (donde se enamora del aventurero Momón y se enfrenta a Entoma) y en “El Hechicero de la Destrucción” (donde se produce la aniquilación de E-Rantel). Actualmente, pertenece al grupo de aventureros Blue Roses. Sus principales rasgos son su apariencia juvenil (se convirtió en vampiro con apenas 12 años) y que, salvo en presencia de sus compañeras más cercanas, suele portar una máscara que cubre su rostro (para evitar la luz solar). Dicha máscara, conocida como la Máscara de Irubia Hordan, tiene una joya roja incrustada en la frente y una fina grieta alrededor de los ojos. Se describe como uno de los tesoros nacionales de Inveria (reino que existió 200 años antes de la trama de Overlord, situado en el sureste de Re-Estize). Aunque no se conocen habilidades específicas de dicha máscara, antes de romperse demostró ser capaz de resistir un ataque de Yuri Alpha.

Analizando su pasado, nos encontramos ante la princesa del reino de Inveria, quien posee la habilidad de replicar los dones de otros individuos. De hecho, su condición de vampiro se debe a un error colateral de la replicación de una habilidad de Cure Elim Los Malvar (también conocido como "Elder Coffin Dragon Lord"), el dragón más poderoso del “nuevo mundo”. Éste temible dragón lanzó un hechizo sobre su reino con la intención de convertir a sus habitantes en no-muertos. Sin embargo, todo salió mal y Keno terminó absorbiendo las almas de los cinco millones de habitantes de su reino.

Entrando más en detalle, el reino de Keno fue devastado por un hechizo de necromancia de gran escala que transformó a toda la población en zombis. Desesperada por evitar el destino de sus súbditos, Keno replicó el hechizo utilizando su talento innato (“Poder de copiar habilidades”) con la esperanza de evitar su zombicificación. Sin embargo, al no comprenderlo completamente, el efecto se distorsionó:

La versión original del hechizo transformaba a los vivos en zombis sin conciencia.
La versión que Keno replicó alteró su fisiología, convirtiéndola en vampiro y dándole las siguientes características:

Inmortalidad y regeneración propias de un vampiro.
Necesidad de consumir sangre.
Apariencia física conservada, no putrefacta como la de un zombi.
Poder mágico muy superior al que poseía como humana.

Aunque el talento de Keno le permite copiar técnicas o hechizos, el resultado no siempre es exacto: el "código" mágico copiado puede mutar, y en este caso lo hizo de forma radical. Como maga de alto nivel, su resistencia y afinidad mágica probablemente alteraron el efecto necromántico y, en lugar de perder su conciencia y pudrirse, su cuerpo se adaptó al estado de no-muerto conservando las funciones superiores.

Entrando en detalle, el hechizo utilizado por Cure Elim Los Malvar pertenece a la magia salvaje, un tipo de magia ancestral que aún no ha sido explorada en el manga ni en el anime. A diferencia de la magia arcana o la magia de YGGDRASIL, la magia salvaje no consume puntos mágicos de manera tradicional, sino que utiliza directamente energía vital o “vidas” (sacrificios) para generar efectos poderosos, incluso a gran escala. El temido dragón sacrificó gran parte de su propia energía vital para convertir a toda Inveria en zombis. Al replicar Evileye este hechizo, sin contar con una reserva de vida comparable, terminó absorbiendo involuntariamente la energía y las almas de todos los habitantes de su nación.

Tras este evento, Keno pasó a ser conocida como la Reina Vampiro Landfall (nombre derivado de la caída del reino) y fue "oficialmente" erradicada por el grupo de los Trece Héroes, aunque en realidad se unió a ellos.

"El Destruyepaíses": El lector lo desconoce, pero es una referencia a Evileye.

Primer enfrentamiento entre Shalltear y Brain Unglaus, tomo 4 del manga (ECC, enero de 2018).

En el mundo de YGGDRASIL existen diversas especies de vampiros.

Los vampiros “genuinos”, como Shalltear, poseen una apariencia original monstruosa.

Evileye en principio no es una vampira genuina y mantiene el aspecto de cuando se transformó.

Tomo 4 del manga en su versión española (ECC, enero de 2018).

Cabe destacar que en el primer episodio de la segunda temporada del anime, se observa a Tsaindorcus Vaision (aka "Platinum Dragon Lord") conversando con una anciana llamada Rigrit. En ese diálogo donde Tsaindorcus Vaision se intersa por el presente de Rigrit, sale a la palestra que ésta se ha jubilado dejando como sucesora a una joven a la que tuvo que retar en duelo y vencer para que ésta acabara uniéndose a las Blue Roses. Esa joven, que conocen tanto Tsaindorcus Vaision como Rigrit, es ni más ni menos que Evileye y los tres formaron parte del grupo de los Trece Héroes que se enfrentaron a las deidades del mal, un suceso que ocurrió aproximadamente doscientos años antes del inicio de la historia de Overlord.

Otro dato omitido en el anime es que tras el asalto de Jaldabaoth al reino sacro, se lleva a cabo una reunión entre las Blue Roses, Remedios Custodio y Gustav. En dicha reunión, las Blue Roses declinan ayudar al Reino Sacro debido a que no lograron vencer al demonio en un primer intento y sugieren contactar a Momón, la única persona conocida capaz de repeler a Jaldabaoth. Como anécdota, en dicha reunión, Evileye realizó un retrato del rostro de Jaldabaoth que provocó la risa de la escudera Neia Baraja, quien lo comparó con un dibujo infantil. Lamentablemente, no existen ilustraciones de dicho dibujo y la escena no está presente ni en el manga ni en el anime.

El combate entre Shalltear y Brain es puro cine.

Hago aquí una pequeña pausa sobre Evileye para retomar el combate entre Brain Unglaus y Shalltear, porque el lector o el espectador no se da cuenta, pero todo lo que sale ahí es puro cine. Pasan muchas cosas en apenas 10 minutos pero a primera vista no somos conscientes de todo lo que se cuece en dicho evento y por ende vemos todo un cúmulo de eventos pasar sin tener tiempo a asimilarlos. Por un lado tenemos a Brain Unglaus en una cueva de bandidos, por otro lado Shalltear está buscando a posibles candidatos que sepan usar técnicas y habilidades (las cuales no existían en YGGDRASIL), aparece Brita con una poción de Momón y de unos guerreros de hierro acaban apareciendo de la nada y le lanzan un ítem mundial para controlar mentalmente a Shalltear. Dicho así, no tiene sentido, ¿verdad?

Bueno, vamos por partes, lo primero es que estos eventos suceden justo después del combate entre Momón y Nabe contra Clementine y Khajiit Dale Badantel. Y esto es importante mencionarlo, porque Brita se encuentra por los alrededores buscando pruebas de que Zurrernorn ha sido vencida... Y es que, el grupo de bandidos para el que trabajaba en ese momento Brain trabajaba a su vez para Khajiit. Esto no sale directamente mencionado en el anime o el manga, pero sí en la novela ligera.

Brain acaba huyendo del combate y Shalltear en su persecución se topa con Brita, quien tiene en manos una poción originaria de YGGDRASIL y esto hace que Shalltear le perdone la vida al pensar que ella entra dentro de los planes de Ainz. Entonces Shalltear envía a sus familiares para acabar con el resto de testigos y descubre que a lo lejos varias de sus invocaciones han fallecido. Y al acercarse nos topamos con una serie de aventureros de hierro que acaban controlando mentalmente a Shalltear haciendo uso de un ítem mundial.

Ahora bien, esto no cuadra, puesto que en YGGDRASIL apenas habían 200 ítems mundiales y no es normal que un objeto tan único y valioso esté en manos de unos aventureros de tan bajo rango. De hecho, no son héroes, si no la Escritura Negra, una unidad de élite de la teocracia Slane, que andan buscando en las guaridas de Zurrernorn la corona mágica que robó Clementine. ¿Y por qué se identifican como aventureros de rango hierro? Bueno, por la sencilla razón de que están en una nación enemiga y necesitan pasar desapercibidos. Hicieron básicamente lo mismo que hizo Ainz con Momón, crear un grupo de aventureros para recaudar información. Ahora bien, el motivo original no era recuperar esa corona... Si recordáis los sucesos de Villa Carne, Ainz hace detonar una especie de barrera mágica que servía a la Teocracia para espiar a Nigun (líder de la Escritura de la Luz, que a su vez buscaba matar a Gazef Stronoff haciéndose pasar por atacantes del Imperio Baharuth). La Teocracia interpretó esa gigantesca explosión como una señal de que el temido Dragón Lord de la Catástrofe (Catastrophe Dragon Lord) estaba despertando en la región cercana a E-Rantel y, con pánico ante la amenaza del dragón, el país envió a su unidad de élite (la Escritura Negra) armada con su Objeto Mundial más valioso, "Ruina del Castillo y del País", con la misión específica de encontrar al dragón y tomar control mental sobre él para someterlo. Por cierto, ese ítem es originario de YGGDRASIL.

El caso es que la portadora del ítem mundial "Ruina del Castillo y del País" consigue controlar mentalmente a Shalltear, pero a su vez es muy malherida por ésta, hasta el punto de que en el primer episodio de la segunda temporada del anime el capitán de la Escritura Negra la da por muerta (en su conversación con Zesshi Zetsumei). Al estar controlada mentalmente sin haber recibido órdenes, Shalltear acaba en un estado de Stand-by, en el que simplemente se dedica a entrar en combate con cualquier persona que le ataque. Por cierto, en el primer episodio de la segunda temporada también vemos un flashback de Tsaindorcus Vaision en el que su armadura pelea contra ella en el que presumiblemente él huye, dando a entender que hubo un combate entre ellos en algún momento entre la huída de la Escritura Negra y el combate de Shalltear contra Ainz.

La princesa de Re-Estize envenenó un orfanato para poder convertirse en demonio.

En el arco “El Rey de la Conspiración” de la cuarta temporada del anime (capítulo 12), se observa a la princesa Renner Theiere Chardelon Ryle Vaiself en un orfanato preparando la comida, mientras insta a las monjas a que también se alimenten, justo antes de la invasión de E-Rantel (la capital del reino).

Sin embargo, según el autor, la acción de Renner no responde a una motivación altruista, sino que tiene como objetivo envenenar a los niños y a las monjas bajo el pretexto de recolectar almas para poder transformarse en demonio (objetivo que finalmente logra). De hecho, su transformación se debe a la Semilla de la Corrupción, un objeto mágico de YGGDRASIL que Albedo le entrega en el segundo episodio de la cuarta temporada del anime. Este objeto permite el cambio de raza a demonio, pero requiere una cantidad específica de almas para activar el proceso. Una vez caído el reino de Re-Estize, Albedo premia a Renner con una segunda semilla para su amado Climb.

Es difícil saber discernir cuando realizó exactamente el ritual para transformarse en demonio, puesto que cuando acudió al orfanato la guerra con el Reino Hechicero ya estaba declarada y cuando empezó el asedio a E-Rantel ella ya poseía una fuerza sobrehumana, siendo capaz de sostener la espada del gran guerrero Stronoff (entonces en propiedad de Brain Unglaus) sin problemas. Es de presuponer entonces que en el momento en que se reunió con las Blue Roses ella ya era un demonio (la escena justo después de la visita al orfanato).

De hecho, la escena del encuentro entre las Blue Roses y Renner es puro cine. Al observar la escena, vemos que sacan a Brain de la escena para evitar testigos, Tina se percata de que el servicio ha abandonado el palacio y Tia regresa para envenenar a Lakyus con una taza de té, tras lo cual le dan una brutal paliza para que acto seguido Evileye pueda hipnotizarla con el conjuro “Fascinar Humano”. Esto sugiere que han utilizado la reunión con Renner para huir con ella de Re-Estize, ya que era el único momento en el que Lakyus no llevaría consigo ningún equipo mágico.

Sin embargo, el trasfondo es mucho más profundo. En primer lugar, las Blue Roses, conscientes de que el Reino de Re-Estize está al borde del colapso ante el Reino Hechicero, no se atreven a debatir con su jefa, sino que prefieren llevársela a la fuerza; En segundo lugar, el motivo de la visita, que no se explica, es el de debatir la estrategia a seguir para repeler la invasión, pero la princesa no pone ninguna traba al motín y las deja huir como si nada, sin intentar convencerlas para que se queden. De hecho, detrás de esta traición hay un juego más oscuro. La reunión, supuestamente para planificar la defensa contra la invasión, es una trampa urdida por Renner, quien sirve a Albedo y busca neutralizar a Lakyus como potencial líder de resistencia, ya que es poseedora de la Kilineiram, una de las cuatro espadas del Caballaero Oscuro (miembro de los Trece Héroes) y además ella es el único habitante de Re-Estize con poderes de resurección. En tercer lugar, la ausencia del servicio no se debe a deserciones, sino a que deben haber perecido como sacrificio para el ritual transformación de Renner. En cuarto lugar, Evileye percata que algo ocurre con la princesa, pues la ve demasiado impasible, pero no llega a percibir de que está ante un demonio. Y, finalmente, Evileye les menciona que huyen a un país que cayó hace mucho tiempo, situado al sureste de Re-Estize (es decir, que vuelve a su antiguo reino, Inveria).

Qué pasó con los ciudadanos de Re-Estize

En el arco “El Rey de la Conspiración” de la cuarta temporada del anime vemos que Brain es congelado por Cocytus durante la invasión de Re-Estize. No se comenta en el ánime, pero durante esta invasión se realizan secuestros en masa por parte de Demihurgo para su granja

Durante el asalto a la capital y la posterior destrucción total del Reino, Demiurgo recolectó prisioneros en masa para realizar las siguientes atrocidades en su infame "Granga Feliz", un campo de concentración y de experimentación bilógica:

Producción de Pergaminos Mágicos (Desollamiento): El objetivo principal era conseguir materia prima para fabricar pergaminos consumibles de bajo nivel para Nazarick. Demiurgo desollaba vivos a los humanos (a quienes llama "ovejas bípedas") para quitarles la piel. Como los niños tienen una piel más fina y de mejor calidad, los priorizaba para este proceso.
Uso de Magia de Sanación Ciclica: Para maximizar la producción, los torturadores aplicaban magia de curación inmediatamente después de arrancarles la piel. Esto regeneraba sus cuerpos por completo, permitiendo que la misma persona fuera desollada una y otra vez de forma infinita.
Experimentos de Hibridación (Cruces Biológicos): Demiurgo estudió el problema de concepción entre especies forzando la reproducción entre humanos y diferentes tipos de demihumanos. Utilizaba magia de control mental (Charm) para obligarlos a aparearse, utilizando magia de curación cíclicamente durante el embarazo para intentar asegurar el nacimiento y luego analizaba los perturbadores resultados biológicos.
Injertos de Extremidades y Órganos: Realizaba cirugías experimentales cortando extremidades y órganos de familiares consanguíneos o de distintas especies para coserlos entre sí. El fin era comprobar si sobrevivían a las mutaciones usando magia de curación.
Tortura Psicológica Extrema: Obligaba a los miembros de una misma familia a desollar a sus propios hijos o los hacía comerse entre ellos para fomentar el odio y la desesperación absoluta entre los prisioneros, algo que le causaba un enorme placer.

Demiurgo enviaba a la Granja Feliz a todos los ciudadanos comunes (los que no tenían valía), mientras que los humanos con habilidades especiales tenían destinos muy diferentes y "privilegiados" dentro de Nazarick. Un detalle irónico de la historia es que Ainz Ooal Gown no comprende la magnitud de estas atrocidades. Ainz cree genuinamente que la "Granja Feliz" de Demiurgo cría algún tipo de monstruo quimérico o animal del Nuevo Mundo similar a una oveja, sin sospechar que se trata de seres humanos.

Sobre Brain Unglaus, Cocytus ordena congelar el cadáver para evitar que se descomponga y preservarlo con honor, esto, entre otras cosas, puede permitir resucitarlo más tarde. No obstante, más adelante Cocytus deja claro que traer a Brain a Nazarick como un sirviente o para experimentos (el destino habitual que Demiurgo le da a los humanos valiosos) sería una tremenda falta de respeto a su resolución como guerrero. En el Volumen 14, Cocytus menciona textualmente que prefiere asumir la responsabilidad ante Ainz antes que profanar el cuerpo de alguien que lo enfrentó con tanto honor, por lo que se queda así, congelado de por vida como Han Solo en Star Wars. Cabe destacar que en la novela web original (que ya no es canon), Brain acaba capturado por Shalltear, convertido en vampiro y obligado a servir a Nazaric

Los Trece Héroes no eran trece.

El grupo conocido como los Trece Héroes se formó hace doscientos años con el objetivo de combatir a las deidades malignas. A pesar de su nombre, la composición del grupo no se limitó a trece miembros. El número de héroes fluctuó a lo largo del tiempo debido a fallecimientos, deserciones y nuevas incorporaciones, hasta que sólo trece lograron sobrevivir. Sin embargo, según se menciona en la novela ligera, el grupo llegó a tener más de trece supervivientes. La lista oficial omitió a aquellos que no eran humanos, como la realeza élfica, vampiros como Evileye, dragones como Tsaindorcus Vaision o el capitán de los gigantes de aire, con el fin de exaltar la heroicidad humana. Asimismo, se omitió el origen de algunos héroes, como el Caballero Oscuro, quien tenía sangre demoníaca (volumen 10, capítulo 3).

Además, en el arco argumental “Los Hombres en el Reino”, Sebas informa a Ainz que Evileye posee un nivel que oscila entre el 50 y el 60. Considerando que Evileye es uno de los héroes más poderosos, esto sugiere que el grupo de los Trece Héroes es considerablemente más débil que los personajes de nivel 100 que conforman la Gran Tumba de Nazarick. Esta afirmación se ve corroborada por Fluder Paradyne (el mago de la corte del Imperio Baharuth) durante una conversación con Jircniv Rune Farlord El Nix (el emperador del Imperio Baharuth), el cual menciona que el hechizo más poderoso realizado por los Trece Héroes era de nivel 5, muy por debajo de los hechizos más potentes de Nazarick. Pléyades como Narberal Gamma, de nivel 63, y por consiguiente más acorde al poder que tendrían dichos héroes, puede lanzar hechizos de nivel 7.

Por otro lado, el dragón plateado que, manejando un avatar con forma de armadura y armas flotantes, se enfrenta a Pandora’s Actor (disfrazado de Ainz) en la cuarta temporada del anime, es otro de los miembros de los Trece Héroes. Cabe destacar que este dragón es el propietario del ítem mundial que acaba manipulando la mente de Shalltear en la primera temporada del anime (un vestido llamado "Ruina del Castillo y del País"), pero él no estaba presente en la escena (el vestido estaba siendo portado por la hechicera Kaire). Durante su combate contra Pandora se presenta con un nombre falso, Rick Aganeia, pero su nombre real es Tsaindorcus Vaision y, aunque en el anime se dé a entender que se trata de un jugador de YGGDRASIL, no lo es: simplemente conoce de su existencia. ¿Cómo es posible? Pues porque en las novelas se da por hecho que su padre, el Dragón Emperador, fue un jugador de YGGDRASIL. Y bueno, se ve que Tsaindorcus Vaision era todo un coleccionista de trajecitos de YGGDRASIL, puesto que en la cuarta temporada le vemos interesado en tomar por la fuerza la "armadura del poder" de Azuth Aindra (especula con matarlo y dárselo a otra persona).

Cabe destacar también que, según la novela ligera, en el grupo de los Trece Héroes también hubo dos jugadores de YGGDRASIL, entre ellos su líder (el cual aparece brevemente mencionado por Evileye en el capítulo 30 del manga).

Las tres elfas que acompañan a Erya Uzruth acaban viviendo en Nazarick y sirviendo a Aura y Mare Bello Fiore.

Erya Uzruth lidera el grupo de aventureros Tenmu, establecido en el Imperio Baharuth. Su grupo está compuesto por él y tres esclavas elfas: una clérigo, una druida y una exploradora. Su personalidad se caracteriza por la arrogancia, el egocentrismo, la crueldad, la misoginia y el racismo. Durante el arco argumental “Los Invasores de la Gran Tumba”, se hace acompañar por sus esclavas para que le lancen hechizos de apoyo que mejoran sus habilidades.

Estas tres elfas fueron inicialmente esclavizadas por la Teocracia Slane, nación cuya religión justifica la superioridad humana sobre otras razas y que se encuentra en guerra con el reino elfo. Posteriormente, fueron vendidas a Erya. De hecho, el personaje es tan cretino que muchos aficionados a Overlord creen que es originario de la Teocracia, pero hasta la fecha, ni en la novela web ni en las novelas ligeras se menciona su origen.

En el arco argumental “Los Invasores de la Gran Tumba”, Erya muere en combate contra Hamesuke, el Rey Sabio del Bosque. Tras su muerte, las tres esclavas comienzan a golpear el cuerpo sin vida de su amo. No obstante, el anime no menciona que, durante el arco argumental “Arco del Rey de la Conspiración”, Ainz decide perdonarles la vida al comprender que invadieron la tumba en contra de su voluntad. Acto seguido, las pone bajo la custodia de Aura y Mare, en el sexto piso de Nazarick, con la esperanza de que contribuyan al desarrollo mental de estos dos elfos oscuros (a pesar de tener 76 años, se consideran niños en su raza).

Desarrollaron una lealtad extrema hacia los dos elfos oscuros, hasta el punto de que Aura y Mare las consideraban una molestia. Esta situación generó una preocupación en Ainz por la seguridad de las sirvientas, lo que lo llevó a prohibir expresamente cualquier daño hacia ellas.

Los jugadores de YGGDRASIL llegan por "oleadas"

Cada cien o doscientos años se produce algún evento significativo en el “nuevo mundo”, hecho que se menciona tanto en las novelas como en el anime y el manga. Si se analizan estos eventos, se observa lo siguiente:

Hace 600 años surgieron los seis grandes dioses, considerados los creadores de la Teocracia Slane. Se les atribuye la introducción de las magias de nivel superior, lo que sugiere que podrían haber sido jugadores con un poder similar al de YGGDRASIL. Es importante señalar que, hasta su llegada, se consideraba a los humanos como seres inferiores, ya que no estaban tan preparados o evolucionados como los semihumanos para adaptarse a condiciones extremas. Y bueno, en el primer episodio de la segunda temporada vemos a Zesshi Zetsumei jugando con un cubo de rubik mientras habla con el capitán de la Escritura Negra. Como es lógico, no es normal encontrarnos con un cubo de rubik en un mundo de fantasía medieval y en la conversación entre ambos se menciona que el cubo en realidad es una reliquia que perteneció a los seis grandes dioses.
Hace 500 años llegaron los Ocho Reyes de la Codicia, quienes se enfrentaron a los señoríos dragonianos. En el volumen 7 (capítulo 67), una conversación entre Evileye y Climb da a entender que puede que sean jugadores, debido a que eran seres capaces de gobernar el mundo con magia de alto nivel y poseían artefactos legendarios como el Nameless Spellbook.
Hace 200 años, se formó el grupo de los Trece Héroes (de los cuales dos se confirma que fueron jugadores de YGGDRASIL) y apareció también el Minotauro Sabio (que presumiblemente es otro jugador).
Y en la actualidad, ha aparecido la Gran Tumba de Nazarick, con Ainz y su ejército de NPC de alto nivel.

En los glosarios del manga, se da a entender que los Seis Grandes Dioses fueron jugadores.

El caso del Minotauro Sabio resulta particularmente interesante, ya que nunca se confirma explícitamente que se trate de un jugador, aunque se sobreentiende que lo fue debido a que introdujo artefactos mágicos de uso cotidiano muy avanzados para la época (como neveras, ventiladores, métodos quirúrgicos, etc.). Este personaje también aparece mencionado brevemente en el arco argumental “Los Invasores de la Gran Tumba”, donde los trabajadores descubren una serie de productos que atribuyen al Minotauro Sabio.

Respecto a la razón de estas apariciones de jugadores en periodos de 100/200 años, Ainz especula que el teletransporte a un nuevo mundo podría estar relacionado con el consumo de un ítem de clase mundial. Esta hipótesis se menciona en una reflexión del volumen 7, donde Ainz especula que el Dragón Emperador fue un jugador de YGGRDRASIL que llegó al “nuevo mundo” tras usar el ítem mundial, otorgando a esta teoría veracidad (por lo que puede considerarse prácticamente canon).

Según el glozario del manga, sólo existen 200 ítems de nivel world.

Además, en el volumen 3, se define a los “ítems mundiales” como artefactos "equivalentes (en poder) a un mundo", vinculados al poder extremo y capaces de influir en el traslado dimensional. Ainz explica que son elementos muy desequilibrados que generan efectos únicos en el mundo. Así mismo, en el primer episodio, minutos antes del cierre de los servidores, Momonga utiliza presumiblemente un ítem equivalente a item mundial para modificar la ficha de Albedo, lo cual es fundamental en la teoría del teletransporte. Puede parecer absurdo utilizar un ítem tan poderoso para modificar únicamente una ficha, pero recordemos que desde el punto de vista de Momonga, al universo de YGGDRASIL le quedaban apenas minutos de vida (el servidor se iba a desconectar en minutos).

No obstante, esa teoría está cogida con pinzas, puesto que se da a entender que usa el báculo de Ainz Ooal Gown para hacer la modificación y éste es, en teoría, de nivel divino (un nivel inferior a un ítem mundial). La necesidad del báculo radicaba en que, según la novela ligera, se le considera el báculo del gremio y, en virtud de ello, otorga permisos de administración sobre éste (volumen 1, capítulo 1, parte 2). No obstante, y también según la novela ligera, el báculo nunca antes había sido utilizado, ni siquiera tras su construcción (volumen 1, capítulo 1, parte 1). Además, se especula con que su poder es comparable al de un ítem mundial debido a la cantidad de poder incrustado en él: las siete joyas que lo componen son, a su vez, siete artefactos de clase divina, con las alineaciones elementales de Sol, Luna, Tierra, Fuego, Viento, Agua y Tiempo. Es decir, el mero hecho de haber utilizado por primera vez el báculo, habría propiciado el teletransporte al nuevo mundo, o por lo menos, eso es lo que se da a entender.

Ahora bien, a diferencia de los ítems de clase mundial, los ítems divinos no tienen por qué ser únicos y es probable que existan báculos como el de Ainz Ool Gown en otros gremios (el gremio de Ainz era de los más fuertes de YGGDRASIL, pero no el más fuerte), lo cual echa por la borda esta teoría.

En el glosario del manga se explica que el báculo de Ainz es de nivel divino.

Para añadir más leña al fuego, es evidente que, considerando que al cierre de los servidores de YGGDRASIL, el juego había funcionado durante 12 años, y que en el “nuevo mundo” las oleadas de héroes aparecen cada 100 o 200 años, la relación espacio-temporal entre ambos universos difiere notablemente. En este sentido, los 12 años transcurridos en el mundo real se han traducido en aproximadamente 600 años en el “nuevo mundo”. Y puestos a explotar el espacio-tiempo, Maruyama explota este factor al máximo: En el material canónico (novelas, manga, anime), los jugadores del pasado no se limitan a ser antiguos usuarios de YGGDRASIL, sino que se sugiere que podrían provenir de diferentes juegos o incluso de realidades paralelas, aunque esto no se explica con total claridad y queda abierto a la interpretación del lector. La posibilidad de múltiples orígenes se basa en que algunos personajes y eventos presentan habilidades o tecnologías que no encajan exclusivamente con YGGDRASIL, lo que apunta a fuentes externas. Además, la mención de portales dimensionales y viajes en el tiempo en ciertos pasajes también respalda la teoría de realidades múltiples. En otras palabras, si el guion sugiere la existencia de realidades paralelas y jugadores de diferentes juegos, no sería descabellado que las condiciones de acceso de cada oleada fueran variables, por lo que la teoría del teletransporte por usar el báculo "divino" podría encajar, pese a estar cogida con pinzas.

También es cierto que la narrativa de la obra no siempre establece una distinción clara entre jugadores y personajes no jugables: Muchos personajes considerados “jugadores” en el “nuevo mundo” son en realidad NPCs con inteligencia artificial avanzada, por lo que la línea entre jugador y NPC resulta difusa. El hecho de que se nos revele desde el primer episodio que Momonga carece de familiares y que se nos indique al inicio que nadie lo echará de menos, puede incluso llevarnos a cuestionar su verdadera naturaleza. Pero partiendo de que se trata de un jugador, el mundo de Overlord se percibe como un entorno orgánico donde, al igual que en un juego de rol clásico, los jugadores pueden contraer matrimonio, tener hijos y tomar decisiones que se reflejan en sus acciones. Por poder, pueden incluso morir de forma definitiva. Y esa es precisamente la magia de la obra de Maruyama: un Universo que se siente vivo, bien construido e invita al lector a adentrarse cada vez más en él.

Si Ainz golpea una puerta o toma una decisión, el lector sabe que habrá una reacción consecuente, ya sea visible o en las sombras. A lo largo de la historia, distintas facciones políticas y nacionales actúan en función de lo que perciben, muchas veces de manera oculta o estratégica. Esta interconexión dinámica entre personajes y fuerzas hace que el mundo no sea estático, sino una red compleja de causas y efectos donde cada acción tiene su repercusión, enriqueciendo la experiencia narrativa y haciendo que cada evento tenga peso dentro del lore.

Los semidioses son descendientes de jugadores

Una de las escenas más cómicas del inicio de la serie es cuando vemos a Albedo y Shalltear empiezan a pelear por quién será la consorte de Momonga y acto seguido Demiurgo espeta a Mae y Cocytus un "me gustaría saber como acaba esto". Esto deja desconcertados a Mae y Cocytus, puesto que Demiurgo es un ser frío y calculador que rara vez presta atención a asuntos tan triviales y la conversación deriva a que a Demiurgo le encantaría saber si Momonga podría dejar descendencia para tener un heredero al que venerar si algún día éste desaparece como los otros grandes seres supremos.

Esto deriva más adelante en una subtrama bastante oscura que se pasa bastante por alto en el ánime, en el que Demiurgo acaba montando granjas de humanos y, entre otras cosas, acaba experimentando con ellos la viabilidad de cruzar razas.

En todo caso, una vez estalla abiertamente el conflicto con la Teocracia Slane (y no me refiero al ataque a Villa Carne, la aldea inicial, si no a que cuando ambas potencias están descaradamente en guerra), sale a la luz la existencia de semidioses. Estos no son, ni más ni menos, que descendientes de los seis grandes dioses o de los Ocho Reyes de la Codicia, que, como ya hemos mencionado, a su vez eran jugadores que llegaron al "nuevo mundo" y que han heredado parte de sus atributos.

No obstante, la gran mayoría de los descendientes de jugadores no heredan los atributos, ni el poder, de sus ancestros. En el universo de Overlord, tener la sangre de un jugador (un Dios) en las venas es una condición necesaria, pero no garantizada, para obtener un poder extraordinario. De hecho, aquí entra el concepto de "despertar", término empleado cuando un descendiente hereda atributos anormalmente altos para un humano. Esto no es un hecho oculto en el "nuevo mundo" y potencias como la Teocracia Slane ejercen un control estricto del lineaje de los héroes, forzando una cría selectiva: Selecciona la pareja de los herederos basándose en sus atributos para intentar preservar o potencia el lineaje de los héroes.

Este control de lineaje de la Teocracia puede parecer bastante perverso, pero se queda corto si lo comparamos con el reino de los elfos: La supervivencia del más apto. El brutal método del Rey de los Elfos, Decem Hougan, para "despertar" el poder de sus hijos, partía de una lógica completamente errónea. Decem asumía que el trauma y el estrés extremo en un combate a muerte actuarían como catalizadores mágicos; por ello, engendró cientos de descendientes solo para enviarlos a la guerra siendo niños. Lo que el monarca ignoraba es que el sistema de Overlord no funciona por superación personal, sino por una estricta lotería genética. El "Despertar" depende enteramente del límite de nivel máximo fijado de forma pasiva en la concepción; al nacer como elfos comunes carentes de este potencial expandido, sus hijos terminaron masacrados en el frente, dejando a Decem atrapado durante siglos en un bucle de frustración y experimentos fallidos.

Zesshi Zetsumei, miembro de la escritura negra de la Teocracia, es condiserada la semidiós más poderosa del "nuevo mundo", debido a que es hija ilegítima de Decem Hougan (hijo de uno de los ocho reyes de la codicia) y de Faim, descendiente de los seis grandes héroes. Fain era la semidiós humana más poderosa de la Teocracia Slane en su tiempo, pero fue raptada por el rey de los elfos, Decem Hougan, quién la engañó, la secuestró y la violó con la obsesión de engendrar un heredero poderoso. Fain fue rescatada eventualmente por la Escritura Negra y, al regresar a la Teocracia, dio a luz a Zesshi Zetsumei (cuyo nombre real es Antilene Heran Fouche).

Ainz es frío e inhumano porque su mundo "real" es frío e inhumano

El mundo real de Satoru Suzuki (nombre real del jugador que maneja a Ainz Ooal Gown) en el año 2138 es una distopía cyberpunk extrema, opresiva y desoladora. Es un entorno tan hostil que explica por qué los miembros del gremio de Ainz Ooal Gown estaban tan obsesionados por crear NPCs tan mentalmente aterradores o por qué Ainz en ocasiones toma bastantes decisiones frías, sin importar lo que le pase a la gente común.

A través de las novelas ligeras y las memorias de Ainz, se revelan los crueles detalles de su sociedad original:

Colapso ambiental absoluto.

Cielo negro y niebla tóxica: El sol casi nunca es visible debido a una capa permanente de contaminación industrial espesa.
Equipo de supervivencia urbano: Salir a la calle requiere el uso obligatorio de máscaras de gas, filtros de aire y gafas protectoras. La contaminación es tan corrosiva que daña la ropa común.
Pulmones artificiales: Muchas personas de la clase trabajadora sufren daños pulmonares severos y dependen de costosos órganos cibernéticos artificiales para respirar.
Lluvia ácida y agua envenenada: El agua de los grifos debe filtrarse múltiples veces para ser potable. Los ríos fluyen con colores extraños debido a los desechos químicos.
Naturaleza muerta: La vegetación natural, las plantas, los pájaros y los insectos prácticamente dejaron de existir en estado salvaje.

El control total de las Megacorporaciones

Dictadura corporativa: Los gobiernos nacionales colapsaron o se convirtieron en títeres. El mundo está gobernado directamente por un conglomerado de megacorporaciones que redactan las leyes a su conveniencia.
Explotación laboral extrema: Las jornadas laborales de los empleados comunes son inhumanas. La madre de Satoru murió por exceso de trabajo en la cocina de su casa tras turnos interminables. El propio Satoru no tenía vida social ni familia, reduciendo su existencia a dormir, trabajar y jugar.
Asesinatos corporativos: Las corporaciones operan con total impunidad. Si alguien descubre secretos comerciales o intenta rebelarse, es asesinado discretamente por mercenarios de la empresa (como le sucedió a Bellriver, uno de los miembros originales del gremio).

Pobreza y alimentación artificial

Comida sintética: Toda la agricultura tradicional desapareció porque la tierra está envenenada. Los alimentos frescos (frutas y verduras) se cultivan solo en domos privados y son lujos exclusivos de los ejecutivos ricos.
La dieta de la clase baja: La gente común como Satoru subsiste a base de suplementos nutricionales en pastillas y alimentos líquidos con saborizantes artificiales (como gachas con sabor a filete).
Educación privatizada: La educación primaria obligatoria fue abolida deliberadamente por las empresas para crear una masa trabajadora dócil. Estudiar cuesta mucho dinero; Satoru solo pudo terminar la escuela primaria antes de ser forzado a trabajar.

El escape a través de la tecnología virtual

Interfaces neuronales: Para interactuar con las máquinas y los juegos, las personas se inyectan nanomáquinas directamente en el cerebro a través de puertos de red integrados en sus cuerpos.
YGGDRASIL como única salvación: Para millones de personas atrapadas en apartamentos minúsculos y rodeados de basura, los videojuegos de inmersión total eran la única forma de ver un árbol, sentir el viento limpio, contemplar estrellas reales o experimentar un cielo azul.

La forma en que opera la Gran Tumba de Nazarick y el tipo de "destrucción" que Ainz Ooal Gown lleva a cabo en el Nuevo Mundo es una alegoría perfecta y deliberada del comportamiento de las despiadadas megacorporaciones de su mundo original.

El autor, Kugane Maruyama, utiliza el trasfondo distópico de Satoru Suzuki para moldear la mentalidad de Ainz. Al no haber recibido una educación formal más allá de la primaria y haber pasado toda su vida adulta como un oficinista alienado, Ainz no piensa como un rey medieval o un señor feudal; piensa y actúa como un oficinista corporativo, puesto que es lo único que sabe hacer.

Aquí os dejo los paralelismos exactos que demuestran esta alegoría:

La mentalidad de "Costo-Beneficio" y el Crecimiento Infinito: Para Ainz, la destrucción y la conquista no nacen de la maldad pura, sino de la fría búsqueda de eficiencia, recursos y expansión:

En su mundo original las megacorporaciones contaminaban el planeta y dejaban morir a la gente común porque mitigar el daño ambiental reducía sus márgenes de ganancia. El beneficio económico justificaba cualquier costo humano.
Por otro lado, si un reino o una población no aporta un beneficio neto a Nazarick, o si interfiere con sus planes de expansión, su eliminación se trata simplemente como un "recorte de gastos" o la absorción agresiva de un competidor. La masacre en las Planicies de Katze o la destrucción de Re-Estize son vistas por Ainz como meras operaciones logísticas necesarias para el crecimiento de su "empresa".

Cultura laboral tóxica:

Ainz se preocupa por el bienestar de los Guardianes, pero su mayor temor es que sus "empleados" sufran de burnout (desgaste laboral) o insatisfacción que baje su productividad. Los guardianes (como Albedo o Demiurgo) compiten de forma enfermiza por trabajar horas extras y complacer al "Jefe", viendo el descanso como una debilidad.
El "Salario" es el reconocimiento: Al igual que las empresas del año 2138 que pagaban salarios de miseria y exigían lealtad absoluta, Ainz mantiene a sus súbditos motivados no con libertad, sino con palabras de elogio corporativo y ascensos simbólicos.

La deshumanización del "Recurso Humano": Para las megacorporaciones del año 2138, las personas no eran más que engranajes reemplazables en una inmensa máquina de producción. Esta misma lógica se refleja perfectamente en Nazarick. Lo vemos en los experimentos de Ainz con personajes como Roberdyck o Clementine, pero sobre todo en la "Granja Feliz" de Demiurgo: los habitantes del "nuevo mundo" dejan de ser personas para convertirse en simples "ovejas bípedas", materia prima reciclable cuya piel se usa para fabricar pergaminos mágicos.Es un espejo brutal del mundo de Satoru Suzuki, donde los trabajadores eran consumidos hasta morir de agotamiento, tal como le ocurrió a su propia madre. Paradójicamente, uno de los momentos en los que Ainz parece más humano es cuando decide resucitar a Shalltear, un acto que va más allá del puro cálculo de costo-beneficio.
La falta de empatía por el condicionamiento social: Satoru Suzuki creció en un mundo donde ver cadáveres de huérfanos en la calle al ir a trabajar era algo cotidiano y normalizado.

Nadie se detenía a ayudar porque el sistema te obligaba a mirar hacia otro lado para sobrevivir.
Cuando es transportado al Nuevo Mundo y pierde sus emociones humanas debido a su cuerpo de no-muerto, esa apatía social corporativa se magnifica. Ainz puede ordenar la masacre de millones de personas sin sentir remordimiento porque, en su mente, está ejecutando un plan de negocios a largo plazo, desprovisto de cualquier carga moral.

En conclusión, la tragedia de Overlord es que Ainz, a pesar de odiar el mundo distópico del que vino, terminó convirtiéndose en el CEO definitivo, recreando en el Nuevo Mundo el mismo sistema corporativo, implacable y deshumanizante que destruyó su planeta original. La alegoría corporativa es una interpretación popular, aunque Maruyama no la hace explícita al 100%. Digamos que es canon que es un mundo de Satoru es horrible y que explica su mentalidad, pero el autor no lo dice abiertamente.

Cada vez que Ainz siente una emoción humana intensa (empatía, pánico, culpa o profunda tristeza), una luz verde brilla en su cuerpo y sus emociones son reprimidas a la fuerza, devolviéndolo a un estado de fría calma. Esto, como alegoría, refleja exactamente lo que Satoru Suzuki tenía que hacer cada mañana en su mundo real. Para sobrevivir en su sociedad distópica, donde pasaba junto a niños muriendo de hambre en la calle para ir a su oficina, Satoru tuvo que "apagar" su empatía. Su mente humana ya tenía un "supresor emocional" psicológico; el cuerpo de no-muerto solo lo hizo biológico y permanente: Un esqueleto no tiene corazón, no tiene estómago, no tiene órganos y no puede dormir. Ainz a menudo se queja de que ya no puede disfrutar del sabor de la comida o del descanso.

La vida de Satoru en el año 2138 ya estaba completamente vacía. Su rutina diaria se reducía a trabajar, comer gachas sintéticas, dormir en un apartamento diminuto y jugar. No tenía familia, amigos reales en el mundo físico, ni pasiones fuera de YGGDRASIL. Su existencia ya era la de un "muerto en vida" que solo operaba por inercia. Al convertirse en un no-muerto, su cuerpo simplemente se adaptó a la realidad de su alma: un cascarón vacío que solo vive para que los engranajes de su organización sigan girando.

Lo trágico es que Ainz no eligió ser un monstruo por pura maldad; fue moldeado por el capitalismo salvaje de su mundo. Al igual que las megacorporaciones destruyeron el ecosistema de la Tierra y deshumanizaron a la humanidad en el año 2138 sin sentir culpa (porque los sistemas corporativos no tienen moral, solo metas), Ainz destruye el "nuevo mundo" siguiendo la misma lógica fría.

En conclusión, el cuerpo de no-muerto de Ainz es el espejo de su tragedia. Es el recordatorio constante de que Satoru Suzuki murió mucho antes de llegar al "nuevo mundo"; Había que ser alguien "útil" a la sociedad para entrar en su gremio y, a pesar de ser un gremio con 41 seres supremos, sólo HeroHero vino a despedirse de él; El sistema corporativo de su tierra natal lo mató por dentro, y el "nuevo mundo" solo le dio el cuerpo de esqueleto adecuado para que pudiera gobernar como el director ejecutivo de la destrucción.

El problema de los isekais es que es fácil identificarse con sus protagonistas puesto que son personas normales, como tú o como yo, que acaban en un mundo nuevo. Y aquí viene la magia de Maruyama, Satoru no viene de un mundo como el tuyo y quiere incomodar que te identifiques con él.

Fuentes de interés:

https://www.youtube.com/@redfairy
https://www.youtube.com/@An1meNotes
https://www.youtube.com/@NazarickArchives
https://www.youtube.com/@AniNews
https://www.youtube.com/@animerankerchannel
https://www.youtube.com/@eRReAnime
https://www.youtube.com/@over.d.lord1
https://overlord.fandom.com/es/wiki/Overlord_Wiki
https://overlordmaruyama.fandom.com/wiki/Overlord_Wiki
Novelas ligeras en francés (he comprado 5 para redactar esta entrada): https://www.pointmanga.com/categorie-produit/light-novel/overlord/
Anime (castellano/catalán) https://shop.selecta-vision.com/#5240/fullscreen/m=and&q=overlord

Presentando el Mode9, una librería que extiende DIV2 Games Studios para cargar objetos y mundos 3D en formato OBJ

2026-06-13T01:42:35.453+02:00

Hoy os presento un nuevo capítulo sobre DIV2 Games Studio, un entorno de programación de videojuegos para MS-DOS lanzado en 1999 (y su precuela un año antes) que fue bastante popular en España, en buena parte porque se vendía en los quioscos a un precio muy asequible. Pero el de hoy no es un capítulo cualquiera: Es, probablemente, el proyecto más ambicioso que he traído al blog hasta la fecha.

Como sabéis, DIV2 traía de serie una colección de "modos" de pantalla. Por un lado teníamos el modo 7, que abatía un plano y dibujaba sprites escalados por la distancia (truco empleado en juegos como Super Mario Kart); por otro teníamos el modo 8, que permitía moverse por mapas de sectores planos (`.WLD`) que simulaban un entorno tridimensional, al estilo de los FPS pre-3D (como el primer Doom). Y ya está, eso era lo más parecido a las 3D que podíamos hacer hasta la fecha en DIV Games Studio: Nada de rampas, pendientes, personajes poligonales, etc.

Siempre me quedé con la espinita de hasta dónde se podría empujar el motor… y de ahí ha salido esto: una DLL que añade a DIV2 un nuevo modo que he bautizado como Modo 9, capaz de cargar y recorrer escenarios y objetos tridimensionales de verdad, modelados, por ejemplo, en Blender y exportados como ficheros OBJ. Y podéis descargarla libremente desde mi GitHub e incluso ojear su código fuente (https://github.com/LeHamsterRuso/Mode9/tree/main/BIN).

¿Qué es exactamente el Modo 9?

Podéis ver el Modo 9 como el hermano mayor del modo 8. Donde el modo 8 te daba sectores planos y en un formato propietario (propiedad de Hammer Technologies), el modo 9 te deja cargar cualquier tipo de malla 3D: paredes, suelos, techos y rampas con cualquier inclinación. La cámara es un proceso normal de DIV2 (lo mueves con `advance()`, lo giras cambiando su `angle`, igual que en el modo 7 y 8), así que puedes ponerla en primera persona, en tercera persona siguiendo al personaje, en vista cenital o donde se te ocurra.

Y sobre ese escenario 3D puedes colocar tus personajes de tres maneras:

Como billboards planos (sprites 2D que se escalan con la distancia y siempre miran a la cámara, igual que el modo 7). Perfectos para antorchas, árboles o carteles.
Como billboards con perspectiva (objetos con una serie de sprites donde el gráfico cambia según el ángulo). Perfecto para personajes (es por ejemplo el tipo de billboards que vemos en juegos como Daggerfall, Doom o el Super Mario Kart de SNES).
Como objetos 3D de verdad, mallas OBJ que puedes rodear y ver desde todos los ángulos, con soporte incluso para animación por vértices (vertex morphing).

Por debajo lleva todo lo que cabe esperar de un motor de la época: gráficos que recuerdan al 3D de la época de la PSX, niebla por distancia, cielo panorámico de 360º, z-buffer, colisiones con deslizamiento, subida automática de escalones y rampas, downscale opcional (baja la resolución nativa del 3D) para ganar velocidad e incluso split-screen a cuatro cámaras. Todo en una DLL compilada con Watcom C++ 10.6, como mandan los cánones.

Cosas a tener en cuenta:

Cuanto menos polígonos tenga tu escenario y objeto 3D, mejor. Intenta no usar modelos de más de 400 polígonos... la librería lo permite, de hecho permite modelos de hasta 8k caras, pero ten en cuenta que un modelo de varios miles de vértices puede hacer que tu juego vaya terriblemente lento.
Los modelos deben de exportarse con caras trianguladas, forward axis -Z y up axis Y.
Los materiales (texturas) no deben de exceder los 1024x1024 (y a ser posible que tenga un tamaño de potencia de 2, como 128x128, 256x256, 512x512, etc). Además debes de convertirlos a formato MAP a 256 colores (el formato típico de DIV y DIV2).
El cielo panorámico no debe de exceder los 4096 x 2048 píxeles.

¿Cómo se usa? El esqueleto mínimo

Una cosa que nos hace falta es declarar un typo de proceso c_m9. Por desgracia este tipo de estructura no se pueden inyectar directamente desde las DLL de DIV2 y toca inicializarla en cada proyecto que use esta librería. Con este ejempo, podemos arrancar un mundo 3D con apenas unas pocas líneas (recuerda copiar la DLL en la carpeta DLL que hay dentro de DIV2 antes de arrancar el PRG):

PROGRAM paso1;
IMPORT "MODE9.DLL";
CONST
    c_m9 = 200;
GLOBAL
    STRUCT m9   z; camera; height; angle;   END
BEGIN
    load_pal("div2.pal"); 
    set_mode(m320x200);
    set_fps(60, 0);

    LOAD_WLD9("OBJ/CASTLE.OBJ", "MAP/CASTLE.MAP", 100);  // escenario
    LOAD_SKY9("MAP/SKY.MAP");                     // cielo (opcional)
    MODE9_STEP(70);                              // altura de los escalones

    camara();   // proceso de cámara
END

PROCESS camara()
BEGIN
    x = 0;  y = -1500;  z = 0;
    angle = -90000;       // mirando hacia el porton del castillo

    m9.camera = id;       // Este proceso es la cámara
    m9.height = 160;      // altura del ojo (uds DIV2)
    m9.angle  = 0;        // pitch (0 = horizonte)

    START_MODE9(id, OFFSET m9.z, 0);

    LOOP
        if (key(_w)) advance(20); end
        if (key(_s)) advance(-20); end
        if (key(_a))  angle += 4000; end
        if (key(_d)) angle -= 4000; end
        if (key(_esc)) break; end
        FRAME;
    END
END

Como veis, la sintaxis recuerda mucho al modo 8 y en este ejemplo cargamos como escenario un fichero 3D en formato OBJ, le aplicamos un material por defecto, le aplicamos una textura de cielo panorámico y nos desplazamos por el escenario con los típicos controles de WASD. A partir de ese punto, mover la cámara es exactamente igual que mover cualquier proceso de DIV2. Pero lo mejor es verlo crecer paso a paso, que es justo lo que hacen los siguientes ejemplos.

Los ejemplos, uno a uno

He preparado seis programas (ficheros PRG) que van añadiendo una sola cosa nueva cada vez, de modo que podáis parar en el que queráis sin miedo a romper nada. Todos comparten el mismo escenario: un castillo con su patio, una escalera, un lago alrededor de la isla y un cielo panorámico.

MODE9_01.PRG · Un mundo vacío para pasear

Este fichero es el punto de partida: Cargamos el castillo con `LOAD_WLD9()`, le asignamos sus tres texturas por material (`MODE9_MATERIAL` para la escalera y el agua, ya que `CASTLE.OBJ` trae tres `usemtl`: castillo, escalera y lago) y arrancamos el render.

La cámara incluye lo que se espera de un FPS clásico: movimiento con WASD, desplazamiento lateral, ratón para girar y mirar arriba/abajo, salto con gravedad y agacharse. Aquí ya se aprecian las colisiones con deslizamiento y el `MODE9_STEP(70)` subiendo la escalera del patio sin que tengamos que programar nada más.

Cosas a tener en cuenta: La librería permite desactivar y activar las colisiones, de forma que puedas traspasar paredes o incluso golpearte con el techo. No obstante, la gravedad (el hecho de caer hacia abajo) debe de implementarse en el propio PRG.

Como apreciaréis, he inundado el código con comentarios explicando qué hace cada nueva función de este modo. Por cierto, si pulsáis multiples veces espacio podréis "volar". Es un bug del PRG que he mantenido porque en cierta forma sirve para explorar y ver el escenario desde el cielo.

//------------------------------------------------------------------------------
// TITLE:       MODE9.PRG
// DATE:        06/06/2026
// DESCRIPTION: Ejemplo del "modo 9": desplazamiento por un escenario 3D (.OBJ)
//              con camara en primera persona (estilo Doom / Elder Scrolls Arena)
//              usando MODE9.DLL.
//
// CONTROLES:
//   W / S         : avanzar / retroceder (SHIFT = correr)
//   A / D         : desplazamiento lateral (strafe)
//   Raton         : girar (horizontal) y mirar (vertical / pitch)
//   ESPACIO       : saltar
//   CTRL          : agacharse
//   ESC           : salir
//
// FICHEROS NECESARIOS:
//   CASTLE.OBJ    : Escenario 3D (castillo + escalera en el patio + lago isla;
//                   3 materiales por 'usemtl': Castle, Stairs, Water).
//   MAP/CASTLE.MAP: Textura del castillo (material 0, por defecto).
//   MAP/STAIRS.MAP: Textura de los peldaños de la escalera (material 1).
//   MAP/WATER.MAP : Textura del lago que rodea la isla (material 2).
//   MAP/SKY.MAP    : Textura del cielo panorámico (skybox).
//
// SOBRE m9 Y c_m9:
//   En DIV/DIV2, una DLL no puede crear STRUCTs ni c_types del lenguaje DIV2,
//   asi que aqui se declaran: el STRUCT m9 (mismos campos que m8: z, camera, height, angle)
//   y la constante c_m9 = 200.
//   La camara se activa con START_MODE9(id,&m9.z,0).
//   Los sprites se ponen con ctype = c_m9 y coordenadas de MUNDO (x,y,z) + size
//   + graph; el modo 9 los dibuja como billboards escalados por distancia SIN
//   llamar a nada cada frame (igual que c_m7 en el modo 7). c_m9 DEBE valer lo
//   mismo en el PRG y en la DLL (200 por defecto; cambiable con MODE9_CTYPE).
//------------------------------------------------------------------------------
PROGRAM MODE9_DEMO;

IMPORT "MODE9.DLL";

CONST
    SCREEN_X   = 320;     // Ancho de la resolucion de la pantalla
    SCREEN_Y   = 200;     // Alto de la resolucion de la pantalla
    GAME_FPS   = 60;      // FPS objetivo
    ADV_UNIT   = 30;      // velocidad de paso (uds DIV2)
    c_m9       = 200;     // c_type "logico" del modo 9 (convencion, ver cabecera)

GLOBAL
    STRUCT m9            // STRUCT de camara del modo 9 (mismos campos que m8). &m9.z = base del struct.
        z;
        camera;
        height;
        angle;
    END
    scr_x;                // resolucion real (la lee la DLL): raton/camara a
    scr_y;                // cualquier resolucion, no solo 320x200
BEGIN
    // Es probable que los assets tarden en cargar en hardware real.
    // Si te salta la expcion 142, puedes decomentar esta linea para ignorarla.
    //ignore_error(142); 

    set_mode(SCREEN_X * 1000 + SCREEN_Y);
    set_fps(GAME_FPS, 0);

    scr_x = MODE9_SCRW();   // MODE9_SCRW() y MODE9_SCRH() se pueden llamar en cualquier momento, no solo al inicio, por si quieres cambiar la resolucion con set_mode durante el juego.
    scr_y = MODE9_SCRH();

    load_fpg("FPG/MODE9.FPG"); // cargar el FPG del juego

    // --- Cargar el escenario 3D (UNA sola llamada: malla + textura + escala) --
    // LOAD_WLD9(obj, textura, unitscale).  unitscale = 100 uds DIV2 por unidad
    // OBJ. Si la textura no existe (o pones ""), el render cae a flat-shading.
    // La textura de LOAD_WLD9 es el material 0 y se aplica por defecto a todos los materiales.
    // Si cambias 100 por 200, el escenario será el doble de grande.
    // La carga del escenario es bloqueante (hasta que no acabe la acción, no se continúa).
    // Si cargas escenarios enormes, puede saltar al excepcion 142 ("El proceso parece bloqueado, esperando FRAME")
    LOAD_WLD9("OBJ/CASTLE.OBJ", "MAP/CASTLE.MAP", 100);

    // --- MULTIMATERIALES -----------------------------------------------------
    // CASTLE.OBJ tiene 3 materiales por 'usemtl' (en orden): 0=Castle, 1=Stairs,
    // 2=Water. MODE9_MATERIAL(idx, map) asigna una textura a cada uno. El 0 ya lo
    // puso LOAD_WLD9 (CASTLE.MAP); aqui ponemos la escalera y el mar. Si un .MAP
    // no existe aun, ese material cae al 0 (CASTLE.MAP) sin fallar.
    MODE9_MATERIAL(1, "MAP/STAIRS.MAP");   // peldanos de la escalera del patio
    MODE9_MATERIAL(2, "MAP/WATER.MAP");    // agua que rodea la isla

    // MODE9_CULL(1) activa el backface culling (no dibujar las caras que se ven por detras; mas rapido).
    // Por defecto está activado. Si deseseas desactivarlo haz MODE9_CULL(0);
    //MODE9_CULL(0);

    // MODE9_FOV cambia el campo de vision horizontal (FOV) en grados.
    // El valor por defecto es ~71, que es el FOV "canonico" de los juegos 3D de la época
    // Un valor menor (60) hace zoom, y un valor mayor (90 o 110) da un efecto de gran angular.
    // Cambiar el FOV puede afectar la sensacion de velocidad y la distorsion de las texturas, asi que ajustalo a tu gusto.
    //MODE9_FOV(90);

    // MODE9_PERSPECTIVE(1) Corrige gran parte de los defectos gráficos de las texturas, pero impacta mucho en el rendimiento.
    // Por defecto esta desactivado (0), lo que da un efecto de distorsion de las texturas.
    //MODE9_PERSPECTIVE(1);

    // Far clip ("flopping"): no dibujar geometria mas alla de N uds DIV2.
    // Por defecto está a 0 (sin limite).
    // Si activas niebla con SET_FOG9, se auto-activa el FARCLIP con el valor de 'far' de la niebla (lo que queda tras la niebla es del color de fondo, no se dibuja).
    //MODE9_FARCLIP(1000);

    // MODE9_COLLISION activa y desactiva las colisiones: con 1, advance/xadvance NO atraviesan las paredes (la distancia
    // minima a la pared es el campo 'radius' del proceso camara). Con 0 puedes atravesar paredes.
    //MODE9_COLLISION(0);

    // MODE9_STEP(INT X) se usa para subir escaleras y rampas.
    // El valor es la altura max (uds DIV2) que la camara sube sola. Los muros
    // mas bajos NO bloquean (se suben como un peldaño) y la camara se apoya
    // en el suelo que tiene debajo (rampas inclinadas, escalones). 0 = desactivado.
    // La DLL no aplica GRAVEDAD, la gravedad la tienes que gestionar en el PRG (ver el bloque de salto/gravedad de 'camara');
    // Ojo, para que funcione las colisiones deben de estar activadas (no va con MODE9_COLLISION(0)).
    MODE9_STEP(70);

    // --- Ambiente y niebla (color en rango 0..100, convencion DIV2) ----------
    // SET_ENV_COLOR9 fija el color de FONDO y tambien el color de la NIEBLA.
    // 0..100 por canal: 100=blanco, 0=negro. SET_FOG9(near,far) funde hacia ese
    // color crecientemente con la DISTANCIA: transparente hasta 'near' y opaco en
    // 'far' (gradiente suave, como el modo 8). OJO: a diferencia del modo 8
    // (0..100), aqui near/far son DISTANCIAS en uds DIV2; lo normal es far ~ 2*near.
    //SET_ENV_COLOR9(60, 72, 88);        // cielo amarillento, impacta en el color de la niebla
    //SET_FOG9(300, 1400);               // niebla: near=300  far=1400 (uds DIV2)
    
    // Por defecto la niebla no está activada, pero si la activas luego la puedes
    // desactivar con MODE9_FOG_OFF.
    //MODE9_FOG_OFF();

    // --- Cielo panoramico (skybox) -------------------------------------------
    // LOAD_SKY9(map): textura .MAP que envuelve 360 en horizontal; sustituye el
    // color de fondo plano (SET_ENV_COLOR9).
    // Gira con la camara (yaw) y se desplaza con el pitch.
    LOAD_SKY9("MAP/SKY.MAP");

    // --- Procesos ------------------------------------------------------------
    camara();
    write(0, 2, scr_y-9, 0, "WASD+RATON mover  ESPACIO salto  ESC salir");
    write_int(0, 0, 0, 0, OFFSET fps);
END


//------------------------------------------------------------------------------
// Proceso CAMARA: se mueve por el escenario como en el modo 8.
//------------------------------------------------------------------------------
PROCESS camara()
PRIVATE
    mouse_x_prev;
    eye_base;
    fall_v;        // velocidad de caida (la gravedad la integra el PRG)
    grounded;      // 1 si la DLL nos sostiene en un suelo/escalon/rampa
    z_fell;        // z tras aplicar la gravedad, ANTES de que la DLL ajuste
BEGIN
    // Posicion inicial (uds DIV2): x,y = plano del suelo; z = altura
    x = 0;                // frente al porton (el porton esta en z=-1000)
    y = -1500;            // fuera de la muralla, mirando hacia el castillo
    z = 0;
    angle = -90000;       // mirando hacia +Z (hacia el porton)

    // Estado del modo 9
    m9.camera = id;
    m9.height = 160;      // altura del ojo (1.6 uds OBJ; muralla de 4 de alto)
    m9.angle  = 0;        // pitch (0 = horizonte)
    eye_base  = m9.height;
    radius    = 40;       // distancia minima a la pared (para MODE9_COLLISION)

    // START_MODE9(camara, m9, region) -- misma firma que start_mode8.
    //   camara = id del proceso camara.
    //   m9     = &m9.z (la DIRECCION del STRUCT; en modo 8 aqui iria el indice
    //            de m8, pero al ser m9 un struct del PRG hay que pasar su
    //            direccion. &m9.z = base del struct; usa &m9[n].z para un array
    //            de camaras). La DLL lee m9.camera/height/angle de ahi cada
    //            frame (no hace falta MODE9_SET ni MODE9_BIND aparte).
    //   region = 0 (pantalla completa; unica region soportada por la DLL).
    START_MODE9(id, &m9.z, 0);

    //MODE9_DOWNSCALE(2) reduce la resolución del render del modo 9.
    // Es un truco empleado en juegos first person shooter de consolas de 16 bits
    // Cada valor de downscale reduce la resolucion a 1/2, 1/3 o 1/4 (y duplica lineas para llenar la pantalla).
    // 1 = resolucion completa (sin downscale, valor por defecto);
    // 2 = render a la mitad de resolucion (si usas 320x200 -> Se aplica 160x100);
    // 3 = un tercio (si usas 320x200 -> Se aplica 80x50);
    // 4 = un cuarto (si usas 320x200 -> Se aplica 40x25);
    // Acelera mucho el render a costa de una gran perdida de calidad (pixelado, texturas borrosas, mas aliasing). Ajustalo a tu gusto.
    //MODE9_DOWNSCALE(2);

    mouse_x_prev = mouse.x;
    fall_v   = 0;
    grounded = 1;


    load_pal("div2.pal");
    LOOP
        if (key(_esc)) STOP_MODE9(); exit("Bye", 0); end

        // --- Movimiento lateral (strafe) ---
        if (key(_d)) xadvance(angle - 90000, ADV_UNIT); end
        if (key(_a)) xadvance(angle + 90000, ADV_UNIT); end

        // --- Avanzar / retroceder ---
        if (key(_w))
            if (key(_l_shift) or key(_r_shift)) advance(ADV_UNIT*2);
            else advance(ADV_UNIT); end
        end
        if (key(_s)) advance(-ADV_UNIT); end

        // --- Salto y gravedad (LA GRAVEDAD VIVE EN EL PRG) -------------------
        // El PRG integra la gravedad (z baja cada frame). El SUELO -incluidos
        // escalones y rampas- lo pone la DLL TRAS el FRAME: si el jugador se apoya
        // en algo, la DLL le SUBE z (ver MODE9_STEP). Por eso despues del FRAME
        // comprobamos si z subio respecto a lo que dejo la gravedad: si subio y
        // estabamos cayendo, es que tocamos suelo (grounded) y paramos la caida.
        if (key(_space) and grounded)
            fall_v   = -60;        // impulso de salto (negativo = hacia arriba)
            grounded = 0;
        end
        fall_v = fall_v + 6;                              // gravedad (subida)
        if (fall_v > 0) fall_v = fall_v + 8; end         // caida mas rapida (game feel)
        z = z - fall_v;            // caer (o subir, si fall_v<0 por el salto)
        if (z < 0) z = 0; end       // suelo de seguridad en y=0 (por si no hay malla)
        z_fell = z;                // z tras la gravedad, antes de que la DLL ajuste

        // --- Agacharse ---
        if (key(_control)) m9.height = eye_base * 2 / 3;
        else m9.height = eye_base; end

        // --- Raton: giro horizontal y pitch vertical (adaptado a la resolucion) -
        // Yaw: sensibilidad ~constante en cualquier modo (256000/scr_x = 800 @320).
        angle = angle - (mouse.x - mouse_x_prev) * 256000 / scr_x;
        // Pitch: mapeo ABSOLUTO de mouse.y. Centro = scr_y/2 (horizonte real);
        // factor 120000/scr_y para que toda la altura cubra +-60000 (=600 @200).
        m9.angle = (scr_y/2 - mouse.y) * 120000 / scr_y;
        if (m9.angle >  60000) m9.angle =  60000; end
        if (m9.angle < -60000) m9.angle = -60000; end

        if (mouse.x <= 0 or mouse.x >= scr_x-1) mouse.x = scr_x/2; end
        mouse_x_prev = mouse.x;

        FRAME;

        // Tras el FRAME la DLL ya pudo SUBIR z (escalon/rampa/apoyo en el suelo).
        // Si z quedo por encima de lo que dejo la gravedad y veniamos cayendo,
        // hemos tocado suelo: marcamos grounded y anulamos la velocidad de caida.
        if (z > z_fell - 1 and fall_v > 0)
            grounded = 1;
            fall_v   = 0;
        else
            grounded = 0;
        end
    END
END

Y aquí os dejo el ejemplo en movimiento:

MODE9_02.PRG · Lo poblamos con billboards

Idéntico al anterior, pero ahora metemos sprites al estilo modo 7. Y es de lo más cómodo: basta con darle a un proceso `ctype = c_m9` y sus coordenadas de mundo en `x, y, z`, y el Modo 9 lo dibuja solo cada frame, escalado por la distancia, sin que llamemos a nada. Coloco varios árboles y un cartel (billboards planos de una cara) y un NPC con gráficos angulares (`xgraph`): una tabla de 8 dibujos repartidos en 360º, de forma que la DLL elige el frame correcto según desde qué ángulo lo mira la cámara, igual que el `xgraph` del modo 7. El z-buffer se encarga de ocultarlos cuando una pared se interpone.

En verde el código añadido y con "(...)" las líneas omitidas por ser idénticas al ejemplo anterior:

PROGRAM MODE9_DEMO;

IMPORT "MODE9.DLL";

CONST
(...)GLOBAL
(...) 
BEGIN
(...)
    // --- Procesos ------------------------------------------------------------
    camara();
    NPC(0, 600, 0);          // un sprite angular "modo 7" en el patio del castillo, representa un NPC
    M9TREE(600, -1300, 0);   // un sprite plano, representa un arbol
    M9TREE(-600, -1300, 0);  // un sprite plano, representa un arbol
    M9TREE(1000, -1600, 0);  // un sprite plano, representa un arbol
    M9TREE(-1000, -1600, 0); // un sprite plano, representa un arbol
    M9SIGN(300, -1200, 0);   // un cartel plano con textura

    write(0, 2, scr_y-9, 0, "WASD+RATON mover  ESPACIO salto  ESC salir");
    write_int(0, 0, 0, 0, OFFSET fps);
END
(...)//------------------------------------------------------------------------------
// Procesos de SPRITE billboard (estilo modo 7): basta con ponerle ctype = c_m9 y
// sus coordenadas de MUNDO (x,y = suelo, z = altura), graph y size. El modo 9
// lo dibuja automaticamente como sprite 2D escalado segun la distancia, SIN
// llamar a nada cada frame (igual que un proceso c_m7 en el modo 7).
//   - x, y : posicion en el plano del suelo (uds DIV2)
//   - z    : altura (uds DIV2)
//   - size : escala base en % (la distancia la aplica el modo 9 encima)
//
// OCLUSION: el modo 9 oculta el sprite si queda tapado por la geometria (test
// de z-buffer). Se puede desactivar con MODE9_OCCLUDE(0).
//------------------------------------------------------------------------------
PROCESS NPC(wx, wy, wz)
PRIVATE
    npc_gr[] = 8, 8,1,2,3,4,5,6,7;   // N=8 graficos en 360º

BEGIN
    ctype = c_m9;         // <-- el modo 9 lo pinta como billboard automaticamente
    //graph = 8;          // grafico de MODE9.FPG, billboard plano (1 cara)
    xgraph = &npc_gr[0];  // grafico de MODE9.FPG, billboard con multiples caras, en funcion del angulo de vision
    size  = 100;          // escala base (%); el modo 9 la modula por distancia
    angle = 0;
    x = wx; y = wy; z = wz;   // posicion en el MUNDO (el proceso la conserva)
    LOOP
        FRAME;
    END
END

PROCESS M9TREE(wx, wy, wz)
BEGIN
    ctype = c_m9;         // <-- el modo 9 lo pinta como billboard automaticamente
    graph = 9;          // grafico de MODE9.FPG, billboard plano (1 cara)
    size  = 100;          // escala base (%); el modo 9 la modula por distancia
    angle = 0;
    x = wx; y = wy; z = wz;   // posicion en el MUNDO (el proceso la conserva)
    LOOP
        FRAME;
    END
END

PROCESS M9SIGN(wx, wy, wz)
BEGIN
    ctype = c_m9;         // <-- el modo 9 lo pinta como billboard automaticamente
    graph = 10;          // grafico de MODE9.FPG, billboard plano (1 cara)
    size  = 100;          // escala base (%); el modo 9 la modula por distancia
    angle = 0;
    x = wx; y = wy; z = wz;   // posicion en el MUNDO (el proceso la conserva)
    LOOP
        FRAME;
    END
END

Y aquí lo tenéis en movimiento:

Por cierto, el NPC que véis es un render de un personaje que modelé en Blender en octubre del año pasado (aquí lo podéis ver en verdadero 3D: https://sketchfab.com/3d-models/nazuna-from-backstabbed-in-a-backwater-dungeon-855b836348714abaa321d4638f2358db). Y bueno, sobra decir que los árboles y la señal también los modelé yo mismo, en este caso para un proyecto abandonado que tenía el nombre en código "La Aventura de Greta: Eboke Debe Dimitir" y del que había ya preparado un boceto para su pantalla de "pulsa start":

MODE9_03.PRG · Metemos un objeto 3D de verdad en nuestro escenario 3D de verdad

Cuando un billboard plano no basta —queremos rodear al bicho y verlo por todos lados— y los billboards con sprites por ángulos se nos queda corto, toca meter un modelo 3D. Aquí cargo una gata humanoide con `LOAD_OBJ9("OBJ/CAT.OBJ", "MAP/CAT.MAP", 50)`, que devuelve un handle, y lo dibujo cada frame con `DRAW_OBJ9()` en la entrada del castillo.

Un detalle importante: los modelos se cargan en segundo plano (mientras jugamos), así que `LOAD_OBJ9` devuelve el handle al instante, pero el gato simplemente "aparece" cuando termina de cargar. A más polígonos, materiales o animaciones, más tardará en cargar. No obstante, he implementado una función de `MODE9_OBJ9_READY() que nos permite consultar si el objeto ligado al manejador ha acabado de cargar, lo cual permite, por ejemplo, la creación de pantallas de carga.

Al igual que antes, en verde dejo el código añadido y con "(...)" las líneas omitidas por ser idénticas al ejemplo anterior:

PROGRAM MODE9_DEMO;

IMPORT "MODE9.DLL";

CONST
(...)GLOBAL
 (...)
   cat_h;                // handle del modelo 3D del gato (LOAD_OBJ9)
BEGIN
(...)    // --- Cielo panoramico (skybox) -------------------------------------------
    // LOAD_SKY9(map): textura .MAP que envuelve 360 en horizontal; sustituye el
    // color de fondo plano (SET_ENV_COLOR9).
    // Gira con la camara (yaw) y se desplaza con el pitch.
    LOAD_SKY9("MAP/SKY.MAP");

    // --- NPC 3D estatico (objeto OBJ texturado en el mundo) ------------------
    // LOAD_OBJ9(obj, textura, unitscale) carga UN modelo 3D estatico: la malla
    // CAT.OBJ con su textura CAT.MAP, escala 50 (uds DIV2 por unidad OBJ). Ocupa
    // un slot de los 8 de la DLL. El gato se vera quieto (sin animacion); para
    // animarlo por vertex morphing se usaria LOAD_OBJ9_ANIM + DRAW_OBJ9_ANIM.
    cat_h = LOAD_OBJ9("OBJ/CAT.OBJ", "MAP/CAT.MAP", 50);
    /*
    // Los modelos se cargan en segundo plano, mientras se ejecuta el juego
    // No obstante, con MODE9_OBJ9_READY puedes consultar si el modelo ha
    // acabado de cargarse en memoria (1 = listo, 0 = aun cargando).
    // Puede servir, por ejemplo, para hacer pantallas de carga
    // Esto es opcional, puedes llamar a DRAW_OBJ9 o DRAW_OBJ9_ANIM con un handle aun no cargado (0) y simplemente no dibuja nada en ese FRAME.
    // Pero ten en cuenta que, mientras el modelo se carga, el juego se ralentiza
    write(0, SCREEN_X/2, SCREEN_Y/2, 4, "Cargando modelo 3D...");
    while(MODE9_OBJ9_READY(cat_h) == 0)
        FRAME;
    END;
    delete_text(ALL_TEXT);*/

    // --- Procesos ------------------------------------------------------------
    camara();
    NPC3D(cat_h, 400, -1300, 0);
    NPC(0, 600, 0);          // un sprite angular "modo 7" en el patio del castillo, representa un NPC
    M9TREE(600, -1300, 0);   // un sprite plano, representa un arbol
    M9TREE(-600, -1300, 0);  // un sprite plano, representa un arbol
    M9TREE(1000, -1600, 0);  // un sprite plano, representa un arbol
    M9TREE(-1000, -1600, 0); // un sprite plano, representa un arbol
    M9SIGN(300, -1200, 0);   // un cartel plano con textura

    write(0, 2, scr_y-9, 0, "WASD+RATON mover  ESPACIO salto  ESC salir");
    write_int(0, 0, 0, 0, OFFSET fps);
END
(...)//------------------------------------------------------------------------------
// NPC3D: objeto 3D texturado en el mundo. Usa DRAW_OBJ9 cada frame para que la
// DLL lo renderice como malla 3D (con z-buffer respecto al escenario).
//   handle : devuelto por LOAD_OBJ9 (0 = modelo no cargado -> no dibuja nada)
//   wx, wy : posicion inicial en el plano del suelo (uds DIV2)
//   wz     : altura inicial (uds DIV2; 0 = al nivel del suelo)
//
// El proceso mantiene sus coordenadas (x,y,z,angle) como cualquier proceso DIV2:
// puedes moverlo con advance(), cambiar angle, etc. en subclases.
// DRAW_OBJ9(handle, x, y, z, angle) se llama antes de cada FRAME y dibuja el
// modelo estatico (sin animacion: el gato se queda quieto).
//------------------------------------------------------------------------------
PROCESS NPC3D(handle, wx, wy, wz)
BEGIN
    x = wx; y = wy; z = wz;
    angle = pi;    
    LOOP
        if (handle > 0)
            DRAW_OBJ9(handle, x, y, z, angle);
        end
        FRAME;
    END
END

Y aquí lo tenéis en movimiento:

Sobre la gata humanoide, se trata de una revisión lowpoly (menos de 400 polígonos) de un modelo que hice en Blender en 2021 basándome en el rediseño de Ankha que le hizo Zero Zone (aquí podéis consultar la versión original que hice entonces: https://sketchfab.com/3d-models/ankha-zone-version-37819f223f26467e8b3247e83b507805). Si véis que el modelo lowpoly no se parece mucho al que hice hace 5 años, es lógico... Pensad que he comprimido más de 130.000 triángulos en apenas unos 400.

MODE9_04.PRG · Y ahora, que el objeto esté animado

El mismo personaje, pero vivo. No es que esté bailando o corriendo, pero le he puesto una pequeña animación de "idle" (espera/estar quieto). Para ello, en lugar de `LOAD_OBJ9` uso `LOAD_OBJ9_ANIM("OBJ/CAT", ...)`, que carga una secuencia de poses numeradas (`CAT0.OBJ` … `CAT9.OBJ`), y lo pinto con `DRAW_OBJ9_ANIM()` pasándole un parámetro extra, `fpos`, que indica en qué punto de la animación está.

Mi Modo 9 interpola las poses intermedias por nosotros, así que con 10 fotogramas el ciclo de "respiración" del gato queda suave y para ello ligo el `fpos` al `timer` para que la animación corra a la misma velocidad independientemente de los FPS a los que vaya el juego. En otras palabras, los vértices no se teletransportan del punto A al punto B, si no que hacen un recorrido. Esto lo hago porque en hardware modesto es poco realista hacer animaciones grandes de 180 posiciones, por poner un ejemplo... Al igual que en las animaciones de Blender, si capturas la posición de los vértices en el momento 0 y otra vez en el momento 50, con esta librería se recalculan las posiciones entre 1 y 49, para que la animación luzca fluída, sin que le tengas que especificar en cada frame cual es la posición exacta de los vértices.

Otra cosa a aclarar es que, como los OBJ no tienen soporte nativo para animaciones, los OBJ de CAT1, CAT2, CAT3, CAT4 son idénticos (mismos vértices, UV, materiales, etc), pero con posiciones cambiadas. Esto, si tienes maña con Blender, no es complicado de implementar e incluso te ayuda a exportar las animaciones para funcionar de esta forma.

Tened en cuenta también de que si pensáis usar animaciones 3D, resultaría recomendable que hagáis uso de MODE9_OBJ9_READY() para implementar una pantalla de carga, puesto que, a pesar de que los objetos se cargan en segundo plano, pueden causar ralentizaciones (pensad que una animación 3D de 10 frames es como cargar en memoria 10 objetos 3D, uno tras otro).

Al igual que antes, en verde dejo el código modificado y con "(...)" las líneas omitidas por ser idénticas al ejemplo anterior:

PROGRAM MODE9_DEMO;

IMPORT "MODE9.DLL";

CONST
(...)
    c_m9       = 200;     // c_type "logico" del modo 9 (convencion, ver cabecera)
    CAT_FRAMES = 10;      // fotogramas del idle del gato (CAT0.OBJ..CAT9.OBJ)
    CAT_LOOP   = 300;     // duracion del bucle en centisegundos (300 = 3 s, ver timer)

GLOBAL
(...)
BEGIN
(...)    // --- NPC 3D animado (objeto OBJ texturado en el mundo) -------------------
    // LOAD_OBJ9_ANIM carga una animacion por vertex morphing: los fotogramas son
    // OBJ/CAT0.OBJ..OBJ/CAT9.OBJ (misma topologia, solo cambian las posiciones) con una
    // unica textura CAT.MAP compartida. Ocupa UN SOLO slot de los 8 de la DLL,
    // independientemente del numero de fotogramas. La carga se separa de NPC3D y
    // se llama con FRAME entre medias para refrescar antes de que arranquen los
    // procesos (y porque parsear 10 OBJ tarda varios segundos en disco real).
    cat_h = LOAD_OBJ9_ANIM("OBJ/CAT", "MAP/CAT.MAP", 50, CAT_FRAMES);
    /*
    // Los modelos se cargan en segundo plano, mientras se ejecuta el juego
    // No obstante, con MODE9_OBJ9_READY puedes consultar si el modelo ha
    // acabado de cargarse en memoria (1 = listo, 0 = aun cargando).
    // Puede servir, por ejemplo, para hacer pantallas de carga
    // Esto es opcional, puedes llamar a DRAW_OBJ9 o DRAW_OBJ9_ANIM con un handle aun no cargado (0) y simplemente no dibuja nada en ese FRAME.
    // Pero ten en cuenta que, mientras el modelo se carga, el juego se ralentiza
    write(0, SCREEN_X/2, SCREEN_Y/2, 4, "Cargando modelo 3D...");
    while(MODE9_OBJ9_READY(cat_h) == 0)
        FRAME;
    END;
    delete_text(ALL_TEXT);*/

    // --- Procesos ------------------------------------------------------------
    camara();
    NPC3D(cat_h, 400, -1300, 0);
    NPC(0, 600, 0);          // un sprite angular "modo 7" en el patio del castillo, representa un NPC
    M9TREE(600, -1300, 0);   // un sprite plano, representa un arbol
    M9TREE(-600, -1300, 0);  // un sprite plano, representa un arbol
    M9TREE(1000, -1600, 0);  // un sprite plano, representa un arbol
    M9TREE(-1000, -1600, 0); // un sprite plano, representa un arbol
    M9SIGN(300, -1200, 0);   // un cartel plano con textura

    write(0, 2, scr_y-9, 0, "WASD+RATON mover  ESPACIO salto  ESC salir");
    write_int(0, 0, 0, 0, OFFSET fps);
END
(...)//------------------------------------------------------------------------------
// NPC3D: objeto 3D texturado en el mundo. Usa DRAW_OBJ9 cada frame para que la
// DLL lo renderice como malla 3D (con z-buffer respecto al escenario).
//   handle : devuelto por LOAD_OBJ9 (0 = modelo no cargado -> no dibuja nada)
//   wx, wy : posicion inicial en el plano del suelo (uds DIV2)
//   wz     : altura inicial (uds DIV2; 0 = al nivel del suelo)
//
// El proceso mantiene sus coordenadas (x,y,z,angle) como cualquier proceso DIV2:
// puedes moverlo con advance(), cambiar angle, etc. en subclases.
// DRAW_OBJ9_ANIM(handle, x, y, z, angle, fpos) se llama antes de cada FRAME.
// 'fpos' es la posicion de la animacion en 1/256 de fotograma; aqui se deriva de
// timer[0] (centisegundos) para un bucle continuo de CAT_LOOP cs = 3 s. Para un
// modelo cargado con LOAD_OBJ9 (estatico) DRAW_OBJ9_ANIM tambien vale: la DLL ve
// nframes=1 y dibuja siempre el frame 0, ignorando fpos.
//------------------------------------------------------------------------------
PROCESS NPC3D(handle, wx, wy, wz)
PRIVATE
    fpos;
BEGIN
    x = wx; y = wy; z = wz;
    angle = pi;
    LOOP
        if (handle > 0)
            // bucle de CAT_LOOP cs -> 0..CAT_FRAMES*256; la DLL interpola entre
            // keyframes (idle suave) y hace bucle al volver al frame 0.
            fpos = (timer[0] % CAT_LOOP) * (CAT_FRAMES * 256) / CAT_LOOP;
            DRAW_OBJ9_ANIM(handle, x, y, z, angle, fpos);
        end
        FRAME;
    END
END

Y éste es el resultado en movimiento:

MODE9_05.PRG · De un mapa a otro: el castillo por dentro

Aquí es donde se pone serio. Este ejemplo es ya casi un pequeño juego: tiene pantalla de inicio ("Pulsa una tecla"), una pantall de salida con menú Sí/No, y sobre todo, un cambio de escenario al cruzar una puerta. La clave es que `LOAD_WLD9()` recarga el mundo en caliente, sin parar el Modo 9 ni perder la cámara: detecto que el jugador está sobre la puerta (distancia al cuadrado por debajo de un radio), hago un *fade* a negro para disimular, descargo los props del patio con `signal(..., s_kill)`, cargo el interior (`CASTIN.OBJ`), apago el cielo con `SKY9_OFF()`, bajo la luz ambiente con `SET_ENV_COLOR9()` y recoloco al jugador.

Dentro hay un NPC (básciamente he mudado a Nazuna aquí) sobre un estrado, un trono, lámparas colgando y antorchas en las paredes, y un bocadillo de diálogo que sigue al personaje en pantalla usando `MODE9_PROJECT()` para proyectar la posición de su cabeza a coordenadas 2D. Y también hay un guiño a cierto consejo sobre lo peligroso que es andar solo.

Como siempre, en verde dejo el código modificado y con "(...)" las líneas omitidas por ser idénticas al ejemplo anterior:

PROGRAM MODE9_05_DEMO;

IMPORT "MODE9.DLL";

CONST
    SCREEN_X   = 320;     // Ancho de la resolucion de la pantalla
    SCREEN_Y   = 200;     // Alto de la resolucion de la pantalla
    GAME_FPS   = 60;      // FPS objetivo
    ADV_UNIT   = 30;      // velocidad de paso (uds DIV2)
    c_m9       = 200;     // c_type "logico" del modo 9 (convencion, ver cabecera)

    MAP_OUT  = 0;          // exterior (patio)
    MAP_IN   = 1;          // interior (sala)
    SWAP_CD  = 40;         // frames de cooldown tras un cambio de mapa

    // Puerta del torreon (exterior): OBJ z=-4 -> mundo y=-400.
    DOOR_X = 0;   DOOR_Y = -400;   DOOR_R2 = 20000;   // radio de disparo ~141
    // Puerta de salida (interior): OBJ z=-6 -> mundo y=-600.
    EXIT_X = 0;   EXIT_Y = -600;   EXIT_R2 = 22500;   // radio de disparo ~150
    // NPC dentro de la sala (mismo sitio que NPC(0,500,50)): globo de dialogo al acercarse.
    NPC_X = 0;    NPC_Y = 500;     BUBBLE_R2 = 160000;   // radio del globo ~400
    NPC_HEAD = 220;       // punto (mundo) a la altura de la CABEZA: ancla del bocadillo y destino del rabito
    NPC_TOP  = 320;       // punto (mundo) SOBRE la cabeza: ahi va el nombre
    BUB_HW = 78;          // semiancho del bocadillo lateral (1 linea de frase)
    BUB_HH = 12;          // semialto del bocadillo
    BUB_GAP = 12;         // separacion entre el NPC y el bocadillo

GLOBAL
    STRUCT m9            // STRUCT de camara del modo 9 (mismos campos que m8). &m9.z = base del struct.
        z;
        camera;
        height;
        angle;
    END
    scr_x;                // resolucion real (la lee la DLL): raton/camara a
    scr_y;                // cualquier resolucion, no solo 320x200
    map_state;            // MAP_OUT / MAP_IN (se muestra como 1 digito arriba-izda)

BEGIN
(...)    LOAD_FPG("FPG/MODE9.FPG");
    MODE9_LOADFPG("FPG/MODE9.FPG");

    MODE9_STEP(70);

    map_state = MAP_OUT;
    camara();           // muestra la pantalla de inicio, carga el 3D y juega
END


//------------------------------------------------------------------------------
// CAMARA: movimiento (igual que MODE9_04) + INTERCAMBIO DE MAPAS (todo inline).
//------------------------------------------------------------------------------
PROCESS camara()
PRIVATE
    mouse_x_prev;
    eye_base;
    fall_v;        // velocidad de caida (la gravedad la integra el PRG)
    grounded;      // 1 si la DLL nos sostiene en un suelo/escalon/rampa
    z_fell;        // z tras aplicar la gravedad, ANTES de que la DLL ajuste
    cooldown;          // frames restantes sin poder disparar puertas
    dx; dy; d2;
    bub_on;            // 1 = globo de dialogo del NPC visible
    bub_fill; bub_brd; bub_tail;   // bocadillo: elipse rellena, borde, rabito
    bub_spk;           // texto de la frase (dentro del bocadillo)
    name_plate; name_txt;          // placa + nombre, encima del NPC
    bd2;               // distancia (al cuadrado) de la camara al NPC
    show;              // 1 = se cumplen las condiciones para ver el globo
    nsx; nsy; nsz;     // proyeccion de la CABEZA del NPC (MODE9_PROJECT)
    tsx; tsy;          // proyeccion del punto SOBRE la cabeza (nombre)
    cx; cy; tx;        // centro del bocadillo y x del rabito en su borde
    pk;                // id del texto "Pulsa una tecla" (parpadeo)
    i; detected;       // sondeo de teclas en la pantalla de inicio
    sel; ed_cur;       // dialogo de salida: opcion elegida (1=Si,0=No) y cursor
BEGIN

    // =================== PANTALLA DE INICIO (pulsa una tecla) ===============
    // Aun no se ha cargado el mundo 3D: es una pantalla 2D normal.
    draw(3,  0, 3, 0,  18, 36, scr_x-18, scr_y-36);         // fondo oscuro
    draw(2, 15, 15, 0, 18, 36, scr_x-18, scr_y-36);         // marco
    write(0, scr_x/2, 56, 4, "EL CASTILLO 3D");
    write(0, scr_x/2, 74, 4, "( Modo 9 - DIV2 )");
    pk = 0;
    detected = 0;

    // Fondo del titulo (graph 14 = TITLEM9.PCX, 320x200).
    put_screen(0, 14);
    frame;
    // Esperar a que se pulse cualquier tecla. Se sondea key() de todos los
    // scancodes (estado real "pulsada"), porque scan_code aqui es un pulso de
    // 1 frame y se pierde si el sondeo no cae justo en ese frame.
    repeat
        if ((timer[0]/40) % 2 == 0)
            if (pk == 0)
                pk = write(0, scr_x/2, 138, 4, "Pulsa una tecla");
            end
        else
            if (pk <> 0)
                delete_text(pk);
                pk = 0;
            end
        end
        FRAME;
    until(scan_code == 0);
    // Esperar a soltar todas las teclas antes de empezar.
    repeat
        FRAME;
    until (scan_code != 0);
    delete_text(all_text);
    delete_draw(all_drawing);
    clear_screen();
    FRAME;
    // ---------------- CARGA INICIAL: EXTERIOR ----------------
    LOAD_WLD9("OBJ/CASTLE.OBJ", "MAP/CASTLE.MAP", 100);
    MODE9_MATERIAL(1, "MAP/STAIRS.MAP");
    MODE9_MATERIAL(2, "MAP/WATER.MAP");
    LOAD_SKY9("MAP/SKY.MAP");

    M9TREE(600, -1300, 0);          // props del patio (el NPC vive DENTRO, no aqui)
    M9TREE(-600, -1300, 0);
    M9TREE(1000, -1600, 0);
    M9TREE(-1000, -1600, 0);
    M9SIGN(300, -1200, 0);

        // Posicion inicial (uds DIV2): x,y = plano del suelo; z = altura
    x = 0;                // frente al porton (el porton esta en z=-1000)
    y = -1500;            // fuera de la muralla, mirando hacia el castillo
    z = 0;
    angle = -90000;       // mirando hacia +Z (hacia el porton)

(...)    mouse_x_prev = mouse.x;
    fall_v   = 0;
    grounded = 1;
    bub_on   = 0;

    // HUD del juego (se crea aqui, ya pasada la pantalla de inicio).
    write(0, scr_x/2, scr_y-9, 4, "WASD+RATON  ESPACIO salto  ESC salir");
    write_int(0, 2, 2, 0, OFFSET fps);

    LOOP
        // --- ESC: dialogo 2D de confirmacion "Deseas salir? Si/No" ---------
        if (key(_esc))
            STOP_MODE9();                       // pausa el render 3D
            put_screen(0, 15);

            while (key(_esc)) FRAME; end        // soltar ESC
            delete_text(all_text);              // limpiar HUD/bocadillo
            delete_draw(all_drawing);
            bub_on = 0;
            sel = 0;                            // 0 = No (por defecto), 1 = Si
            draw(3,  0,  3, 0, 40, 68, scr_x-40, 132);             // fondo oscuro
            draw(2, 15, 15, 0, 40, 68, scr_x-40, 132);             // marco del panel
            write(0, scr_x/2, 84, 4, "Deseas salir?");
            write(0, scr_x/2-34, 112, 4, "Si");
            write(0, scr_x/2+34, 112, 4, "No");
            ed_cur = draw(2, 14, 15, 0, scr_x/2+18, 104, scr_x/2+50, 122);  // cursor en "No"
            repeat
                if (key(_left))  sel = 1; end
                if (key(_right)) sel = 0; end
                if (sel == 1) move_draw(ed_cur, 14, 15, scr_x/2-50, 104, scr_x/2-18, 122);
                else          move_draw(ed_cur, 14, 15, scr_x/2+18, 104, scr_x/2+50, 122); end
                FRAME;
            until (key(_enter))
            if (sel == 1) STOP_MODE9(); exit("Bye", 0); end
            // "No": limpiar dialogo, recrear HUD y reanudar el juego 3D.
            delete_text(all_text);
            delete_draw(all_drawing);
            clear_screen();
            write(0, scr_x/2, scr_y-9, 4, "WASD+RATON  ESPACIO salto  ESC salir");
            write_int(0, 2, 2, 0, OFFSET fps);
            START_MODE9(id, &m9.z, 0);
            while (key(_enter)) FRAME; end       // soltar intro
            mouse_x_prev = mouse.x;       // evitar tiron de camara al reanudar
        end

        // --- Movimiento lateral (strafe) ---
        if (key(_d)) xadvance(angle - 90000, ADV_UNIT); end
        if (key(_a)) xadvance(angle + 90000, ADV_UNIT); end

(...)        if (mouse.x <= 0 or mouse.x >= scr_x-1) mouse.x = scr_x/2; end
        mouse_x_prev = mouse.x;

        // ===================== INTERCAMBIO DE MAPAS (INLINE) =================
        if (cooldown > 0)
            cooldown = cooldown - 1;
        else
            if (map_state == MAP_OUT)
                // Pegados a la puerta del torreon? -> ENTRAR
                dx = x - DOOR_X;  dy = y - DOOR_Y;  d2 = dx*dx + dy*dy;
                if (d2 < DOOR_R2)
                    fade_off();
                    frame;
                    fade_on();
                    frame;
                    signal(type M9TREE, s_kill);     // descargar props del patio
                    signal(type M9SIGN, s_kill);
                    // Recarga en caliente: el modo 9 sigue ACTIVO y la camara
                    // enlazada (id + &m9.z) persiste; LOAD_WLD9 solo cambia la malla.
                    LOAD_WLD9("OBJ/CASTIN.OBJ", "MAP/CASTIN_T.MAP", 100);  // 1 material (0)
                    SKY9_OFF();
                    SET_ENV_COLOR9(8, 8, 12);
                    NPC(0, 500, 50);                 // el NPC, ahora dentro (sobre el estrado)
                    THRONE(0, 575, 50);              // trono detras del NPC, en el estrado
                    LAMP(0, 300,  500);                 // lampara colgando del techo
                    LAMP(0, -150, 500);                 // lampara colgando del techo
                    TORCH( 470,  300, 250);          // 4 antorchas en las paredes
                    TORCH( 470, -100, 250);
                    TORCH(-470,  300, 250);
                    TORCH(-470, -100, 250);
                    x = 0;  y = -300;  z = 0;  angle = -90000;
                    m9.height = eye_base;  m9.angle = 0;
                    fall_v = 0;  grounded = 1;
                    map_state = MAP_IN;
                    cooldown  = SWAP_CD;
                end
            else
                // Pegados a la puerta de salida? -> SALIR
                dx = x - EXIT_X;  dy = y - EXIT_Y;  d2 = dx*dx + dy*dy;
                if (d2 < EXIT_R2)
                    fade_off();
                    frame;
                    fade_on();
                    frame;
                    signal(type NPC, s_kill);        // descargar NPC y props de la sala
                    signal(type THRONE, s_kill);
                    signal(type LAMP, s_kill);
                    signal(type TORCH, s_kill);
                    LOAD_WLD9("OBJ/CASTLE.OBJ", "MAP/CASTLE.MAP", 100);
                    MODE9_MATERIAL(1, "MAP/STAIRS.MAP");
                    MODE9_MATERIAL(2, "MAP/WATER.MAP");
                    LOAD_SKY9("MAP/SKY.MAP");
                    M9TREE(600, -1300, 0);
                    M9TREE(-600, -1300, 0);
                    M9TREE(1000, -1600, 0);
                    M9TREE(-1000, -1600, 0);
                    M9SIGN(300, -1200, 0);
                    x = 0;  y = -650;  z = 0;  angle = 90000;
                    m9.height = eye_base;  m9.angle = 0;
                    fall_v = 0;  grounded = 1;
                    map_state = MAP_OUT;
                    cooldown  = SWAP_CD;
                end
            end
        end

        // ===================== NOMBRE + BOCADILLO (estilo comic) ============
        // Se muestra SOLO si: estamos en la sala, CERCA del NPC y MIRANDOLO
        // (MODE9_PROJECT devuelve 1 = delante de la camara, y su x cae en pantalla).
        //   - El NOMBRE ("Nazuma") va ENCIMA del NPC (sobre su cabeza), sin tapar
        //     la cara, con una placa semitransparente para leerse.
        //   - El BOCADILLO con la frase va a un LADO del NPC; elige IZDA o DCHA
        //     segun donde haya mas sitio (si el NPC esta en la mitad izquierda de
        //     la pantalla, el bocadillo va a la derecha, y viceversa). El RABITO
        //     sale del lado del bocadillo que mira al NPC.
        // Ambos SIGUEN al NPC (se reposicionan con move_draw/move_text cada frame).
        show = 0;
        if (map_state == MAP_IN)
            bd2 = (x - NPC_X)*(x - NPC_X) + (y - NPC_Y)*(y - NPC_Y);
            if (bd2 < BUBBLE_R2)
                if (MODE9_PROJECT(NPC_X, NPC_Y, NPC_HEAD, OFFSET nsx, OFFSET nsy, OFFSET nsz))
                    if (nsx >= 0 and nsx < scr_x)   // el NPC esta en pantalla -> lo miramos
                        show = 1;
                    end
                end
            end
        end

        if (show)
            // Punto sobre la cabeza para el nombre (si no proyecta, usa la cabeza).
            if (MODE9_PROJECT(NPC_X, NPC_Y, NPC_TOP, OFFSET tsx, OFFSET tsy, OFFSET nsz) == 0)
                tsx = nsx;  tsy = nsy - 20;
            end
            if (tsy < 8) tsy = 8; end       // que el nombre no se salga por arriba

            // Lado del bocadillo segun el espacio disponible en pantalla.
            if (nsx < scr_x/2) cx = nsx + BUB_GAP + BUB_HW;   // NPC a la izda -> bocadillo a la DCHA
            else               cx = nsx - BUB_GAP - BUB_HW;   // NPC a la dcha -> bocadillo a la IZDA
            end
            if (cx < BUB_HW)         cx = BUB_HW;          end   // recortar para no salirse
            if (cx > scr_x - BUB_HW) cx = scr_x - BUB_HW;  end
            cy = nsy;                                            // a la altura de la cabeza
            if (cy < BUB_HH + 2)            cy = BUB_HH + 2;            end
            if (cy > scr_y - BUB_HH - 12)   cy = scr_y - BUB_HH - 12;   end
            // Borde del bocadillo que mira al NPC (de ahi sale el rabito).
            if (cx > nsx) tx = cx - BUB_HW;   else tx = cx + BUB_HW;   end

            if (bub_on == 0)
                // draw(tipo, color, opacidad 0..15, region, x0,y0, x1,y1)
                bub_fill   = draw(5,  0,  7, 0, cx-BUB_HW, cy-BUB_HH, cx+BUB_HW, cy+BUB_HH); // elipse rellena semitransp.
                bub_brd    = draw(4, 15, 15, 0, cx-BUB_HW, cy-BUB_HH, cx+BUB_HW, cy+BUB_HH); // borde de la elipse
                bub_tail   = draw(1, 15, 15, 0, tx, cy, nsx, nsy);                           // rabito hacia el NPC
                bub_spk    = write(0, cx, cy, 4, "Es peligroso andar solo");
                name_plate = draw(3,  0,  7, 0, tsx-24, tsy-7, tsx+24, tsy+7);               // placa del nombre
                name_txt   = write(0, tsx, tsy, 4, "Nazuma");                                // nombre encima del NPC
                bub_on     = 1;
            else
                // ya existe: solo reposicionar para seguir al NPC
                move_draw(bub_fill, 0,  7, cx-BUB_HW, cy-BUB_HH, cx+BUB_HW, cy+BUB_HH);
                move_draw(bub_brd, 15, 15, cx-BUB_HW, cy-BUB_HH, cx+BUB_HW, cy+BUB_HH);
                move_draw(bub_tail,15, 15, tx, cy, nsx, nsy);
                move_text(bub_spk, cx, cy);
                move_draw(name_plate, 0, 7, tsx-24, tsy-7, tsx+24, tsy+7);
                move_text(name_txt, tsx, tsy);
            end
        else
            if (bub_on == 1)
                delete_draw(bub_fill);
                delete_draw(bub_brd);
                delete_draw(bub_tail);
                delete_draw(name_plate);
                delete_text(bub_spk);
                delete_text(name_txt);
                bub_on = 0;
            end
        end

        FRAME;

        // Tras el FRAME la DLL ya pudo SUBIR z (escalon/rampa/apoyo en el suelo).
        // Si z quedo por encima de lo que dejo la gravedad y veniamos cayendo,
        // hemos tocado suelo: marcamos grounded y anulamos la velocidad de caida.
        if (z > z_fell - 1 and fall_v > 0)
            grounded = 1;
            fall_v   = 0;
        else
            grounded = 0;
        end
    END
END

//------------------------------------------------------------------------------
// SPRITES billboard (estilo modo 7): ctype = c_m9 + coords de MUNDO + graph/size.
// Se destruyen con signal(type ..., s_kill) al cambiar de mapa.
//------------------------------------------------------------------------------
PROCESS NPC(wx, wy, wz)
PRIVATE
    npc_gr[] = 8, 8,1,2,3,4,5,6,7;
BEGIN
    ctype = c_m9;
    xgraph = &npc_gr[0];
    size  = 100;
    angle = pi/2;
    x = wx; y = wy; z = wz;
    LOOP
        FRAME;
    END
END

(...)PROCESS M9SIGN(wx, wy, wz)
BEGIN
    ctype = c_m9;
    graph = 10;
    size  = 100;
    angle = 0;
    x = wx; y = wy; z = wz;
    LOOP
        FRAME;
    END
END

//------------------------------------------------------------------------------
// Billboards del INTERIOR (graficos id >= 11 en FPG/MODE9.FPG):
//   11 = antorcha,  12 = lampara de techo,  13 = trono.
// Se crean al entrar a la sala y se destruyen con signal(type ...) al salir.
//------------------------------------------------------------------------------
PROCESS TORCH(wx, wy, wz)
BEGIN
    ctype = c_m9;
    graph = 11;
    size  = 200;
    angle = 0;
    x = wx; y = wy; z = wz;
    LOOP
        FRAME;
    END
END

PROCESS LAMP(wx, wy, wz)
BEGIN
    ctype = c_m9;
    graph = 12;
    size  = 300;
    angle = 0;
    x = wx; y = wy; z = wz;
    LOOP
        FRAME;
    END
END

PROCESS THRONE(wx, wy, wz)
BEGIN
    ctype = c_m9;
    graph = 13;
    size  = 400;
    angle = 0;
    x = wx; y = wy; z = wz;
    LOOP
        FRAME;
    END
END

Y así queda en movimiento:

MODE9_MU.PRG · Bonus: pantalla partida a dos jugadores

Para rematar, una demo de split-screen. Este ejemplo lo comentaré simplemente por arriba: Se definen dos regiones (mitad superior y mitad inferior de la pantalla) con `MODE9_REGION`, y se arrancan dos cámaras con sus respectivos struct `m9` mediante `START_MODE9(c1, &m9[0].z, 1)` y `START_MODE9(c2, &m9[1].z, 2)`.

Cada jugador maneja su cámara (uno con WASD, otro con los cursores) y —detalle bonito— como cada cámara lleva también `ctype = c_m9`, cada jugador ve al otro como un billboard angular (Nazuna para variar) dentro del mundo. Para acabar sólo mencionar que mi Modo 9 admite hasta cuatro vistas simultáneas.

Puedes verlo en movimiento en este tuit: https://x.com/Hamster_ruso/status/2063713220397801517/video/1

La documentación

Soy consciente de que una librería así no se aprende solo leyendo código, de modo que he generado una ayuda en HTML completa, navegable, con la lista de todas las funciones agrupadas por temas, una guía de "primeros pasos" por etapas (las mismas que los ejemplos), una sección sobre cómo preparar los modelos OBJ y otra con las limitaciones del motor (número máximo de vértices, triángulos, materiales, modelos, billboards, etc.). La tenéis en dos idiomas: `HELP_MODE9_EN` en inglés y `HELP_MODE9_ES` en castellano. Símplemente descargaros el respositorio github del proyecto y abrid el `index.html` de la carpeta que prefiráis.

¿Y ahora qué?

Me hace especial ilusión este capítulo porque siento que el Modo 9 abre la puerta a un tipo de juego que mucha gente daba por imposible en DIV2. Tenéis la DLL ya compilada en la carpeta `BIN`, lista para usar; los ejemplos y los assets en `EXAMPLES`; y el código fuente en `SRC`.

Si esta entrada te ha interesado, te dejo el enlace a los capítulos anteriores de la serie sobre DIV2 Games Studio:

Ejemplos sencillos

Programando un JRPG (dificultad avanzada)

Programando un bullet-hell (dificultad avanzada)

Programando un tamagochi

Especial DLL

Y hasta aquí el ejemplo de hoy. ¡Nos leemos!

¿Aprendiendo a programar para MS-DOS con DIV2 Games Studio? Especial librerías DLL

2026-06-11T02:00:00.000+02:00

Hoy os presento un nuevo capítulo sobre DIV2 Games Studio, un entorno de programación de videojuegos para MS-DOS lanzado en 1999 (y su precuela un año antes) y que fue bastante popular en España, debido, entre otras cosas, a que se comercializó en quioscos a un precio bastante asequible (2.995 pesetas, unos 18€ de la época). Venía con un CD de instalación, un manual de usuario del tamaño de un diccionario y muchos ejemplos de código fuente. Su comunidad llegó a ser tan grande que incluso llegó a comercializarse una revista bimestral especializada en este framework: DIVmanía.

El capítulo de hoy quería dedicarlo a una funcionalidad que pasa bastante desapercibida tanto en DIV como en DIV2 y es el uso de ficheros DLL: Unas librerías externas, generalmente programadas en lenguaje C/C++, que en el caso de DIV Games Studio permiten añadir toda clase de efectos y funcionalidades extra e, incluso, expandir el propio lenguaje.

El objetivo de esta entrada no es detallar al milímetro cómo funcionan las DLL en DIV y DIV2 o pasear por el código fuente de los ejemplos, si no más bien recordaros que existen, mostraros qué permiten hacer cuando tienes mañana con el lenguaje C y dar varias píldoras acerca de su funcionamiento.

Para empezar, varios matices:

En mi GitHub encontraréis las librerías de ejemplo de esta entrada, así como su código fuente (https://github.com/LeHamsterRuso/DIV2Examples/tree/main/DLL, carpetas bin y src).
En la mayoría de DLL que veremos a continuación, comparto también un fichero PRG de ejemplo para que pruebes cómo funcionan (https://github.com/LeHamsterRuso/DIV2Examples/tree/main/PRG/DLL).
Las librerías de DIV1 no funcionan en DIV2 y viceversa. Las librerías de esta entrada sólo funcionan en DIV2.
DIV y DIV2 no permiten hacer uso de varias DLL, pero como paliativo sí que podemos hacer un CPP (fichero de código fuente en C++) que haga uso de varios CPP, por lo que puedes bypasear este punto si dispones del código fuente de las librerías que quieres usar.
Sólo he conseguido que mis librerías funcionen en DIV complicándolas con Watcom 10.6, un compilador de C/C++ de 1996. Lo he intentado con Open Watcom (alternativa libre y multiplataforma), pero las DLL que me generaba no eran idénticas y crasheaban al arrancar los juegos. Esto se debe a que el arranque de la DLL depende de símbolos que el runtime de Watcom 10.6 inyecta (main_entry_, la raíz de constructores C++); con OpenWatcom esos símbolos no salen idénticos y el loader de DIV32RUN no los reconoce.

¿Cómo hacemos que un juego utilice una DLL?

No es complicado, basta con copiar la DLL en la carpeta DLL e indicarle en el PRG que tiene que importarla:

Nota: Que sepas que da igual si especificas o no la carpeta "DLL" en el import, DIV buscará las librerías directamente ahí, pero no dará error si lo especificas.

Con todo ello, pasemos a los ejemplos y luego veamos más en detalle a la parte técnica.

Los ejemplos de mi GitHub:

HUD.DLL (+ HUDTEST.PRG)

Se trata de una DLL sencilla que únicamente muestra por pantalla los frames por segundo reales, la resolución de pantalla utilizada, el consumo de memoria de nuestro juego y una marca de agua (texto de copyright) en la esquina inferior derecha. La idea de esta DLL es utilizarla para degubuear el consumo de nuestro juego, midiendo el rendimiento de este o detectando posibles leaks de memoria.

CRT.DLL (+ CRTDEMO.PRG)

Como su nombre da a entender, añade un filtro de scanlines para simular un monitor CRT. En este tuit puedes verlo en movimiento: https://x.com/Hamster_ruso/status/2062268417197933052/video/1

WIPE.DLL (+ WIPEDEMO.PRG)

Crea efectos de transición, útil para el tránsito entre pantallas. En el PRG de ejemplo se activan pulsando "Espacio".

KEYDISP.DLL

Muestra un teclado en la esquina inferior izquierda y dibuja las teclas que estamos pulsando mientras jugamos. Para este ejemplo no he escrito un PRG, pero puedes probarlo con "MALVADO.PRG" (uno de los ejemplos míticos de DIV/DIV2).

PLASMA.DLL (+PLASMADE.PRG)

Una animación que simula el movimiento de una lámpara de lava.

SAVESTAT.DLL

Guarda los estados de un juego para después volver a cargarlos. Es similar a las funciones de save/load states de los emuladores: Vuelca el contenido de la memoria de los procesos a un fichero "SSX.SAV" y después los puedes cargar. Los botones F1 a F5 guardan, mientras que los botones F6 a F10 cargan. Para este ejemplo no he escrito un PRG, pero puedes probarlo con "MALVADO.PRG" (uno de los ejemplos míticos de DIV/DIV2). Nota: Es bastante inestable, lo comparto como prueba de concepto.

En este tuit puedes verlo en movimiento: https://x.com/Hamster_ruso/status/2062264865318719979/video/1

KD3D.DLL (+ 3D_01.PRG y 3D_02.PRG)

Carga un objeto 3D en formato OBJ. Sí, esto es 3D real en DIV2 Games Studio, renderizado por CPU. El personaje ha sido creado usando Blender. Se trata de una versión lowpoly de un modelo que hice en 2021 (https://sketchfab.com/3d-models/ankha-zone-version-37819f223f26467e8b3247e83b507805)

En este tuit puedes verlo en movimiento: https://x.com/Hamster_ruso/status/2062650483286618492/video/1

KD3DT.DLL (+ 3D_03.PRG)

Carga un objeto 3D en formato OBJ y le aplica una textura. En este tuit puedes verlo en movimiento: https://x.com/Hamster_ruso/status/2063003682799603803/video/1

¿Cómo funcionan las DLL en DIV Games Studio 2?

El concepto

DIV Games Studio se compone de dos partes: el lenguaje DIV (con el que escribes tus juegos) y DIV32RUN, el módulo interno que contiene todas las rutinas reales del motor (vídeo, procesos, paleta, sonido, etc.). Una DLL es un trozo de código en C/C++ que se "fusiona" con el juego en tiempo de ejecución y que puede llamar a las funciones internas de DIV32RUN y manipular sus variables directamente en memoria.

En la práctica, una DLL sirve para dos cosas: extender el lenguaje con funciones nuevas que no existen en DIV, o modificar/sustituir el funcionamiento interno del motor (rutinas de vídeo, efectos, comportamiento de los procesos…).

El puente: DIV.H, importar y exportar

Toda DLL de DIV incluye la cabecera DIV.H, que es el contrato entre tu código y el motor. El truco central es que DIV no expone una API por copia de datos, sino punteros a sus propias variables internas. La DLL los "pide" con DIV_import("nombre") y el macro GLOBAL_IMPORT() los resuelve todos de golpe en la inicialización:

Memoria del intérprete: mem[] (toda la memoria de los programas DIV), stack[] y sp (la pila por la que viajan los parámetros).
Vídeo: punteros directos a buffer, background y ghost, más anchura/altura y la paleta de colores.
Estructuras del lenguaje mapeadas sobre mem[] mediante offsets calculados: MOUSE, SCROLL, M7, M8, JOY, SETUP, NET, FILEINFO… y variables globales como fps, timer(), scan_code, ascii, etc.
La lista de procesos: id_offset, id_init_offset, process_size… que permiten recorrer y modificar cualquier proceso vivo (su x, y, graph, angle, flags…).
La comunicación es bidireccional: tú importas cosas de DIV con DIV_import, y le entregas tus funciones con DIV_export (o COM_export para funciones del lenguaje). Además de importar variables, DIV exporta un par de funciones de ayuda: div_rand(min,max) (números aleatorios) y div_text_out(texto,x,y) (escribir en pantalla). Es un detalle simpático que muestra que la relación es bidireccional.

Ejemplo de DLL mínima funcional, lo único que hace es dibujar una línea en pantalla:

#define GLOBALS
#include "div.h"

static int mindll_ok = 0;
static void *(*g_import)(char *name) = 0;
static void  (*g_export)(char *name, void *obj) = 0;

// Escribe una línea de píxeles (color 2 de la paleta cargada) en la fila 10 del buffer,
void post_process_buffer(void) {
    int x;
    char *row;
    if (!mindll_ok) return;
    if (wide <= 0 || height <= 10) return;
    row = buffer + 10 * wide;
    for (x = 0; x < wide; x++) row[x] = 2;
}

// No hace nada, sólo devuelve 0
void __export divlibrary(LIBRARY_PARAMS) {}

// Exporta post_process_buffer para que DIV2 lo llame después de cada frame
void __export divmain(COMMON_PARAMS) {
    g_import = DIV_import;
    g_export = DIV_export;
    #define DIV_import g_import
    #define DIV_export g_export
    AutoLoad();
    GLOBAL_IMPORT();
    mindll_ok = 1;
    DIV_export("post_process_buffer", post_process_buffer);
    #undef DIV_import
    #undef DIV_export
}

// No hace nada, sólo devuelve 0
void __export divend(COMMON_PARAMS) {
    mindll_ok = 0;
}

Los tres tipos de DLL

1. Salvapantallas (ej. DEMO0.CPP, SS1.CPP, ejemplos presentes en el disco de DIV2)

Defines ss_init(), ss_frame() y ss_end(). DIV las llama tras un tiempo de inactividad (ss_time). En ss_frame() operas sobre el buffer de vídeo antes de cada volcado. Se controla con ss_status y se sale poniendo ss_exit=1.

#include <stdio.h>

#define GLOBALS
#include "div.h"

void ss_init(void) { // Funcion de inicializacion del salvapantallas.

  ss_time=1500; // Llamar al salvapantallas tras 15 segundos de inactividad.

}

void ss_frame(void) { // Pone "wide" puntos en negro, aleatoriamente.
   // HAZ LA MAGIA AQUI 
}

void __export divmain(COMMON_PARAMS) {
  AutoLoad();
  GLOBAL_IMPORT();
  DIV_export("ss_init",ss_init);
  DIV_export("ss_frame",ss_frame);
}

2. DLL de autocarga (ej. DEMO1.CPP, AGUA.CPP, HBOY.CPP, ejemplos presentes en el disco de DIV2)

Llaman a AutoLoad() dentro de divmain() y se activan solas con solo copiarlas al directorio del juego (o junto a D.EXE). Su poder está en los "Entry-Points" estándar: funciones con nombre fijo que DIV invoca en momentos concretos de su ciclo si las defines. Aquí es donde una DLL puede reemplazar partes del motor sin que el juego DIV se entere.

Las más jugosas: set_video_mode, process_palette, process_active_palette, process_fpg / process_map / process_fnt / process_sound (modificar recursos al cargarlos), background_to_buffer, buffer_to_video (sustituir el volcado de pantalla), post_process_scroll, post_process_m7, post_process_buffer (aplicar efectos a cada ventana), post_process (tocar las variables de los procesos cada frame), put_sprite (interceptar el dibujado de sprites)...

3. DLL de funciones (ej. DEMO2.CPP, PARTS.CPP)

Añaden comandos nuevos al lenguaje. Defines divlibrary() y dentro haces un COM_export("NOMBRE", puntero, nº_parámetros) por cada función. Dentro de cada función lees los parámetros con getparm() y obligatoriamente devuelves con retval() (siempre, aunque no retornes nada útil). Desde el juego se usan tras un IMPORT "ruta\nombre.dll";.

Conviene decir que también necesitan divmain() con GLOBAL_IMPORT() además de divlibrary() - se ve en DEMO2.CPP.

Reglas que hay que respetar (lo que NO se puede/debe hacer)

Está absolutamente prohibido usar malloc/free/fopen/fclose estándar. Hay que usar div_malloc, div_free, div_fopen, div_fclose (se comportan igual pero pasan por el gestor de memoria de DIV; usar las de C corrompe el estado).
El retval() es obligatorio en toda función del lenguaje, y hay que hacer un getparm() por cada parámetro declarado, o se descuadra la pila.
En el módulo principal hay que poner #define GLOBALS antes de #include "div.h" (define realmente las variables; el resto de fuentes las ven como extern). Esto permite repartir una DLL en varios .cpp.
Las funciones de arranque/cierre (divmain/divend/divlibrary) van marcadas con __export.
No se pueden importar DLL de otros lenguajes: el formato y el ABI son específicos de DIV.
Sí puedes usar el resto de la librería estándar de C (math.h, etc.) con normalidad.

La parte técnica peculiar

DIV usa el formato de DLL de Windows NT aunque corre en DOS. Las DLL se construían con el Watcom C++ 10.6 original, añadiendo la directiva format windows nt dll al enlazador. ¿Implica esto que necesitas un Windows o un MS-DOS especial para compilar estas librerías? No necesariamente, en mi caso para compilarlas desde macOS ejecuto el toolchain de Watcom vía Wine en un contenedor Docker que contiene una imagen liviana de Linux.

Si esta entrada te ha interesado, te dejo el enlace a los capítulos anteriores:

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

2026-05-30T22:19:56.212+02:00

Han pasado varios veces desde la última entrada que hice sobre Div Games Studio y hoy os presento algo sencillo de hacer, un Tamagochi protagonizado por Aisha Clanclan, una oficial del universo de Outlaw Star perteneciente a la raza alienígena Ctarl-Ctarl, conocida por su fuerza sobrehumana, su gran ego y su capacidad de transformarse parcialmente en bestia.

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. Si te interesa, te dejo el enlace a los capítulos anteriores (1 ejemplos sencillos, 2 JRPG, 3 bullet-hell).

En lo que respecta a los Tamagochi, si analizamos su lógica veremos que, en función del tiempo, sus estados van cambiando (pasan hambre, se ensucian, enferman, etc) e incluso pueden llegar a evolucionar en función de cómo les cuidamos. Ahora bien, esto supone un reto en Div debido a que carece de funciones básicas para obtener la fecha del sistema. Es decir, el lenguaje carece de algo tan básico como un "get_date", "get_hour" o cualquier tipo de función que sirva para saber qué día es hoy o qué hora tiene el ordenador.

Para contornar este tipo de limitaciones, los desarrolladores en Div solemos estudiar dos opciones:

Crear una librería DLL en lenguaje C para poder expandir Div (si os fijáis en la carpeta DLL del framework se muestran ejemplos de librerías https://vii1.github.io/DIV2Help/1014.html).

Hacer uso del comando system (https://vii1.github.io/DIV2Help/168.html) que permite lanzar comandos por CMD y capturar el resultado.

El inconveniente de crear una DLL es que acabas añadiendo una capa más de complejidad a tu código y hacer una llamada system tampoco es que sea la panacea, puesto que los comandos que funcionan MS-DOS no tienen por qué existir o comportarse igual en DOSBox o similares. Siendo sinceros, de las dos opciones la que más me gusta es la de la DLL.

No obstante, opté por una tercera vía: Crear ficheros temporales en tiempo de ejecución. Y es que, aunque DIV no tenga funciones para manejar la fecha del sistema, sí que nos permite obtener la fecha de creación y de modificación de un fichero. Con esa premisa, podemos crear un fichero y consultar su fecha de creación para saber qué fecha y hora tiene el sistema operativo... Lo cual resulta terriblemente más sencillo que crearte una librería en C o hacer invocaciones dudosas con la instrucción system. Por cierto, estos ejemplos los podéis consultar desde mi GitHub (https://github.com/LeHamsterRuso/DIV2Examples/blob/main/PRG/):

//------------------------------------------------------------------------------
// TÍTULO:      TAMA01.PRG - Tutorial: Obtener Hora del Sistema
// FECHA:       13/02/2026
// DESCRIPCIÓN: Primer ejemplo de un tutorial sobre cómo crear un juego de mascota virtual en MS-DOS.
//              Este ejemplo muestra cómo obtener la hora actual del sistema operativo.
// NOTA:        El programa crea un archivo temporal para obtener la fecha y hora de modificación,
//              que representa la hora actual. Presiona ESC para salir.
//              Código y comentarios en castellano para facilitar la comprensión.
//------------------------------------------------------------------------------

PROGRAM TAMA_WAIFU;
CONST
    nombre_fichero = "test.tmp";
    permisos = "w";
GLOBAL
    id_fichero;
    dato = 0;
BEGIN
    id_fichero = fopen(nombre_fichero, permisos);
    fwrite(OFFSET dato, sizeof(dato), id_fichero);
    fclose(id_fichero);

    get_fileinfo(nombre_fichero);

    // Fecha de última modificación
    write_int(0, 10, 50, 0, &fileinfo.day);      // día
    write_int(0, 50, 50, 0, &fileinfo.month);    // mes
    write_int(0, 90, 50, 0, &fileinfo.year);     // año

    // Hora de última modificación
    write_int(0, 10, 70, 0, &fileinfo.hour);     // hora
    write_int(0, 50, 70, 0, &fileinfo.min);      // minuto
    write_int(0, 90, 70, 0, &fileinfo.sec);      // segundo

    // Bucle para mantener el programa abierto
    LOOP
        IF (key(_ESC))
            exit(0, "Bye");
        END
        FRAME;
    END
END

Con esa premisa, ya podemos empezar a hacer algo básico: Mostrar a Aisha de fondo, un hud con la información de su estado y dibujar una botonera con la opción de Salir.

Como veréis a continuación, el código no tiene mucho misterio:

Hacemos uso de una serie de constantes para mantener el hud organizado y memorizar los ID de los gráficos para Aisha y para el marco de la botonera.
Al arrancar el programa recuperamos la hora con get_hora(), que lo que hará será crear el fichero temporal, consultar la hora y fecha de creación y almacenará los datos de la fecha en una estructura llamada reloj.

El código en si no es lioso, la única parte realmente complicada es todo el formateo de la fecha, para calcular correctamente los años bisiestos.

Llamaremos a mostrar_mascota() para dibujar a Aisha, mostrar_hud() para dibujar la información del estado de Aisha y mostrar_comandos() para dibujar las interacciones que podemos tener (por ahora sólo podemos "salir" del juego.

//------------------------------------------------------------------------------
// TÍTULO:      TAMA02A.PRG - Versión funcional
// FECHA:       13/02/2026
// DESCRIPCIÓN: Segundo ejemplo de un tutorial sobre cómo crear un juego de mascota virtual en MS-DOS.
//              Muestra una interfaz gráfica simple:
//              - HUD superior: stats (Hambre, Felicidad, Disciplina)
//              - CG central: imagen de Aisha
//              - Muestra el texto inferior: "Salir"
//
//------------------------------------------------------------------------------

PROGRAM TAMA_WAIFU;

CONST
    PERMISO_ESCRITURA = "w";    // w = escritura, r = lectura, a = append (añadir al final)

    // ID de los gráficos
    CG_AISHA = 4;         // ID del gráfico que muestra a Aisha
    MARCO_DIALOGO = 16;   // ID del marco del cuadro de dilálogo

    // Índices para HUD, recorremos un bucle para mostrar los textos en pantalla
    HUD_HAMBRE = 0;     // Índice para el texto "Hambre:" y su valor
    HUD_FELICIDAD = 1;  // Índice para el texto "Felicidad:" y su valor
    HUD_DISCIPLINA = 2; // Índice para el texto "Disc:" y su valor
    HUD_COUNT = 3;      // Número total de labels del HUD (fin del bucle)

    // Índices para los textos del reloj,  recorremos un bucle para mostrar los textos en pantalla
    RL_HORA_LABEL = 0;  // 'Hora:' antes de la hora
    RL_SEP_T1 = 1;      // ':' entre horas y minutos
    RL_SEP_T2 = 2;      // ':' entre minutos y segundos
    RL_FECHA_LABEL = 3; // 'Fecha:' antes de la fecha
    RL_SEP_D_M = 4;     // '/' entre día y mes
    RL_SEP_M_Y = 5;     // '/' entre mes y año
    RL_COUNT = 6;       // Número total de labels del reloj (fin del bucle)

    // Indice para los valoress del reloj, recorremos un bucle para mostrar los valores en pantalla
    RV_HORA = 0;        // Índice para escribir la hora (write_int)
    RV_MIN = 1;         // Índice para escribir los minutos (write_int)
    RV_SEG = 2;         // Índice para escribir los segundos (write_int)
    RV_DIA = 3;         // Índice para escribir el día (write_int)
    RV_MES = 4;         // Índice para escribir el mes (write_int)
    RV_ANO = 5;         // Índice para escribir el año (write_int)
    RV_COUNT = 6;       // Número total de valores del reloj (fin del bucle)

GLOBAL
    // Juego a 320x200, 60 FPS, sin frameskip, cuadro de diálogo de 50px de alto
    screen_width = 320;
    screen_height = 200;
    max_fps = 60;
    frameskip = 0;
    cuadro_dialogo_alto = 50;

    // Configuración de los write/write_int para el HUD
    fuente_fichero = 0;
    fuente_izq = 3;
    fuente_centro = 4;

    // ID de los FPG a cargar
    fpg_aisha = 0;
    fpg_hud = 0;

    // Fondo del HUD
    background_tipo = 3;
    background_color = 2;
    background_opacity = 8;
    background_region = 0;
    background_x = 0;
    background_y = 0;
    background_width = 320;
    background_height = 20;

    // Rutas de los assets
    rutas_aisha = "tama/aisha.fpg";
    rutas_hud = "tama/hud.fpg";
    rutas_tmp_nombre = "tm_time.tmp";

    // Stats como variables
    hambre = 2;
    felicidad = 3;
    disciplina = 1;

    // Estructura reloj (fecha/hora)
    STRUCT reloj
        dia = 0;
        mes = 0;
        ano = 0;
        hora = 0;
        minutos = 0;
        segundos = 0;
    END

PRIVATE
    i = 0; // Contador de frames para actualizar reloj cada segundo

BEGIN
    // Configurar modo de video y FPS
    set_mode(screen_width * 1000 + screen_height);
    set_fps(max_fps, 0);

    // Cargamos la paleta y los ficheros FPG
    load_pal(rutas_hud);
    fpg_aisha = load_fpg(rutas_aisha);
    fpg_hud = load_fpg(rutas_hud);

    // Inicializamos el reloj con la hora del sistema
    get_hora();

    // Iniciamos los procesos que correrán en paralelo
    mostrar_mascota();  // El personaje a mostrar
    mostrar_hud();      // Información en pantalla
    mostrar_comandos(); // La lista de comandos

    // Loop principal
    LOOP
        // Actualizar contador de frames y reloj cada segundo
        i = i + 1;
        IF (i > FPS)   // La constante FPS contiene cuantos frames hubo en el último segundo, más fiable que usar max_fps
            actualiza_reloj();
            i = 0;
        END

        FRAME;
    END
END

//------------------------------------------------------------------------------
// PROCESS: get_hora
// DESCRIPCIÓN: Rellena la STRUCT `reloj` con la fecha/hora actual del sistema.
// Para ello creamos un fichero temporal y consultamos su fecha de modificación
//------------------------------------------------------------------------------
FUNCTION get_hora();
PRIVATE
    tmp_dato;
    tmp_id;
BEGIN
    tmp_dato = 0;
    tmp_id = fopen(rutas_tmp_nombre, PERMISO_ESCRITURA);
    fwrite(OFFSET tmp_dato, sizeof(tmp_dato), tmp_id);
    fclose(tmp_id);

    get_fileinfo(rutas_tmp_nombre);

    reloj.dia = fileinfo.day;
    reloj.mes = fileinfo.month;
    reloj.ano = fileinfo.year;

    reloj.hora = fileinfo.hour;
    reloj.minutos = fileinfo.min;
    reloj.segundos = fileinfo.sec;

    return(0);
END

//------------------------------------------------------------------------------
// FUNCTION: actualiza_reloj
// DESCRIPCIÓN: Incrementa el reloj en +1 segundo y normaliza minutos/horas/días
//------------------------------------------------------------------------------
FUNCTION actualiza_reloj();
PRIVATE
    maxd;
BEGIN
    reloj.segundos = reloj.segundos + 1;
    IF (reloj.segundos >= 60)
        reloj.segundos = 0;
        reloj.minutos = reloj.minutos + 1;
    END

    IF (reloj.minutos >= 60)
        reloj.minutos = 0;
        reloj.hora = reloj.hora + 1;
    END

    IF (reloj.hora >= 24)
        reloj.hora = 0;
        reloj.dia = reloj.dia + 1;

        // Normalizamos día/mes/año según días del mes
        maxd = dias_mes(reloj.mes, reloj.ano);
        IF (reloj.dia > maxd)
            reloj.dia = 1;
            reloj.mes = reloj.mes + 1;
            IF (reloj.mes > 12)
                reloj.mes = 1;
                reloj.ano = reloj.ano + 1;
            END
        END
    END

    return(0);
END

//------------------------------------------------------------------------------
// FUNCTION: dias_mes
// DESCRIPCIÓN: Devuelve número de días del mes `m` en el año `y` (gestión de bisiestos)
//------------------------------------------------------------------------------
FUNCTION dias_mes(INT m, INT y);
BEGIN
    SWITCH (m)
        CASE 1,3,5,7,8,10,12:
            return(31);
        END
        CASE 4,6,9,11:
            return(30);
        END
        CASE 2:
            IF ((y MOD 400 == 0) OR ((y MOD 4 == 0) AND (y MOD 100 <> 0)))
                return(29);
            END
            return(28);
        END
        DEFAULT:
            return(31);
        END
    END
END

//------------------------------------------------------------------------------
// PROCESS: mostrar_mascota
// DESCRIPCIÓN: Muestra la CG de la mascota (Aisha) en el centro de la pantalla
//------------------------------------------------------------------------------
PROCESS mostrar_mascota();
BEGIN
    file = fpg_aisha;   // Fichero FPG a utilizar
    graph = CG_AISHA;   // ID del gráfico a mostrar

    // X = mitad del ancho de la pantalla, para que quede centrado
    x = screen_width / 2;

    // Y = centro de la pantalla - mitad del alto del cuadro de diálogo para que quede justo encima del texto inferior
    y = screen_height / 2 - cuadro_dialogo_alto / 2;

    LOOP
        FRAME;
    END
END

//------------------------------------------------------------------------------
// PROCESS: mostrar_hud
// DESCRIPCIÓN: Muestra el HUD superior con los stats del personaje y el reloj
//------------------------------------------------------------------------------
FUNCTION mostrar_hud();
BEGIN
    // Dibujamos un fondo semitransparente
    // Uso de draw: draw(<tipo>, <color>, <opacidad>, <región>, <x0>, <y0>, <x1>, <y1>)
    draw(background_tipo, background_color, background_opacity, background_region,
            background_x, background_y,
            background_x + background_width, background_y + background_height);

    // Labels del HUD (coordenadas fijas en esta versión)
    write(fuente_fichero, 8, 5, fuente_izq, "Hambre:");
    write(fuente_fichero, 109, 5, fuente_izq, "Felicidad:");
    write(fuente_fichero, 210, 5, fuente_izq, "Disciplina:");

    // Valores de los stats (OFFSET) en coordenadas fijas
    write_int(fuente_fichero, 64, 5, fuente_izq, OFFSET hambre);
    write_int(fuente_fichero, 181, 5, fuente_izq, OFFSET felicidad);
    write_int(fuente_fichero, 286, 5, fuente_izq, OFFSET disciplina);

    // Labels del reloj (texto) en coordenadas fijas
    write(fuente_fichero, 64, 17, fuente_izq, "Hora:");
    write(fuente_fichero, 120, 17, fuente_izq, ":");
    write(fuente_fichero, 144, 17, fuente_izq, ":");
    write(fuente_fichero, 188, 17, fuente_izq, "Fecha:");
    write(fuente_fichero, 248, 17, fuente_izq, "/");
    write(fuente_fichero, 272, 17, fuente_izq, "/");

    // Valores numéricos del reloj (OFFSET) en coordenadas fijas
    write_int(fuente_fichero, 104, 17, fuente_izq, OFFSET reloj.hora);
    write_int(fuente_fichero, 128, 17, fuente_izq, OFFSET reloj.minutos);
    write_int(fuente_fichero, 152, 17, fuente_izq, OFFSET reloj.segundos);

    write_int(fuente_fichero, 232, 17, fuente_izq, OFFSET reloj.dia);
    write_int(fuente_fichero, 256, 17, fuente_izq, OFFSET reloj.mes);
    write_int(fuente_fichero, 280, 17, fuente_izq, OFFSET reloj.ano);

    return(0);
END

//------------------------------------------------------------------------------
// PROCESS: mostrar_comandos
// DESCRIPCIÓN: Muestra el marco de diálogo y los comandos disponibles (en este caso sólo "Salir") en la parte inferior de la pantalla
//------------------------------------------------------------------------------
PROCESS mostrar_comandos();
BEGIN
    file = fpg_hud;         // Fichero FPG a utilizar
    graph = MARCO_DIALOGO;  // ID del gráfico del marco del cuadro de diálogo

    // Centramos el marco en la parte inferior de la pantalla
    x = screen_width / 2;
    y = screen_height - cuadro_dialogo_alto / 2;

    // Por ahora no hay comandos
    write(fuente_fichero, x, y, fuente_centro, "> Salir");

    LOOP
        // Si se pulsa ESC, SPACE o ENTER, salimos del programa
        IF (key(_esc) OR key(_space) OR key(_enter))
            exit("Hasta pronto.", 0);
        END

        FRAME;
    END
END

Ahora bien, el código anterior podríamos organizarlo mejor si hacemos uso de estructuras, de forma que haga exáctamente lo mismo, pero siendo más legible: Esta versión es exáctamente igual a la anterior, pero definiendo estructuras globales para la configuración (resolución, frames y ancho del cuadro de la botonera), fuente (fichero y alineaciones), fpg (id de Aisha y del hud), hud (labels y valores), rutas (localización de los recursos) y stats (hambre, felicidad y disciplina):

//------------------------------------------------------------------------------
// TÍTULO:      TAMA02.PRG - Esqueleto UI básico
// FECHA:       14/02/2026
// DESCRIPCIÓN: Segundo ejemplo de un tutorial sobre cómo crear un juego de mascota virtual en MS-DOS.
//              Muestra una interfaz gráfica simple:
//              - HUD superior: stats (Hambre, Felicidad, Disciplina)
//              - CG central: imagen de Aisha
//              - Muestra el texto inferior: "Salir"
//
// Nota: Esta versión (TAMA02B.PRG) es funcionalmente idéntica a TAMA02A.PRG,
//       pero organiza los datos usando STRUCTs en lugar de variables/arrays.
//------------------------------------------------------------------------------

PROGRAM TAMA_WAIFU;

CONST
(...)
GLOBAL
    // Estructura de configuración general
    STRUCT configuracion
        STRUCT pantalla     // Resolución de pantalla de 320x200
            ancho = 320;
            alto = 200;
        END
        fps = 60;           // Frames por segundo para el juego
        frameskip = 0;      // Frameskip (0 = desactivado)
        STRUCT cuadro_dialogo
            alto = 50;      // alto total del cuadro de diálogo (px)
        END
    END

    // Estructura para constantes de UI (fuente, alineación y márgenes)
    STRUCT fuente
        fichero = 0; // ID o fuente por defecto
        STRUCT alineacion
            izq = 3;
            centro = 4;
        END
    END

    // Estructura para almacenar los ficheros FPG
    STRUCT fpg
        aisha;  // ID del FPG de CG de Aisha
        hud;    // ID del FPG del HUD
    END

    // Estructura global del HUD (labels como array)
    STRUCT hud
        STRUCT label[HUD_COUNT] // Lista de labels ("Hambre:", "Felicidad:", "Disc:")
            STRUCT pos          // Posición de cada label en pantalla
                x = 0;
                y = 0;
            END
            STRUCT text         // Texto de cada label
                label = "";
            END
            STRUCT value_pos    // Posición para escribir el valor numérico (write_int) de cada stat
                x = 0;
                y = 0;
            END
        END

        // Reloj: separa labels (texto) y values (posiciones para write_int)
        STRUCT reloj
            STRUCT labels[RL_COUNT] // Lista de labels del reloj ("Hora:", ":", ":", "Fecha:", "/", "/")
                STRUCT pos          // Posición de cada label del reloj en pantalla
                    x = 0;
                    y = 0;
                END
                STRUCT text         // Texto de cada label del reloj ("Hora:", ":", ":", "Fecha:", "/", "/")
                    label = "";
                END
            END
            STRUCT values[RV_COUNT] // Posiciones para escribir los valores numéricos del reloj (hora, minutos, segundos, día, mes, año)
                STRUCT pos
                    x = 0;
                    y = 0;
                END
            END
        END

        STRUCT background // Parámetros para el fondo del HUD (rectángulo negro semitransparente)
            tipo = 3;     // tipo de dibujo (rectángulo)
            color = 2;    // color del rectángulo
            opacity = 8;  // opacidad (0-15)
            region = 0;   // región para draw
            x = 0;        // posición de esquina superior izquierda
            y = 0;
            width = 320;  // ancho del rectángulo (se ajusta en tiempo de ejecución)
            height = 20;  // alto del rectángulo
        END
    END

    // Estructura de rutas de assets
    STRUCT rutas
        aisha = "tama/aisha.fpg";    // Fichero con los gráficos de la chica mascota
        hud = "tama/hud.fpg";        // Fichero con los gráficos de la interfaz
        tmp_nombre = "tm_time.tmp";  // Fichero temporal para obtener la hora del sistema
    END

    // Stats de la mascota virtual
    STRUCT stats
        hambre = 2;
        felicidad = 3;
        disciplina = 1;
    END

    // Estructura de reloj para fecha/hora del sistema
    STRUCT reloj
        dia = 0;
        mes = 0;
        ano = 0;
        hora = 0;
        minutos = 0;
        segundos = 0;
    END

PRIVATE
    i = 0; // Contador de frames para actualizar reloj cada segundo

BEGIN
    // Configurar modo de video y FPS
    set_mode(configuracion.pantalla.ancho * 1000 + configuracion.pantalla.alto);
    set_fps(configuracion.fps, 0);

    // Carganmos la paleta
    load_pal(rutas.hud);

    // Carganis kis archivos FPG
    fpg.aisha = load_fpg(rutas.aisha);
    fpg.hud = load_fpg(rutas.hud);

    // Inicializamos el reloj con la hora del sistema
    get_hora();

    // Iniciamos los procesos que correrán en paralelo
    mostrar_mascota();  // El personaje a mostrar
    mostrar_hud();      // Información en pantalla
    mostrar_comandos(); // La lista de comandos

    // Loop principal
    LOOP
        // Actualizar contador de frames y reloj cada segundo
        i = i + 1;
        IF (i > FPS)   // La constante FPS contiene cuantos frames hubo en el último segundo, más fiable que usar configuracion.fps
            actualiza_reloj();
            i = 0;
        END

        FRAME;
    END
END

//------------------------------------------------------------------------------
// PROCESS: get_hora
// DESCRIPCIÓN: Rellena la STRUCT `reloj` con la fecha/hora actual del sistema.
// Para ello creamos un fichero temporal y consultamos su fecha de modificación
//------------------------------------------------------------------------------
FUNCTION get_hora();
PRIVATE
    tmp_dato;
    tmp_id;
BEGIN
    tmp_dato = 0;
    tmp_id = fopen(rutas.tmp_nombre, PERMISO_ESCRITURA);
    fwrite(OFFSET tmp_dato, sizeof(tmp_dato), tmp_id);
    fclose(tmp_id);

    get_fileinfo(rutas.tmp_nombre);

    reloj.dia = fileinfo.day;
    reloj.mes = fileinfo.month;
    reloj.ano = fileinfo.year;

    reloj.hora = fileinfo.hour;
    reloj.minutos = fileinfo.min;
    reloj.segundos = fileinfo.sec;

    return(0);
END
(...)//------------------------------------------------------------------------------
// PROCESS: mostrar_mascota
// DESCRIPCIÓN: Muestra la CG de la mascota (Aisha) en el centro de la pantalla
//------------------------------------------------------------------------------
PROCESS mostrar_mascota();
BEGIN
    file = fpg.aisha;   // Fichero FPG a utiiizar
    graph = CG_AISHA;   // ID del gráfico a mostrar

    // X = mitad del ancho de la pantalla, para que quede centrado
    x = configuracion.pantalla.ancho / 2;

    // Y = centro de la pantalla - mitad del alto del cuadro de diálogo para que quede justo encima del texto inferior
    y = configuracion.pantalla.alto / 2 - configuracion.cuadro_dialogo.alto / 2;

    // No utilizamos put/xput/set_screen y usamos un bucle para que el gráfico cambie en futuras iteraciones
    LOOP
        FRAME;
    END
END

//------------------------------------------------------------------------------
// PROCESS: mostrar_hud
// DESCRIPCIÓN: Muestra el HUD superior con los stats del personaje y el reloj
//------------------------------------------------------------------------------
FUNCTION mostrar_hud();
PRIVATE
    INT idx;    // Índice para bucles
BEGIN
    // Inicializamos los componentes del HUD
    init_hud();

    // Dibujamos un fondo semitransparente
    // Uso de draw: draw(<tipo>, <color>, <opacidad>, <región>, <x0>, <y0>, <x1>, <y1>)
    draw(hud.background.tipo, hud.background.color, hud.background.opacity, hud.background.region,
            hud.background.x, hud.background.y,
            hud.background.x + hud.background.width, hud.background.y + hud.background.height);

    // Escribimos los labels dek HUD uno a uno
    FOR (idx = 0; idx < HUD_COUNT; idx++)
        write(fuente.fichero, hud.label[idx].pos.x, hud.label[idx].pos.y, fuente.alineacion.izq, hud.label[idx].text.label);
    END

    // Escribimos los valores de los stats (OFFSET)
    write_int(fuente.fichero, hud.label[HUD_HAMBRE].value_pos.x, hud.label[HUD_HAMBRE].value_pos.y, fuente.alineacion.izq, OFFSET stats.hambre);
    write_int(fuente.fichero, hud.label[HUD_FELICIDAD].value_pos.x, hud.label[HUD_FELICIDAD].value_pos.y, fuente.alineacion.izq, OFFSET stats.felicidad);
    write_int(fuente.fichero, hud.label[HUD_DISCIPLINA].value_pos.x, hud.label[HUD_DISCIPLINA].value_pos.y, fuente.alineacion.izq, OFFSET stats.disciplina);

    // Escribimos los labels del reloj uno a uno
    FOR (idx = 0; idx < RL_COUNT; idx++)
        write(fuente.fichero, hud.reloj.labels[idx].pos.x, hud.reloj.labels[idx].pos.y, fuente.alineacion.izq, hud.reloj.labels[idx].text.label);
    END

    // Escribimos los valores del reloj (OFFSET)
    write_int(fuente.fichero, hud.reloj.values[RV_HORA].pos.x, hud.reloj.values[RV_HORA].pos.y, fuente.alineacion.izq, OFFSET reloj.hora);
    write_int(fuente.fichero, hud.reloj.values[RV_MIN].pos.x, hud.reloj.values[RV_MIN].pos.y, fuente.alineacion.izq, OFFSET reloj.minutos);
    write_int(fuente.fichero, hud.reloj.values[RV_SEG].pos.x, hud.reloj.values[RV_SEG].pos.y, fuente.alineacion.izq, OFFSET reloj.segundos);
    write_int(fuente.fichero, hud.reloj.values[RV_DIA].pos.x, hud.reloj.values[RV_DIA].pos.y, fuente.alineacion.izq, OFFSET reloj.dia);
    write_int(fuente.fichero, hud.reloj.values[RV_MES].pos.x, hud.reloj.values[RV_MES].pos.y, fuente.alineacion.izq, OFFSET reloj.mes);
    write_int(fuente.fichero, hud.reloj.values[RV_ANO].pos.x, hud.reloj.values[RV_ANO].pos.y, fuente.alineacion.izq, OFFSET reloj.ano);

    return(0);
END

//------------------------------------------------------------------------------
// PROCESS: init_hud
// DESCRIPCIÓN: Inicializa las posiciones y textos de los labels del HUD
// que luego serán usados en el proceso `mostrar_hud`
//------------------------------------------------------------------------------
FUNCTION init_hud();
BEGIN
    hud.label[HUD_HAMBRE].pos.x = 8;
    hud.label[HUD_HAMBRE].pos.y = 5;
    hud.label[HUD_HAMBRE].text.label = "Hambre:";
    hud.label[HUD_HAMBRE].value_pos.x = 64;
    hud.label[HUD_HAMBRE].value_pos.y = 5;

    hud.label[HUD_FELICIDAD].pos.x = 109;
    hud.label[HUD_FELICIDAD].pos.y = 5;
    hud.label[HUD_FELICIDAD].text.label = "Felicidad:";
    hud.label[HUD_FELICIDAD].value_pos.x = 181;
    hud.label[HUD_FELICIDAD].value_pos.y = 5;

    hud.label[HUD_DISCIPLINA].pos.x = 210;
    hud.label[HUD_DISCIPLINA].pos.y = 5;
    hud.label[HUD_DISCIPLINA].text.label = "Disciplina:";
    hud.label[HUD_DISCIPLINA].value_pos.x = 286;
    hud.label[HUD_DISCIPLINA].value_pos.y = 5;

    // Labels del reloj
    hud.reloj.labels[RL_HORA_LABEL].pos.x = 64;
    hud.reloj.labels[RL_HORA_LABEL].pos.y = 17;
    hud.reloj.labels[RL_HORA_LABEL].text.label = "Hora:";

    hud.reloj.values[RV_HORA].pos.x = 104; // hora (2 dígitos)
    hud.reloj.values[RV_HORA].pos.y = 17;

    hud.reloj.labels[RL_SEP_T1].pos.x = 120; // ':'
    hud.reloj.labels[RL_SEP_T1].pos.y = 17;
    hud.reloj.labels[RL_SEP_T1].text.label = ":";

    hud.reloj.values[RV_MIN].pos.x = 128; // minutos
    hud.reloj.values[RV_MIN].pos.y = 17;

    hud.reloj.labels[RL_SEP_T2].pos.x = 144; // ':'
    hud.reloj.labels[RL_SEP_T2].pos.y = 17;
    hud.reloj.labels[RL_SEP_T2].text.label = ":";

    hud.reloj.values[RV_SEG].pos.x = 152; // segundos
    hud.reloj.values[RV_SEG].pos.y = 17;

    // Fecha
    hud.reloj.labels[RL_FECHA_LABEL].pos.x = 188;
    hud.reloj.labels[RL_FECHA_LABEL].pos.y = 17;
    hud.reloj.labels[RL_FECHA_LABEL].text.label = "Fecha:";

    hud.reloj.values[RV_DIA].pos.x = 232; // día
    hud.reloj.values[RV_DIA].pos.y = 17;

    hud.reloj.labels[RL_SEP_D_M].pos.x = 248; // '/'
    hud.reloj.labels[RL_SEP_D_M].pos.y = 17;
    hud.reloj.labels[RL_SEP_D_M].text.label = "/";

    hud.reloj.values[RV_MES].pos.x = 256; // mes
    hud.reloj.values[RV_MES].pos.y = 17;

    hud.reloj.labels[RL_SEP_M_Y].pos.x = 272; // '/'
    hud.reloj.labels[RL_SEP_M_Y].pos.y = 17;
    hud.reloj.labels[RL_SEP_M_Y].text.label = "/";

    hud.reloj.values[RV_ANO].pos.x = 280; // año (4 dígitos)
    hud.reloj.values[RV_ANO].pos.y = 17;

    // Ajustamos el ancho del fondo del HUD al ancho de la pantalla
    hud.background.width = configuracion.pantalla.ancho;

    return(0);
END

//------------------------------------------------------------------------------
// PROCESS: mostrar_comandos
// DESCRIPCIÓN: Muestra el marco de diálogo y los comandos disponibles (en este caso sólo "Salir") en la parte inferior de la pantalla
//------------------------------------------------------------------------------
PROCESS mostrar_comandos();
BEGIN
    file = fpg.hud;         // Fichero FPG a utilizar
    graph = MARCO_DIALOGO;  // ID del gráfico del marco del cuadro de diálogo

    // Centramos el marco en la parte inferior de la pantalla
    x = configuracion.pantalla.ancho / 2;
    y = configuracion.pantalla.alto - configuracion.cuadro_dialogo.alto / 2;

    // Por ahora no hay comandos
    write(fuente.fichero, x, y, fuente.alineacion.centro, "> Salir");

    LOOP
        // Si se pulsa ESC, SPACE o ENTER, salimos del programa
        IF (key(_esc) OR key(_space) OR key(_enter))
            exit("Hasta pronto.", 0);
        END

        FRAME;
    END
END
 

Aunque a nivel funcional esto no aporte nada, nos permite programar de una forma más parecida a los lenguajes de programación actuales, como si de una falsa orientación a objetos se tratara. Y bueno, ahora que ya tenemos un esquelto base, podemos empezar a añadir funcionalidades básicas, como "Jugar", "Alimentar", "Estudiar", "Bañar", "Curar" y apagar las "Luces" (para forzar que se duerma).

Para ello:

Crearemos una estructura para la mascota, donde desplazaremos ahí el gráfico a mostrar de Aisha y otra para el menú, para operar con las distintas opciones como si trataran de un array de opciones.
Actualizaremos el mostrar_mascota() para cambiar el gráfico de Aisha en tiempo real.
Crearemos una rutina de init_menu() y de controlar_menu(), para inicializar la botonera y para navegar por ella.
La rutina de controlar_menu() además hace uso de otras subrutinas, como menu_mover_h() y menu_mover_v(), que permiten recalcular qué botón estamos seleccionando en caso de que manejando los cursores salgamos de los menús.

//------------------------------------------------------------------------------
// TÍTULO:      TAMA03.PRG - Menú navegable simple (entregable 3)
// FECHA:       14/02/2026
// DESCRIPCIÓN: Reutiliza el esqueleto visual de TAMA02B.PRG y añade un menúnnavegable con opciones.
//              - Navegación: flechas ARRIBA/ABAJO o IZQUIERDA/DERECHA
//              - Selección: ENTER / SPACE
//              - Seleccionar una acción muestra una CG y un texto
//              - "Salir" termina la ejecución;
//
//------------------------------------------------------------------------------

PROGRAM TAMA_WAIFU;
(...)GLOBAL
(...) 
    // Estructura de estado de la mascota (gráfico actual, etc.)
    STRUCT mascota
        graph = 4;   // gráfico actualmente mostrado por `mostrar_mascota`

        // Stats de la mascota — encapsulan el estado
        STRUCT stats
            hambre = 2;
            felicidad = 3;
            disciplina = 1;
        END
    END

    // Estructura del menú de comandos
    STRUCT menu
        spacing = 64;        // separación horizontal entre columnas
        selected = 0;        // índice seleccionado (flat)
        active = 0;          // 1 = acción activa (modal)
        accion_id = -1;      // id de la acción activa
        count = 7;           // número de comandos
        cols = 4;            // columnas de la rejilla
        rows = 2;            // filas de la rejilla

        STRUCT comando[7]    // Lista de 7 comandos (Jugar, Alimentar, Estudiar, Baño, Curar, Luces, Salir)
            STRUCT label
                text = "";   // Texto a mostrar
            END
            cg = 4;           // gráfico asociado a la acción (por defecto CG_AISHA)
            action_text = ""; // texto que se muestra cuando la acción está activa
        END
    END

PRIVATE
    i = 0; // Contador de frames para actualizar reloj cada segundo

BEGIN
    // Configurar modo de video y FPS
    set_mode(configuracion.pantalla.ancho * 1000 + configuracion.pantalla.alto);
    set_fps(configuracion.fps, 0);

    // Cargamos la paleta
    load_pal(rutas.hud);

    // Cargamos los archivos FPG
    fpg.aisha = load_fpg(rutas.aisha);
    fpg.hud = load_fpg(rutas.hud);

    // Inicializamos el reloj con la hora del sistema
    get_hora();
    // Inicializamos el menú
    init_menu();

    // Iniciamos los procesos que correrán en paralelo
    mostrar_mascota();  // El personaje a mostrar
    mostrar_hud();      // Información en pantalla
    mostrar_comandos(); // La lista de comandos
    controlar_menu();   // Gestiona la entrada del menú

    // Loop principal
    LOOP
        // Actualizar contador de frames y reloj cada segundo
        i = i + 1;
        IF (i > FPS)   // La constante FPS contiene cuantos frames hubo en el último segundo, más fiable que usar configuracion.fps
            actualiza_reloj();
            i = 0;
        END

        FRAME;
    END
END
(...)//------------------------------------------------------------------------------
// PROCESS: mostrar_mascota
// DESCRIPCIÓN: Muestra la CG de la mascota (Aisha) en el centro de la pantalla
//------------------------------------------------------------------------------
PROCESS mostrar_mascota();
BEGIN
    file = fpg.aisha;   // Fichero FPG a utiiizar
    mascota.graph = CG_AISHA;   // ID del gráfico a mostrar

    // X = mitad del ancho de la pantalla, para que quede centrado
    x = configuracion.pantalla.ancho / 2;

    // Y = centro de la pantalla - mitad del alto del cuadro de diálogo para que quede justo encima del texto inferior
    y = configuracion.pantalla.alto / 2 - configuracion.cuadro_dialogo.alto / 2;

    // El gráfico mostrado se toma de `mascota.graph` para que otros procesos puedan cambiarlo
    LOOP
        graph = mascota.graph;
        FRAME;
    END
END
(...)//------------------------------------------------------------------------------
// FUNCTION: mostrar_hud
// DESCRIPCIÓN: Muestra el HUD superior con los stats del personaje y el reloj
//------------------------------------------------------------------------------
FUNCTION mostrar_hud();
PRIVATE
    INT idx;    // Índice para bucles
BEGIN
(...) 
    // Escribimos los valores de los stats (OFFSET)
    write_int(fuente.fichero, hud.label[HUD_HAMBRE].value_pos.x, hud.label[HUD_HAMBRE].value_pos.y, fuente.alineacion.izq, OFFSET mascota.stats.hambre);
    write_int(fuente.fichero, hud.label[HUD_FELICIDAD].value_pos.x, hud.label[HUD_FELICIDAD].value_pos.y, fuente.alineacion.izq, OFFSET mascota.stats.felicidad);
    write_int(fuente.fichero, hud.label[HUD_DISCIPLINA].value_pos.x, hud.label[HUD_DISCIPLINA].value_pos.y, fuente.alineacion.izq, OFFSET mascota.stats.disciplina);
(...)END

//------------------------------------------------------------------------------
// PROCESS: mostrar_comandos
// DESCRIPCIÓN: Renderiza el marco de diálogo y las opciones del menú inferior.
//              Utiliza la `STRUCT menu` y los `menu.comando[]` para ser totalmente data-driven.
//------------------------------------------------------------------------------
PROCESS mostrar_comandos();
PRIVATE
    idx = 0;                 // índice de ítem actual
    row = 0;                 // fila del ítem (idx / cols)
    col = 0;                 // columna del ítem (idx MOD cols)
    row_gap = 14;            // separación vertical entre filas
    action_text = "";        // texto de la acción activa (si hay alguna)
    action_graph = CG_AISHA; // gráfico de la acción activa (si hay alguna)
    startX = 0;              // X de la primera columna (calculada para centrar la tabla)
    startY = 0;              // Y de la primera fila   (calculada para centrar la tabla)
    px = 0;                  // X calculada para cada ítem
    py = 0;                  // Y calculada para cada ítem
    INT id_menu_textos[7];   // IDs para los textos de cada comando (se eliminan cada frame)
    id_action_text = 0;      // ID del texto de la acción activa (se elimina cada frame)
    string texto_seleccionado[50];
BEGIN
    file = fpg.hud;         // Fichero FPG a utilizar
    graph = MARCO_DIALOGO;  // ID del gráfico del marco del cuadro de diálogo

    // Calcular posiciones locales del marco (no forman parte de la STRUCT `menu`)
    x = configuracion.pantalla.ancho / 2;
    y = configuracion.pantalla.alto - configuracion.cuadro_dialogo.alto / 2;

    LOOP
        // Limpieza: borramos los textos del frame anterior usando sus IDs
        FOR (idx = 0; idx < menu.count; idx++)
            IF (id_menu_textos[idx] != 0)
                delete_text(id_menu_textos[idx]);
                id_menu_textos[idx] = 0;
            END
        END

        IF (id_action_text != 0)
            delete_text(id_action_text);
            id_action_text = 0;
        END

        // Si la acción está activa, NO dibujamos los comandos; mostramos solo el texto dentro del marco.
        IF (menu.active == 1)
            IF (menu.accion_id >= 0 AND menu.accion_id < menu.count)
                action_graph = menu.comando[menu.accion_id].cg;
                action_text = menu.comando[menu.accion_id].action_text;
            ELSE
                action_graph = CG_AISHA;
                action_text = "";
            END

            // Cambiamos el gráfico de la mascota y mostramos el texto de la acción
            mascota.graph = action_graph;
            id_action_text = write(fuente.fichero, x, y, fuente.alineacion.centro, action_text);
        ELSE
            // --- Rejilla exacta: cada columna tiene la misma X, cada fila la misma Y ---
            // startX centra la tabla horizontalmente: (cols-1)*spacing es el ancho entre extremos
            startX = x - (menu.cols - 1) * menu.spacing / 2;
            // startY centra la tabla verticalmente en el cuadro de diálogo
            startY = y - (menu.rows - 1) * row_gap / 2;

            FOR (idx = 0; idx < menu.count; idx++)
                row = idx / menu.cols;
                col = idx MOD menu.cols;
                px = startX + col * menu.spacing;
                py = startY + row * row_gap;

                IF (menu.selected == idx)
                    texto_seleccionado = "> " + menu.comando[idx].label.text;
                    id_menu_textos[idx] = write(fuente.fichero, px, py, fuente.alineacion.centro, texto_seleccionado);
                ELSE
                    id_menu_textos[idx] = write(fuente.fichero, px, py, fuente.alineacion.centro, menu.comando[idx].label.text);
                END
            END
        END

        FRAME;
    END
END

//------------------------------------------------------------------------------
// FUNCTION: init_menu
// DESCRIPCIÓN: Inicializa labels, CGs y posición del menú de comandos
//------------------------------------------------------------------------------
FUNCTION init_menu();
BEGIN
    menu.spacing = 64;
    menu.selected = 0;
    menu.active = 0;
    menu.accion_id = -1;
    menu.count = 7;
    menu.cols = 4;
    menu.rows = 2;

    menu.comando[0].label.text = "Jugar";
    menu.comando[0].cg = 015;
    menu.comando[0].action_text = "Aisha esta jugando.";

    menu.comando[1].label.text = "Alimentar";
    menu.comando[1].cg = 010;
    menu.comando[1].action_text = "Aisha esta comiendo.";

    menu.comando[2].label.text = "Estudiar";
    menu.comando[2].cg = 016;
    menu.comando[2].action_text = "Aisha esta estudiando.";

    menu.comando[3].label.text = "Baño";
    menu.comando[3].cg = 013;
    menu.comando[3].action_text = "Aisha se esta bañando.";

    menu.comando[4].label.text = "Curar";
    menu.comando[4].cg = 014;
    menu.comando[4].action_text = "Aisha toma sus medicinas.";

    menu.comando[5].label.text = "Luces";
    menu.comando[5].cg = 020;
    menu.comando[5].action_text = "Aisha se prepara para dormir.";

    menu.comando[6].label.text = "Salir";
    menu.comando[6].cg = CG_AISHA;
    menu.comando[6].action_text = "";

    return(0);
END

//------------------------------------------------------------------------------
// PROCESS: controlar_menu
// DESCRIPCIÓN: Gestiona la entrada del menú (navegación y selección). Usa la STRUCT `menu`.
//------------------------------------------------------------------------------
PROCESS controlar_menu();
BEGIN
    LOOP
        IF (NOT menu.active)
            IF (key(_right))
                menu_mover_h(+1);
            END
            IF (key(_left))
                menu_mover_h(-1);
            END
            IF (key(_down))
                menu_mover_v(+1);
            END
            IF (key(_up))
                menu_mover_v(-1);
            END

            // Selección con ENTER / SPACE
            IF (key(_enter) OR key(_space))
                IF (menu.selected == menu.count - 1)
                    exit("Hasta pronto.", 0);
                ELSE
                    menu.active = 1;
                    menu.accion_id = menu.selected;
                END
            END
        ELSE
            // Cerrar acción activa con ENTER / SPACE / ESC
            IF (key(_enter) OR key(_space) OR key(_esc))
                menu.active = 0;
                mascota.graph = CG_AISHA;
            END
        END

        // Esperamos a que se suelten todas las teclas (on-release)
        WHILE ((key(_enter) OR key(_space) OR key(_left) OR key(_right) OR key(_up) OR key(_down)))
            FRAME;
        END

        FRAME;
    END
END

//------------------------------------------------------------------------------
// FUNCTION: menu_mover_h
// DESCRIPCIÓN: Mueve el cursor horizontal (delta +1=derecha, -1=izquierda).
//              Hace wrap dentro de la misma fila respetando celdas vacías.
//------------------------------------------------------------------------------
FUNCTION menu_mover_h(INT delta);
PRIVATE
    row = 0;
    col = 0;
    new_col = 0;
    last_col = 0;
BEGIN
    col = menu.selected MOD menu.cols;
    row = menu.selected / menu.cols;

    // Última columna válida de esta fila (la fila inferior puede estar incompleta)
    last_col = menu.count - 1 - row * menu.cols;
    IF (last_col >= menu.cols)
        last_col = menu.cols - 1;
    END

    new_col = col + delta;
    IF (new_col > last_col)
        new_col = 0;        // wrap derecha → primera
    END

    IF (new_col < 0)
        new_col = last_col; // wrap izquierda → última
    END

    menu.selected = row * menu.cols + new_col;
    return(0);
END

//------------------------------------------------------------------------------
// FUNCTION: menu_mover_v
// DESCRIPCIÓN: Mueve el cursor vertical (delta +1=abajo, -1=arriba).
//              Hace wrap entre filas; si la celda destino no existe, va al último ítem válido.
//------------------------------------------------------------------------------
FUNCTION menu_mover_v(INT delta);
PRIVATE
    row = 0;
    col = 0;
    new_row = 0;
    new_idx = 0;
BEGIN
    col = menu.selected MOD menu.cols;
    row = menu.selected / menu.cols;

    new_row = row + delta;
    IF (new_row >= menu.rows)
        new_row = 0;            // wrap abajo → primera fila
    END
    IF (new_row < 0)
        new_row = menu.rows - 1; // wrap arriba → última fila
    END

    new_idx = new_row * menu.cols + col;

    // Si la celda no existe (fila inferior incompleta), va al último ítem válido
    IF (new_idx >= menu.count)
        new_idx = menu.count - 1;
    END

    menu.selected = new_idx;
    return(0);
END

El juego nos está quedando bien, pero podemos añadir aún pequeñas mejoras, como incluir una pequeña introducción al iniciar el juego, presentándose si no se detecta el fichero "save" o saludándonos si no es la primera vez que volvemos. Y lo más notorio: Implementar el guardado de los stats, porque hasta la fecha iban cambiando, pero no los estabamos guardando y se reiniciaban cada vez que volvíamos a entrar en el juego.

Para ello:

Crearemos una nueva rutina para grabar y cargar los stats en el fichero TAMA.SAV.
Crearemos una nueva rutina de introducción.
Haremos que cada acción modifique los stats de Aisha.
Mostraremos en el hud los stats de limpieza, descanso y salud, que hasta la fecha no los estábamos mostrando.

//------------------------------------------------------------------------------
// TÍTULO:      TAMA04.PRG - Persistencia de stats y pantalla de intro (entregable 4)
// FECHA:       21/02/2026
// DESCRIPCIÓN: Basado en TAMA03.PRG. Añade:
//              - Nuevos stats: limpieza, descanso, salud
//              - Fichero de guardado TAMA.SAV con los stats de la mascota
//                · Si no existe: Aisha se presenta (primera vez)
//                · Si existe:    Aisha saluda al estilo Outlaw Stars
//              - Cada acción modifica los stats y guarda al terminar
//              - normalizar_stats() mantiene todos los stats en [0..10]
//------------------------------------------------------------------------------

PROGRAM TAMA_WAIFU;

CONST
    PERMISO_ESCRITURA = "w";    // w = escritura, r = lectura, a = append (añadir al final)
    PERMISO_LECTURA   = "r";    // modo lectura para cargar el fichero SAV

    // ID de los gráficos
    CG_AISHA = 4;         // ID del gráfico que muestra a Aisha
    MARCO_DIALOGO = 16;   // ID del marco del cuadro de diálogo

    // Índices para HUD, recorremos un bucle para mostrar los textos en pantalla
    HUD_HAMBRE = 0;     // Índice para el texto "Hambre:" y su valor
    HUD_FELICIDAD = 1;  // Índice para el texto "Felicidad:" y su valor
    HUD_DISCIPLINA = 2; // Índice para el texto "Disciplina:" y su valor
    HUD_LIMPIEZA = 3;   // Índice para el texto "Limpieza:" y su valor
    HUD_DESCANSO = 4;   // Índice para el texto "Descanso:" y su valor
    HUD_SALUD = 5;      // Índice para el texto "Salud:" y su valor
    HUD_COUNT = 6;      // Número total de labels del HUD (fin del bucle)
(...)
GLOBAL
(...)    // Estructura global del HUD (labels como array)
    STRUCT hud
        (...)
        STRUCT background // Parámetros para el fondo del HUD (rectángulo negro semitransparente)
            tipo = 3;     // tipo de dibujo (rectángulo)
            color = 2;    // color del rectángulo
            opacity = 8;  // opacidad (0-15)
            region = 0;   // región para draw
            x = 0;        // posición de esquina superior izquierda
            y = 0;
            width = 320;  // ancho del rectángulo (se ajusta en tiempo de ejecución)
            height = 30;  // alto del rectángulo (ampliado para 2 filas de stats + reloj)
        END
    END

    // Estructura de rutas de assets
    STRUCT rutas
        aisha = "tama/aisha.fpg";    // Fichero con los gráficos de la chica mascota
        hud = "tama/hud.fpg";        // Fichero con los gráficos de la interfaz
        tmp_nombre = "tm_time.tmp";  // Fichero temporal para obtener la hora del sistema
        save = "tama/tama.sav";      // Fichero de guardado de stats
    END
(...)    // Estructura de estado de la mascota (gráfico actual, etc.)
    STRUCT mascota
        graph = 4;   // gráfico actualmente mostrado por `mostrar_mascota`

        // Stats de la mascota — encapsulan el estado
        STRUCT stats
            hambre = 5;
            felicidad = 5;
            disciplina = 5;
            limpieza = 10;
            descanso = 10;
            salud = 10;
        END
    END
(...)PRIVATE
    i = 0; // Contador de frames para actualizar reloj cada segundo

BEGIN
    // Configurar modo de video y FPS
    set_mode(configuracion.pantalla.ancho * 1000 + configuracion.pantalla.alto);
    set_fps(configuracion.fps, 0);

    // Cargamos la paleta
    load_pal(rutas.hud);

    // Cargamos los archivos FPG
    fpg.aisha = load_fpg(rutas.aisha);
    fpg.hud = load_fpg(rutas.hud);

    // Inicializamos el reloj con la hora del sistema
    get_hora();
    // Inicializamos el menú
    init_menu();

    introduccion();     // prepara el marco, lanza la mascota y muestra la intro; bloquea hasta que el jugador confirma

    // Iniciamos los procesos que correrán en paralelo
    mostrar_hud();      // Información en pantalla
    mostrar_comandos(); // La lista de comandos
    controlar_menu();   // Gestiona la entrada del menú

    // Loop principal
    LOOP
        // Actualizar contador de frames y reloj cada segundo
        i = i + 1;
        IF (i > FPS)   // La constante FPS contiene cuantos frames hubo en el último segundo, más fiable que usar configuracion.fps
            actualiza_reloj();
            i = 0;
        END

        FRAME;
    END
END
(...)//------------------------------------------------------------------------------
// FUNCTION: init_hud
// DESCRIPCIÓN: Inicializa posiciones y textos del HUD con 6 stats en 2 filas.
//   Fila 1 (y=5):  Hambre | Felicidad | Disciplina
//   Fila 2 (y=14): Limpieza | Descanso | Salud
//   Reloj  (y=23): Hora HH:MM:SS  |  Fecha DD/MM/AAAA
//------------------------------------------------------------------------------
FUNCTION init_hud();
BEGIN
    // --- Fila 1: Hambre, Felicidad, Disciplina ---
    hud.label[HUD_HAMBRE].pos.x = 8;
    hud.label[HUD_HAMBRE].pos.y = 5;
    hud.label[HUD_HAMBRE].text.label = "Hambre:";
    hud.label[HUD_HAMBRE].value_pos.x = 64;
    hud.label[HUD_HAMBRE].value_pos.y = 5;

    hud.label[HUD_FELICIDAD].pos.x = 109;
    hud.label[HUD_FELICIDAD].pos.y = 5;
    hud.label[HUD_FELICIDAD].text.label = "Felicidad:";
    hud.label[HUD_FELICIDAD].value_pos.x = 181;
    hud.label[HUD_FELICIDAD].value_pos.y = 5;

    hud.label[HUD_DISCIPLINA].pos.x = 210;
    hud.label[HUD_DISCIPLINA].pos.y = 5;
    hud.label[HUD_DISCIPLINA].text.label = "Disciplina:";
    hud.label[HUD_DISCIPLINA].value_pos.x = 286;
    hud.label[HUD_DISCIPLINA].value_pos.y = 5;

    // --- Fila 2: Limpieza, Descanso, Salud ---
    hud.label[HUD_LIMPIEZA].pos.x = 8;
    hud.label[HUD_LIMPIEZA].pos.y = 14;
    hud.label[HUD_LIMPIEZA].text.label = "Limpieza:";
    hud.label[HUD_LIMPIEZA].value_pos.x = 72;
    hud.label[HUD_LIMPIEZA].value_pos.y = 14;

    hud.label[HUD_DESCANSO].pos.x = 109;
    hud.label[HUD_DESCANSO].pos.y = 14;
    hud.label[HUD_DESCANSO].text.label = "Descanso:";
    hud.label[HUD_DESCANSO].value_pos.x = 181;
    hud.label[HUD_DESCANSO].value_pos.y = 14;

    hud.label[HUD_SALUD].pos.x = 210;
    hud.label[HUD_SALUD].pos.y = 14;
    hud.label[HUD_SALUD].text.label = "Salud:";
    hud.label[HUD_SALUD].value_pos.x = 254;
    hud.label[HUD_SALUD].value_pos.y = 14;

    // --- Reloj (fila 3, y=23) ---
    hud.reloj.labels[RL_HORA_LABEL].pos.x = 4;
    hud.reloj.labels[RL_HORA_LABEL].pos.y = 23;
    hud.reloj.labels[RL_HORA_LABEL].text.label = "Hora:";

    hud.reloj.values[RV_HORA].pos.x = 40;
    hud.reloj.values[RV_HORA].pos.y = 23;

    hud.reloj.labels[RL_SEP_T1].pos.x = 56;
    hud.reloj.labels[RL_SEP_T1].pos.y = 23;
    hud.reloj.labels[RL_SEP_T1].text.label = ":";

    hud.reloj.values[RV_MIN].pos.x = 64;
    hud.reloj.values[RV_MIN].pos.y = 23;

    hud.reloj.labels[RL_SEP_T2].pos.x = 80;
    hud.reloj.labels[RL_SEP_T2].pos.y = 23;
    hud.reloj.labels[RL_SEP_T2].text.label = ":";

    hud.reloj.values[RV_SEG].pos.x = 88;
    hud.reloj.values[RV_SEG].pos.y = 23;

    hud.reloj.labels[RL_FECHA_LABEL].pos.x = 140;
    hud.reloj.labels[RL_FECHA_LABEL].pos.y = 23;
    hud.reloj.labels[RL_FECHA_LABEL].text.label = "Fecha:";

    hud.reloj.values[RV_DIA].pos.x = 184;
    hud.reloj.values[RV_DIA].pos.y = 23;

    hud.reloj.labels[RL_SEP_D_M].pos.x = 200;
    hud.reloj.labels[RL_SEP_D_M].pos.y = 23;
    hud.reloj.labels[RL_SEP_D_M].text.label = "/";

    hud.reloj.values[RV_MES].pos.x = 208;
    hud.reloj.values[RV_MES].pos.y = 23;

    hud.reloj.labels[RL_SEP_M_Y].pos.x = 224;
    hud.reloj.labels[RL_SEP_M_Y].pos.y = 23;
    hud.reloj.labels[RL_SEP_M_Y].text.label = "/";

    hud.reloj.values[RV_ANO].pos.x = 232;
    hud.reloj.values[RV_ANO].pos.y = 23;

    // Ajustamos el ancho del fondo del HUD al ancho de la pantalla
    hud.background.width = configuracion.pantalla.ancho;

    return(0);
END

//------------------------------------------------------------------------------
// FUNCTION: mostrar_hud
// DESCRIPCIÓN: Muestra el HUD superior con los stats del personaje y el reloj
//------------------------------------------------------------------------------
FUNCTION mostrar_hud();
PRIVATE
    INT idx;    // Índice para bucles
BEGIN 
(...)
    // Escribimos los valores de los stats (OFFSET)
    write_int(fuente.fichero, hud.label[HUD_HAMBRE].value_pos.x, hud.label[HUD_HAMBRE].value_pos.y, fuente.alineacion.izq, OFFSET mascota.stats.hambre);
    write_int(fuente.fichero, hud.label[HUD_FELICIDAD].value_pos.x, hud.label[HUD_FELICIDAD].value_pos.y, fuente.alineacion.izq, OFFSET mascota.stats.felicidad);
    write_int(fuente.fichero, hud.label[HUD_DISCIPLINA].value_pos.x, hud.label[HUD_DISCIPLINA].value_pos.y, fuente.alineacion.izq, OFFSET mascota.stats.disciplina);
    write_int(fuente.fichero, hud.label[HUD_LIMPIEZA].value_pos.x,   hud.label[HUD_LIMPIEZA].value_pos.y,   fuente.alineacion.izq, OFFSET mascota.stats.limpieza);
    write_int(fuente.fichero, hud.label[HUD_DESCANSO].value_pos.x,   hud.label[HUD_DESCANSO].value_pos.y,   fuente.alineacion.izq, OFFSET mascota.stats.descanso);
    write_int(fuente.fichero, hud.label[HUD_SALUD].value_pos.x,      hud.label[HUD_SALUD].value_pos.y,      fuente.alineacion.izq, OFFSET mascota.stats.salud);
(...)
    return(0);
END
(...)//------------------------------------------------------------------------------
// PROCESS: controlar_menu
// DESCRIPCIÓN: Gestiona la entrada del menú (navegación y selección). Usa la STRUCT `menu`.
//------------------------------------------------------------------------------
PROCESS controlar_menu();
BEGIN
    LOOP
        IF (NOT menu.active)
            IF (key(_right))
                menu_mover_h(+1);
            END
            IF (key(_left))
                menu_mover_h(-1);
            END
            IF (key(_down))
                menu_mover_v(+1);
            END
            IF (key(_up))
                menu_mover_v(-1);
            END

            // Selección con ENTER / SPACE
            IF (key(_enter) OR key(_space))
                IF (menu.selected == menu.count - 1)
                    // Salir: guardamos y salimos
                    guardar_partida();
                    exit("Hasta pronto.", 0);
                ELSE
                    menu.active = 1;
                    menu.accion_id = menu.selected;
                END
            END
        ELSE
            // Cerrar acción activa → aplicar efecto, guardar, volver al menú
            IF (key(_enter) OR key(_space) OR key(_esc))
                aplicar_efecto(menu.accion_id);
                menu.active = 0;
                mascota.graph = CG_AISHA;
            END
        END

        // Esperamos a que se suelten todas las teclas (on-release)
        WHILE ((key(_enter) OR key(_space) OR key(_left) OR key(_right) OR key(_up) OR key(_down)))
            FRAME;
        END

        FRAME;
    END
END
(...)

//------------------------------------------------------------------------------// FUNCTION: cargar_partida
// DESCRIPCIÓN: Lee TAMA.SAV y rellena mascota.stats. Devuelve 1 si OK, 0 si no existe.
//------------------------------------------------------------------------------
FUNCTION cargar_partida();
PRIVATE
    fid = 0;
BEGIN
    fid = fopen(rutas.save, PERMISO_LECTURA);
    IF (fid == 0)
        return(0);  // fichero no existe → primera vez
    END

    fread(OFFSET mascota.stats, 1, fid);

    fclose(fid);
    return(1);
END

//------------------------------------------------------------------------------
// FUNCTION: guardar_partida
// DESCRIPCIÓN: Escribe los stats actuales de mascota en TAMA.SAV.
//------------------------------------------------------------------------------
FUNCTION guardar_partida();
PRIVATE
    fid = 0;
BEGIN
    fid = fopen(rutas.save, PERMISO_ESCRITURA);

    fwrite(OFFSET mascota.stats, 1, fid);

    fclose(fid);
    return(0);
END

//------------------------------------------------------------------------------
// FUNCTION: clamp_stat
// DESCRIPCIÓN: Devuelve `v` acotado al rango [0..10].
//------------------------------------------------------------------------------
FUNCTION clamp_stat(INT v);
BEGIN
    IF (v > 10) return(10); END
    IF (v <  0) return(0);  END
    return(v);
END

//------------------------------------------------------------------------------
// FUNCTION: normalizar_stats
// DESCRIPCIÓN: Clampea todos los stats al rango [0..10].
//------------------------------------------------------------------------------
FUNCTION normalizar_stats();
BEGIN
    mascota.stats.hambre     = clamp_stat(mascota.stats.hambre);
    mascota.stats.felicidad  = clamp_stat(mascota.stats.felicidad);
    mascota.stats.disciplina = clamp_stat(mascota.stats.disciplina);
    mascota.stats.limpieza   = clamp_stat(mascota.stats.limpieza);
    mascota.stats.descanso   = clamp_stat(mascota.stats.descanso);
    mascota.stats.salud      = clamp_stat(mascota.stats.salud);
    return(0);
END

//------------------------------------------------------------------------------
// FUNCTION: aplicar_efecto
// DESCRIPCIÓN: Aplica los cambios de stats correspondientes a la acción `id`.
//              Tras modificar los valores llama a normalizar_stats() y guarda.
//   0 Jugar     → felicidad+2, disciplina-1, limpieza-1, descanso-2
//   1 Alimentar → hambre+2
//   2 Estudiar  → felicidad-1, disciplina+2, descanso-2
//   3 Baño      → limpieza=10, descanso-1
//   4 Curar     → salud=10
//   5 Luces     → descanso=10
//------------------------------------------------------------------------------
FUNCTION aplicar_efecto(INT id_efecto);
BEGIN
    SWITCH (id_efecto)
        CASE 0: // Jugar
            mascota.stats.felicidad  = mascota.stats.felicidad  + 2;
            mascota.stats.disciplina = mascota.stats.disciplina - 1;
            mascota.stats.limpieza   = mascota.stats.limpieza   - 1;
            mascota.stats.descanso   = mascota.stats.descanso   - 2;
        END
        CASE 1: // Alimentar
            mascota.stats.hambre = mascota.stats.hambre + 2;
        END
        CASE 2: // Estudiar
            mascota.stats.felicidad  = mascota.stats.felicidad  - 1;
            mascota.stats.disciplina = mascota.stats.disciplina + 2;
            mascota.stats.descanso   = mascota.stats.descanso   - 2;
        END
        CASE 3: // Baño
            mascota.stats.limpieza = 10;
            mascota.stats.descanso = mascota.stats.descanso - 1;
        END
        CASE 4: // Curar
            mascota.stats.salud = 10;
        END
        CASE 5: // Luces
            mascota.stats.descanso = 10;
        END
    END

    normalizar_stats();
    guardar_partida();
    return(0);
END

//------------------------------------------------------------------------------
// FUNCTION: introduccion
// DESCRIPCIÓN: Muestra el sprite de la mascota. Bloquea hasta que el jugador confirma.
//------------------------------------------------------------------------------
FUNCTION introduccion();
BEGIN
    file  = fpg.hud;
    graph = MARCO_DIALOGO;
    x     = configuracion.pantalla.ancho / 2;
    y     = configuracion.pantalla.alto - configuracion.cuadro_dialogo.alto / 2;

    mostrar_mascota();  // lanzamos el sprite de Aisha antes de la intro (PROCESS → paralelo)

    intro_aisha();      // presentación o saludo; bloquea hasta que el jugador pulsa ENTER/SPACE

    graph = 0;          // quitamos el gráfico del proceso main
    return(0);
END

//------------------------------------------------------------------------------
// FUNCTION: intro_aisha
// DESCRIPCIÓN: Intenta cargar TAMA.SAV.
//              · Si no existe → presentación de Aisha (primera vez)
//              · Si existe    → saludo al estilo Outlaw Stars
//              Espera a que el jugador pulse ENTER/SPACE y hace on-release.
//              Nota: el proceso main ya tiene asignado el gráfico MARCO_DIALOGO
//              y mostrar_mascota() ya está corriendo; esta función solo escribe
//              texto y llama a FRAME.
//------------------------------------------------------------------------------
FUNCTION intro_aisha();
PRIVATE
    save_existe = 0;
    id_l1 = 0;
    id_l2 = 0;
    cx = 0;
    cy = 0;
BEGIN
    file = fpg.hud;         // Fichero FPG a utilizar
    graph = MARCO_DIALOGO;  // ID del gráfico del marco del cuadro de diálogo

    // Calcular posiciones locales del marco (no forman parte de la STRUCT `menu`)
    x = configuracion.pantalla.ancho / 2;
    y = configuracion.pantalla.alto - configuracion.cuadro_dialogo.alto / 2;

    cx = configuracion.pantalla.ancho / 2;
    cy = configuracion.pantalla.alto - configuracion.cuadro_dialogo.alto / 2;

    save_existe = cargar_partida();

    IF (save_existe == 0)
        // Primera vez — presentación
        id_l1 = write(fuente.fichero, cx, cy - 8, fuente.alineacion.centro,
                      "¡Soy Aisha Clan-Clan, orgullo de");
        id_l2 = write(fuente.fichero, cx, cy + 4, fuente.alineacion.centro,
                      "los Ctarl-Ctarl! ¡Cuídame bien!");
    ELSE
        // Ya existe partida — saludo tsundere de Outlaw Stars
        id_l1 = write(fuente.fichero, cx, cy - 8, fuente.alineacion.centro,
                      "¡Ah, has vuelto! Era hora,");
        id_l2 = write(fuente.fichero, cx, cy + 4, fuente.alineacion.centro,
                      "humano. ¡No me hagas esperar!");
    END

    // Esperamos a que el jugador pulse ENTER/SPACE
    WHILE (NOT (key(_enter) OR key(_space)))
        FRAME;
    END

    // On-release
    WHILE (key(_enter) OR key(_space))
        FRAME;
    END

    delete_text(id_l1);
    delete_text(id_l2);
    return(0);
END

Con todo esto ya tenemos algo bastante funcional, pero aún nos falta lo más básico: Implementar el sistema de cansancio y sueño.

Para ello:

Crearemos una estructura para controlar los estados del sueño y una rutina comprobar_sueno() que tendremos que controlar en el bucle principal.
Nos aseguraremos que si Aisha está durmiendo, sólo podamos salir del juego.
Alteraremos la introducción para ver a Aisha durmiendo si al volver a entrar aún no está descansada.

//------------------------------------------------------------------------------
// TÍTULO:      TAMA05.PRG - Ciclo de sueño de Aisha (entregable 5)

// FECHA:       24/02/2026
// DESCRIPCIÓN: Basado en TAMA04.PRG. Añade:
//              - Estado de sueño persistido en el SAV
//              - Acción de Luces implementada:
//                · Mientras duerme: gráfico 21, solo el comando "Salir" es usable
//                · Se despierta automáticamente a las 8 AM del día siguiente
//                · Si descanso=0: siesta de 3 horas.
//              - Auto-duerme a las 2 AM si Aisha está despierta
//              - Despierta a las 8 AM.
//              - Si el jugador se conecta mientras Aisha duerme, se le muestra durmiendo.
//------------------------------------------------------------------------------

PROGRAM TAMA_WAIFU;

CONST
    PERMISO_ESCRITURA = "w";    // w = escritura, r = lectura, a = append (añadir al final)
    PERMISO_LECTURA   = "r";    // modo lectura para cargar el fichero SAV

    // ID de los gráficos
    CG_AISHA = 4;         // ID del gráfico que muestra a Aisha
    MARCO_DIALOGO = 16;   // ID del marco del cuadro de diálogo
    CG_DURMIENDO = 21;    // ID del gráfico que muestra a Aisha durmiendo

    // Horario del ciclo de sueño
    HORA_DORMIR   = 2;  // Hora a la que Aisha se duerme automáticamente (2 AM)
    HORA_AMANECER = 8;  // Hora a la que Aisha se despierta normalmente (8 AM)
    HORAS_SIESTA  = 3;  // Horas que duerme si descanso=0 (siesta)

    // Índice del comando "Salir" — único comando visible cuando Aisha duerme
    CMD_SALIR = 6;

    // Motivo del sueño — parámetro de activar_sueno()
    SUENO_LUCES    = 0;  // Luces manual      → día siguiente a las HORA_AMANECER
    SUENO_NOCTURNO = 1;  // Ventana 2–8 AM    → mismo día a las HORA_AMANECER
    SUENO_SIESTA   = 2;  // Agotamiento (descanso=0) → +HORAS_SIESTA horas

(...)GLOBAL
(...)    // Estructura de rutas de assets
    STRUCT rutas
        aisha = "tama/aisha.fpg";    // Fichero con los gráficos de la chica mascota
        hud = "tama/hud.fpg";        // Fichero con los gráficos de la interfaz
        tmp_nombre = "tm_time.tmp";  // Fichero temporal para obtener la hora del sistema
        save = "tama/tamav2.sav";     // Fichero de guardado de stats (nuevo formato para TAMA05.PRG)
    END
(...)    // Estructura de estado de la mascota (gráfico actual, etc.)
    STRUCT mascota
        graph = 4;   // gráfico actualmente mostrado por `mostrar_mascota`

        // Stats de la mascota — encapsulan el estado
        STRUCT stats
            hambre = 5;
            felicidad = 5;
            disciplina = 5;
            limpieza = 10;
            descanso = 10;
            salud = 10;
        END

        // Estado de sueño — se persiste en el SAV junto con los stats
        STRUCT sueno
            durmiendo = 0;     // 1 si Aisha está durmiendo, 0 si está despierta
            despertar_dia = 0; // día del reloj en que se despertará
            despertar_hora = 8; // hora del reloj en que se despertará
        END
    END

(...)PRIVATE
    i = 0; // Contador de frames para actualizar reloj cada segundo

BEGIN
(...)    // Loop principal
    LOOP
        // Actualizar contador de frames y reloj cada segundo
        i = i + 1;
        IF (i > FPS)   // La constante FPS contiene cuantos frames hubo en el último segundo, más fiable que usar configuracion.fps
            actualiza_reloj();
            comprobar_sueno(); // Comprueba auto-sueño (2 AM) y auto-despertar
            i = 0;
        END

        FRAME;
    END
END
(...)//------------------------------------------------------------------------------
// PROCESS: mostrar_comandos
// DESCRIPCIÓN: Renderiza el marco de diálogo y las opciones del menú inferior.
//              Utiliza la `STRUCT menu` y los `menu.comando[]` para ser totalmente data-driven.
//              Cuando Aisha está durmiendo: muestra sólo "Salir" con gráfico 21.
//------------------------------------------------------------------------------
PROCESS mostrar_comandos();
PRIVATE
(...)BEGIN
(...)    LOOP
        (...)        // Si la acción está activa, NO dibujamos los comandos; mostramos solo el texto dentro del marco.
        IF (menu.active == 1)
            IF (menu.accion_id >= 0 AND menu.accion_id < menu.count)
                action_graph = menu.comando[menu.accion_id].cg;
                action_text = menu.comando[menu.accion_id].action_text;
            ELSE
                action_graph = CG_AISHA;
                action_text = "";
            END

            // Cambiamos el gráfico de la mascota y mostramos el texto de la acción
            mascota.graph = action_graph;
            id_action_text = write(fuente.fichero, x, y, fuente.alineacion.centro, action_text);
        ELSE
            IF (mascota.sueno.durmiendo == 1)
                // Modo durmiendo: gráfico 21, solo el comando "Salir" activo
                // `controlar_menu` también fuerza menu.selected = CMD_SALIR, aquí lo reforzamos
                mascota.graph = CG_DURMIENDO;
                menu.selected = CMD_SALIR;
                texto_seleccionado = "> " + menu.comando[CMD_SALIR].label.text;
                id_menu_textos[CMD_SALIR] = write(fuente.fichero, x, y, fuente.alineacion.centro, texto_seleccionado);
            ELSE
                // --- Rejilla exacta: cada columna tiene la misma X, cada fila la misma Y ---
                // startX centra la tabla horizontalmente: (cols-1)*spacing es el ancho entre extremos
                startX = x - (menu.cols - 1) * menu.spacing / 2;
                // startY centra la tabla verticalmente en el cuadro de diálogo
                startY = y - (menu.rows - 1) * row_gap / 2;

                FOR (idx = 0; idx < menu.count; idx++)
                    row = idx / menu.cols;
                    col = idx MOD menu.cols;
                    px = startX + col * menu.spacing;
                    py = startY + row * row_gap;

                    IF (menu.selected == idx)
                        texto_seleccionado = "> " + menu.comando[idx].label.text;
                        id_menu_textos[idx] = write(fuente.fichero, px, py, fuente.alineacion.centro, texto_seleccionado);
                    ELSE
                        id_menu_textos[idx] = write(fuente.fichero, px, py, fuente.alineacion.centro, menu.comando[idx].label.text);
                    END
                END
            END
        END

        FRAME;
    END
END
(...)//------------------------------------------------------------------------------
// PROCESS: controlar_menu
// DESCRIPCIÓN: Gestiona la entrada del menú (navegación y selección). Usa la STRUCT `menu`.
//              Cuando Aisha está durmiendo: bloquea la navegación; solo ENTER sobre
//              "Salir" (forzado por mostrar_comandos) permite salir del programa.
//------------------------------------------------------------------------------
PROCESS controlar_menu();
BEGIN
    LOOP
        IF (NOT menu.active)
            // Navegación: solo permitida si Aisha está despierta
            IF (mascota.sueno.durmiendo == 0)
                IF (key(_right))
                    menu_mover_h(+1);
                END
                IF (key(_left))
                    menu_mover_h(-1);
                END
                IF (key(_down))
                    menu_mover_v(+1);
                END
                IF (key(_up))
                    menu_mover_v(-1);
                END
            END

            // Selección con ENTER / SPACE
            // (cuando duerme, mostrar_comandos fuerza menu.selected = CMD_SALIR)
            IF (key(_enter) OR key(_space))
                IF (menu.selected == menu.count - 1)
                    // Salir: guardamos y salimos
                    guardar_partida();
                    exit("Hasta pronto.", 0);
                ELSE
                    menu.active = 1;
                    menu.accion_id = menu.selected;
                END
            END
        ELSE
            // Cerrar acción activa → aplicar efecto, guardar, volver al menú
            IF (key(_enter) OR key(_space) OR key(_esc))
                aplicar_efecto(menu.accion_id);
                menu.active = 0;
                // Solo restauramos CG_AISHA si no está durmiendo;
                // si se acaba de ejecutar Luces, `activar_sueno` ya puso CG_DURMIENDO
                IF (mascota.sueno.durmiendo == 0)
                    mascota.graph = CG_AISHA;
                END
            END
        END

        // Esperamos a que se suelten todas las teclas (on-release)
        WHILE ((key(_enter) OR key(_space) OR key(_left) OR key(_right) OR key(_up) OR key(_down)))
            FRAME;
        END

        FRAME;
    END
END
(...)//------------------------------------------------------------------------------
// FUNCTION: cargar_partida
// DESCRIPCIÓN: Lee tamav2.sav y rellena mascota.stats + mascota.sueno.
//              Devuelve 1 si OK, 0 si el fichero no existe (primera vez).
//              Formato del SAV:
//                · 6 campos  → mascota.stats  (hambre..salud)
//                · 3 campos  → mascota.sueno  (durmiendo, despertar_dia, despertar_hora)
//------------------------------------------------------------------------------
FUNCTION cargar_partida();
PRIVATE
    fid = 0;
BEGIN
    fid = fopen(rutas.save, PERMISO_LECTURA);
    IF (fid == 0)
        return(0);  // fichero no existe → primera vez
    END

    fread(OFFSET mascota.stats, 1, fid);
    fread(OFFSET mascota.sueno, 1, fid);

    fclose(fid);
    return(1);
END

//------------------------------------------------------------------------------
// FUNCTION: guardar_partida
// DESCRIPCIÓN: Escribe los stats actuales y el estado de sueño de la mascota
//              en tamav2.sav con el mismo formato que cargar_partida.
//              Escribe cada campo individualmente (count=1) porque sizeof de
//              una STRUCT no-array vale 1 en DIV2.
//------------------------------------------------------------------------------
FUNCTION guardar_partida();
PRIVATE
    fid = 0;
BEGIN
    fid = fopen(rutas.save, PERMISO_ESCRITURA);

    fwrite(OFFSET mascota.stats, 1, fid);  // 6 stats
    fwrite(OFFSET mascota.sueno, 1, fid);  // 3 campos de sueño

    fclose(fid);
    return(0);
END
(...)//------------------------------------------------------------------------------
// FUNCTION: aplicar_efecto
// DESCRIPCIÓN: Aplica los cambios de stats correspondientes a la acción `id`.
//              Tras modificar los valores llama a normalizar_stats() y guarda.
//   0 Jugar     → felicidad+2, disciplina-1, limpieza-1, descanso-2
//   1 Alimentar → hambre+2
//   2 Estudiar  → felicidad-1, disciplina+2, descanso-2
//   3 Baño      → limpieza=10, descanso-1
//   4 Curar     → salud=10
//   5 Luces     → activa el sueño (comprueba descanso antes), luego descanso=10
//------------------------------------------------------------------------------
FUNCTION aplicar_efecto(INT id_efecto);
BEGIN
    SWITCH (id_efecto)
        CASE 0: // Jugar
            mascota.stats.felicidad  = mascota.stats.felicidad  + 2;
            mascota.stats.disciplina = mascota.stats.disciplina - 1;
            mascota.stats.limpieza   = mascota.stats.limpieza   - 1;
            mascota.stats.descanso   = mascota.stats.descanso   - 2;
        END
        CASE 1: // Alimentar
            mascota.stats.hambre = mascota.stats.hambre + 2;
        END
        CASE 2: // Estudiar
            mascota.stats.felicidad  = mascota.stats.felicidad  - 1;
            mascota.stats.disciplina = mascota.stats.disciplina + 2;
            mascota.stats.descanso   = mascota.stats.descanso   - 2;
        END
        CASE 3: // Baño
            mascota.stats.limpieza = 10;
            mascota.stats.descanso = mascota.stats.descanso - 1;
        END
        CASE 4: // Curar
            mascota.stats.salud = 10;
        END
        CASE 5: // Luces → poner a dormir a Aisha (día siguiente a las HORA_AMANECER)
            activar_sueno(SUENO_LUCES);
        END
    END

    normalizar_stats();
    guardar_partida();
    return(0);
END

//------------------------------------------------------------------------------
// FUNCTION: activar_sueno
// DESCRIPCIÓN: Pone a Aisha a dormir calculando la hora de despertar según el motivo.
//   tipo = SUENO_LUCES    → día siguiente a las HORA_AMANECER (Luces manual)
//   tipo = SUENO_NOCTURNO → mismo día a las HORA_AMANECER    (ventana 2–8 AM)
//   tipo = SUENO_SIESTA   → +HORAS_SIESTA horas desde ahora  (agotamiento)
//   En todos los casos: descanso → 10, gráfico → CG_DURMIENDO, guarda partida.
//------------------------------------------------------------------------------
FUNCTION activar_sueno(INT tipo);
PRIVATE
    suma_hora;  // hora de despertar calculada (antes del MOD 24)
BEGIN
    mascota.sueno.durmiendo = 1;

    IF (tipo == SUENO_SIESTA)
        // Agotamiento: siesta de HORAS_SIESTA horas desde ahora
        suma_hora = reloj.hora + HORAS_SIESTA;
        mascota.sueno.despertar_hora = suma_hora MOD 24;
        IF (suma_hora >= 24)
            mascota.sueno.despertar_dia = reloj.dia + 1; // cruza la medianoche
        ELSE
            mascota.sueno.despertar_dia = reloj.dia;
        END
    ELSE
        IF (tipo == SUENO_NOCTURNO)
            // Ventana 2–8 AM: se despierta a las 8 AM del mismo día
            mascota.sueno.despertar_hora = HORA_AMANECER;
            mascota.sueno.despertar_dia  = reloj.dia;
        ELSE
            // SUENO_LUCES: Luces manual → día siguiente a las HORA_AMANECER
            mascota.sueno.despertar_hora = HORA_AMANECER;
            mascota.sueno.despertar_dia  = reloj.dia + 1;
        END
    END

    // Restauramos el descanso al irse a la cama (siempre, independientemente de la duración)
    mascota.stats.descanso = 10;

    mascota.graph = CG_DURMIENDO;
    guardar_partida();
    return(0);
END

//------------------------------------------------------------------------------
// FUNCTION: comprobar_sueno
// DESCRIPCIÓN: Llamada cada segundo desde el loop principal. Gestiona:
//              · Auto-despertar cuando se cumple la hora programada
//              · Auto-sueño nocturno: si la hora está en [HORA_DORMIR, HORA_AMANECER)
//              · Auto-sueño por agotamiento: si descanso=0 a cualquier hora
//------------------------------------------------------------------------------
FUNCTION comprobar_sueno();
BEGIN
    // --- Auto-despertar ---
    IF (mascota.sueno.durmiendo == 1)
        // Comprobamos si ya llegó la hora de despertar
        // (día mayor, o mismo día y hora mayor-igual que despertar_hora)
        IF (reloj.dia > mascota.sueno.despertar_dia OR
                (reloj.dia == mascota.sueno.despertar_dia AND
                 reloj.hora >= mascota.sueno.despertar_hora))
            mascota.sueno.durmiendo = 0;
            mascota.graph = CG_AISHA;
            menu.selected = 0;      // resetamos el cursor al inicio del menú
            guardar_partida();
        END
    END

    // --- Auto-sueño (solo si Aisha está despierta) ---
    IF (mascota.sueno.durmiendo == 0)
        // Ventana nocturna [HORA_DORMIR, HORA_AMANECER): se despierta ese mismo día a las 8 AM
        IF (reloj.hora >= HORA_DORMIR AND reloj.hora < HORA_AMANECER)
            activar_sueno(SUENO_NOCTURNO);
        END
        // Agotamiento (descanso=0) a cualquier hora: siesta de HORAS_SIESTA horas
        IF (mascota.stats.descanso == 0)
            activar_sueno(SUENO_SIESTA);
        END
    END

    return(0);
END
(...)//------------------------------------------------------------------------------
// FUNCTION: intro_aisha
// DESCRIPCIÓN: Intenta cargar tamav2.sav.
//              · Si no existe → presentación de Aisha (primera vez)
//              · Si existe y durmiendo=1 → pantalla de sueño (gráfico 21)
//              · Si existe y durmiendo=0 → saludo al estilo Outlaw Stars
//              Espera a que el jugador pulse ENTER/SPACE y hace on-release.
//              Nota: el proceso main ya tiene asignado el gráfico MARCO_DIALOGO
//              y mostrar_mascota() ya está corriendo; esta función solo escribe
//              texto y llama a FRAME.
//------------------------------------------------------------------------------
FUNCTION intro_aisha();
PRIVATE
    save_existe = 0;
    id_l1 = 0;
    id_l2 = 0;
    cx = 0;
    cy = 0;
BEGIN
    file = fpg.hud;         // Fichero FPG a utilizar
    graph = MARCO_DIALOGO;  // ID del gráfico del marco del cuadro de diálogo

    // Calcular posiciones locales del marco (no forman parte de la STRUCT `menu`)
    x = configuracion.pantalla.ancho / 2;
    y = configuracion.pantalla.alto - configuracion.cuadro_dialogo.alto / 2;

    cx = configuracion.pantalla.ancho / 2;
    cy = configuracion.pantalla.alto - configuracion.cuadro_dialogo.alto / 2;

    save_existe = cargar_partida();  // carga stats + sueno si el SAV existe

    IF (save_existe == 1 AND mascota.sueno.durmiendo == 1)
        // Aisha está durmiendo — mostramos su gráfico 21 y un mensaje
        mascota.graph = CG_DURMIENDO;
        id_l1 = write(fuente.fichero, cx, cy, fuente.alineacion.centro,
                      "Aisha está durmiendo.");
    ELSE
        IF (save_existe == 0)
            // Primera vez — presentación
            id_l1 = write(fuente.fichero, cx, cy - 8, fuente.alineacion.centro,
                          "¡Soy Aisha Clan-Clan, orgullo de");
            id_l2 = write(fuente.fichero, cx, cy + 4, fuente.alineacion.centro,
                          "los Ctarl-Ctarl! ¡Cuídame bien!");
        ELSE
            // Ya existe partida y Aisha está despierta — saludo tsundere de Outlaw Stars
            id_l1 = write(fuente.fichero, cx, cy - 8, fuente.alineacion.centro,
                          "¡Ah, has vuelto! Era hora,");
            id_l2 = write(fuente.fichero, cx, cy + 4, fuente.alineacion.centro,
                          "humano. ¡No me hagas esperar!");
        END
    END

    // Esperamos a que el jugador pulse ENTER/SPACE
    WHILE (NOT (key(_enter) OR key(_space)))
        FRAME;
    END

    // On-release
    WHILE (key(_enter) OR key(_space))
        FRAME;
    END

    delete_text(id_l1);
    IF (id_l2 != 0)
        delete_text(id_l2);
    END
    return(0);
END

Con todo ello ya tenemos un juego plenamente funcional. No será el GOTY 2026, pero lo que tiene que hacer, lo hace. Por último os presento una última versión, que sirve únicamente para pulir/mejorar varios aspectos:

Eventos aleatorios en segundo plano (puede recibir regalos, enfermad, comer por su cuenta..).
Sistema de cooldown para que sus stats cambién mientras juguemos. Es decir, si dejas a Aisha todo el día en segundo plano, le entrará hambre, por ejemplo.
Semilla aleatoria inicializada por la hora (sirve para calcular los números aleatorios)
Realizamos una copia de seguridad del SAV antes de sobrescribir (archivo .bak) y eliminación del fichero temporal de hora.
El HUD pasa a ser un PROCESS que se refresca cada frame y ahora muestra un contador del tiempo restante mientras Aisha duerme (minutos_restantes_sueno()).

//------------------------------------------------------------------------------
// TÍTULO:      TAMA06.PRG - Ciclo de sueño y eventos (entregable 6)
// FECHA:       30/05/2026
// DESCRIPCIÓN: Basado en TAMA05.PRG. Mejora y añade:
//              - Añade eventos aleatorios en segundo plano (regalo, enfermedad,
//                comida, suciedad) con cooldown.
//              - Inicializa la semilla aleatoria con la hora del sistema.
//              - Guarda una copia de seguridad del SAV antes de sobrescribir
//                (archivo .bak).
//              - HUD convertido a `PROCESS` y refrescado dinámicamente cada frame.
//              - Muestra contador de tiempo restante mientras Aisha está durmiendo.
//              - Añade decremento horario de stats (hambre/descanso/limpieza) cada
//                hora y guarda automáticamente.
//              - Elimina el fichero temporal usado para obtener la hora.
//              - Nuevas funciones: `decrementar_stats()`, `minutos_restantes_sueno()`,
//                `disparar_evento()` y `PROCESS eventos_aleatorios()`.
//              - Varias mejoras de gestión de texto y limpieza de recursos.
//------------------------------------------------------------------------------

PROGRAM TAMA_WAIFU;

CONST
(...)    // Motivo del sueño — parámetro de activar_sueno()
    SUENO_LUCES    = 0;  // Luces manual      → día siguiente a las HORA_AMANECER
    SUENO_NOCTURNO = 1;  // Ventana 2–8 AM    → mismo día a las HORA_AMANECER
    SUENO_SIESTA   = 2;  // Agotamiento (descanso=0) → +HORAS_SIESTA horas

    // Eventos aleatorios
    EVENT_PROB_PCT = 2;      // probabilidad (%) por minuto de que ocurra un evento
    EVENT_MIN_INTERVAL = 10; // minutos mínimos entre eventos

(...)GLOBAL
(...)PRIVATE
    i = 0; // Contador de frames para actualizar reloj cada segundo

BEGIN
    // Configurar modo de video y FPS
    set_mode(configuracion.pantalla.ancho * 1000 + configuracion.pantalla.alto);
    set_fps(configuracion.fps, 0);

    // Cargamos la paleta
    load_pal(rutas.hud);

    // Cargamos los archivos FPG
    fpg.aisha = load_fpg(rutas.aisha);
    fpg.hud = load_fpg(rutas.hud);

    // Inicializamos el reloj con la hora del sistema
    get_hora();
    // Inicializamos la semilla aleatoria con la hora actual
    rand_seed(reloj.hora * 3600 + reloj.minutos * 60 + reloj.segundos);
    // Inicializamos el menú
    init_menu();

    introduccion();     // prepara el marco, lanza la mascota y muestra la intro; bloquea hasta que el jugador confirma

    // Iniciamos los procesos que correrán en paralelo
    mostrar_hud();      // Información en pantalla
    mostrar_comandos(); // La lista de comandos
    eventos_aleatorios(); // Dispara eventos aleatorios en segundo plano
    controlar_menu();   // Gestiona la entrada del menú

    // Loop principal
    LOOP
        // Actualizar contador de frames y reloj cada segundo
        i = i + 1;
        IF (i > FPS)   // La constante FPS contiene cuantos frames hubo en el último segundo, más fiable que usar configuracion.fps
            actualiza_reloj();
            comprobar_sueno(); // Comprueba auto-sueño (2 AM) y auto-despertar
            // Decremento horario de stats: sólo en el cambio de hora (minutos==0 && segundos==0)
            IF (reloj.minutos == 0 AND reloj.segundos == 0)
                decrementar_stats();
            END
            i = 0;
        END

        FRAME;
    END
END

//------------------------------------------------------------------------------
// FUNCTION: get_hora
// DESCRIPCIÓN: Rellena la STRUCT `reloj` con la fecha/hora actual del sistema.
// Para ello creamos un fichero temporal y consultamos su fecha de modificación
//------------------------------------------------------------------------------
FUNCTION get_hora();
PRIVATE
    tmp_dato;
    tmp_id;
BEGIN
    tmp_dato = 0;
    tmp_id = fopen(rutas.tmp_nombre, PERMISO_ESCRITURA);
    fwrite(OFFSET tmp_dato, sizeof(tmp_dato), tmp_id);
    fclose(tmp_id);

    get_fileinfo(rutas.tmp_nombre);

    reloj.dia = fileinfo.day;
    reloj.mes = fileinfo.month;
    reloj.ano = fileinfo.year;

    reloj.hora = fileinfo.hour;
    reloj.minutos = fileinfo.min;
    reloj.segundos = fileinfo.sec;

    // Eliminamos el fichero temporal creado para obtener la hora
    remove(rutas.tmp_nombre);

    return(0);
END
(...)//------------------------------------------------------------------------------
// PROCESS: mostrar_hud
// DESCRIPCIÓN: Muestra y refresca el HUD superior con los stats del personaje y el reloj
//------------------------------------------------------------------------------
PROCESS mostrar_hud();
PRIVATE
    INT idx;    // Índice para bucles
BEGIN
    // Inicializamos los componentes del HUD
    init_hud();

    // Dibujamos un fondo semitransparente y los labels (una sola vez)
    draw(hud.background.tipo, hud.background.color, hud.background.opacity, hud.background.region,
            hud.background.x, hud.background.y,
            hud.background.x + hud.background.width, hud.background.y + hud.background.height);

    // Escribimos los labels del HUD uno a uno
    FOR (idx = 0; idx < HUD_COUNT; idx++)
        write(fuente.fichero, hud.label[idx].pos.x, hud.label[idx].pos.y, fuente.alineacion.izq, hud.label[idx].text.label);
    END

    // Escribimos los labels del reloj uno a uno
    FOR (idx = 0; idx < RL_COUNT; idx++)
        write(fuente.fichero, hud.reloj.labels[idx].pos.x, hud.reloj.labels[idx].pos.y, fuente.alineacion.izq, hud.reloj.labels[idx].text.label);
    END

    // Bucle principal del HUD: actualiza valores dinámicos cada frame
    LOOP
        // Escribimos (actualizamos) los valores de los stats (OFFSET)
        write_int(fuente.fichero, hud.label[HUD_HAMBRE].value_pos.x, hud.label[HUD_HAMBRE].value_pos.y, fuente.alineacion.izq, OFFSET mascota.stats.hambre);
        write_int(fuente.fichero, hud.label[HUD_FELICIDAD].value_pos.x, hud.label[HUD_FELICIDAD].value_pos.y, fuente.alineacion.izq, OFFSET mascota.stats.felicidad);
        write_int(fuente.fichero, hud.label[HUD_DISCIPLINA].value_pos.x, hud.label[HUD_DISCIPLINA].value_pos.y, fuente.alineacion.izq, OFFSET mascota.stats.disciplina);
        write_int(fuente.fichero, hud.label[HUD_LIMPIEZA].value_pos.x,   hud.label[HUD_LIMPIEZA].value_pos.y,   fuente.alineacion.izq, OFFSET mascota.stats.limpieza);
        write_int(fuente.fichero, hud.label[HUD_DESCANSO].value_pos.x,   hud.label[HUD_DESCANSO].value_pos.y,   fuente.alineacion.izq, OFFSET mascota.stats.descanso);
        write_int(fuente.fichero, hud.label[HUD_SALUD].value_pos.x,      hud.label[HUD_SALUD].value_pos.y,      fuente.alineacion.izq, OFFSET mascota.stats.salud);

        // Escribimos (actualizamos) los valores del reloj (OFFSET)
        write_int(fuente.fichero, hud.reloj.values[RV_HORA].pos.x, hud.reloj.values[RV_HORA].pos.y, fuente.alineacion.izq, OFFSET reloj.hora);
        write_int(fuente.fichero, hud.reloj.values[RV_MIN].pos.x, hud.reloj.values[RV_MIN].pos.y, fuente.alineacion.izq, OFFSET reloj.minutos);
        write_int(fuente.fichero, hud.reloj.values[RV_SEG].pos.x, hud.reloj.values[RV_SEG].pos.y, fuente.alineacion.izq, OFFSET reloj.segundos);
        write_int(fuente.fichero, hud.reloj.values[RV_DIA].pos.x, hud.reloj.values[RV_DIA].pos.y, fuente.alineacion.izq, OFFSET reloj.dia);
        write_int(fuente.fichero, hud.reloj.values[RV_MES].pos.x, hud.reloj.values[RV_MES].pos.y, fuente.alineacion.izq, OFFSET reloj.mes);
        write_int(fuente.fichero, hud.reloj.values[RV_ANO].pos.x, hud.reloj.values[RV_ANO].pos.y, fuente.alineacion.izq, OFFSET reloj.ano);

        FRAME;
    END
END

//------------------------------------------------------------------------------
// PROCESS: mostrar_comandos
// DESCRIPCIÓN: Renderiza el marco de diálogo y las opciones del menú inferior.
//              Utiliza la `STRUCT menu` y los `menu.comando[]` para ser totalmente data-driven.
//              Cuando Aisha está durmiendo: muestra sólo "Salir" con gráfico 21.
//------------------------------------------------------------------------------
PROCESS mostrar_comandos();
PRIVATE
    idx = 0;                 // índice de ítem actual
    row = 0;                 // fila del ítem (idx / cols)
    col = 0;                 // columna del ítem (idx MOD cols)
    row_gap = 14;            // separación vertical entre filas
    action_text = "";        // texto de la acción activa (si hay alguna)
    action_graph = CG_AISHA; // gráfico de la acción activa (si hay alguna)
    startX = 0;              // X de la primera columna (calculada para centrar la tabla)
    startY = 0;              // Y de la primera fila   (calculada para centrar la tabla)
    px = 0;                  // X calculada para cada ítem
    py = 0;                  // Y calculada para cada ítem
    INT id_menu_textos[7];   // IDs para los textos de cada comando (se eliminan cada frame)
    id_action_text = 0;      // ID del texto de la acción activa (se elimina cada frame)
    id_sleep_countdown = 0;  // ID del texto del contador de sueño (se elimina cada frame)
    string texto_seleccionado[50];
    string countdown_text[50];
    rem_min = 0;
    h = 0;
    m = 0;
BEGIN
    file = fpg.hud;         // Fichero FPG a utilizar
    graph = MARCO_DIALOGO;  // ID del gráfico del marco del cuadro de diálogo

    // Calcular posiciones locales del marco (no forman parte de la STRUCT `menu`)
    x = configuracion.pantalla.ancho / 2;
    y = configuracion.pantalla.alto - configuracion.cuadro_dialogo.alto / 2;

    LOOP
        // Limpieza: borramos los textos del frame anterior usando sus IDs
        FOR (idx = 0; idx < menu.count; idx++)
            IF (id_menu_textos[idx] != 0)
                delete_text(id_menu_textos[idx]);
                id_menu_textos[idx] = 0;
            END
        END

        IF (id_action_text != 0)
            delete_text(id_action_text);
            id_action_text = 0;
        END

        IF (id_sleep_countdown != 0)
            delete_text(id_sleep_countdown);
            id_sleep_countdown = 0;
        END

        // Si la acción está activa, NO dibujamos los comandos; mostramos solo el texto dentro del marco.
        IF (menu.active == 1)
            IF (menu.accion_id >= 0 AND menu.accion_id < menu.count)
                action_graph = menu.comando[menu.accion_id].cg;
                action_text = menu.comando[menu.accion_id].action_text;
            ELSE
                action_graph = CG_AISHA;
                action_text = "";
            END

            // Cambiamos el gráfico de la mascota y mostramos el texto de la acción
            mascota.graph = action_graph;
            id_action_text = write(fuente.fichero, x, y, fuente.alineacion.centro, action_text);
        ELSE
            IF (mascota.sueno.durmiendo == 1)
                // Modo durmiendo: gráfico 21, solo el comando "Salir" activo
                // `controlar_menu` también fuerza menu.selected = CMD_SALIR, aquí lo reforzamos
                mascota.graph = CG_DURMIENDO;
                menu.selected = CMD_SALIR;
                texto_seleccionado = "> " + menu.comando[CMD_SALIR].label.text;
                id_menu_textos[CMD_SALIR] = write(fuente.fichero, x, y, fuente.alineacion.centro, texto_seleccionado);
                // Mostrar tiempo restante hasta el despertar
                rem_min = minutos_restantes_sueno();
                IF (rem_min <= 0)
                    countdown_text = "Despertará pronto";
                ELSE
                    h = rem_min / 60;
                    m = rem_min MOD 60;
                    countdown_text = "Despertará en: " + h + "h " + m + "m";
                END
                id_sleep_countdown = write(fuente.fichero, x, y + 10, fuente.alineacion.centro, countdown_text);
            ELSE
                // --- Rejilla exacta: cada columna tiene la misma X, cada fila la misma Y ---
                // startX centra la tabla horizontalmente: (cols-1)*spacing es el ancho entre extremos
                startX = x - (menu.cols - 1) * menu.spacing / 2;
                // startY centra la tabla verticalmente en el cuadro de diálogo
                startY = y - (menu.rows - 1) * row_gap / 2;

                FOR (idx = 0; idx < menu.count; idx++)
                    row = idx / menu.cols;
                    col = idx MOD menu.cols;
                    px = startX + col * menu.spacing;
                    py = startY + row * row_gap;

                    IF (menu.selected == idx)
                        texto_seleccionado = "> " + menu.comando[idx].label.text;
                        id_menu_textos[idx] = write(fuente.fichero, px, py, fuente.alineacion.centro, texto_seleccionado);
                    ELSE
                        id_menu_textos[idx] = write(fuente.fichero, px, py, fuente.alineacion.centro, menu.comando[idx].label.text);
                    END
                END
            END
        END

        FRAME;
    END
END
(...)//------------------------------------------------------------------------------
// FUNCTION: guardar_partida
// DESCRIPCIÓN: Escribe los stats actuales y el estado de sueño de la mascota
//              en tamav2.sav con el mismo formato que cargar_partida.
//              Escribe cada campo individualmente (count=1) porque sizeof de
//              una STRUCT no-array vale 1 en DIV2.
//------------------------------------------------------------------------------
FUNCTION guardar_partida();
PRIVATE
    fid = 0;
    fid_bak = 0;
    bakname = "";
BEGIN
    // Antes de sobrescribir el SAV, escribimos una copia de seguridad con el estado actual en memoria
    bakname = rutas.save + ".bak";
    fid_bak = fopen(bakname, PERMISO_ESCRITURA);
    IF (fid_bak != 0)
        fwrite(OFFSET mascota.stats, 1, fid_bak);
        fwrite(OFFSET mascota.sueno, 1, fid_bak);
        fclose(fid_bak);
    END

    // Escribimos el fichero principal
    fid = fopen(rutas.save, PERMISO_ESCRITURA);
    fwrite(OFFSET mascota.stats, 1, fid);  // 6 stats
    fwrite(OFFSET mascota.sueno, 1, fid);  // 3 campos de sueño
    fclose(fid);
    return(0);
END
(...)//------------------------------------------------------------------------------
// FUNCTION: decrementar_stats
// DESCRIPCIÓN: Decrementa stats pasivos por el paso del tiempo.
//              Se espera ser llamado una vez por hora (minutos==0 && segundos==0).
//------------------------------------------------------------------------------
FUNCTION decrementar_stats();
PRIVATE
    changed = 0;
BEGIN
    // Hambre y descanso disminuyen con el tiempo
   mascota.stats.hambre   = mascota.stats.hambre - 1;
    mascota.stats.descanso = mascota.stats.descanso - 1;
    // Limpieza baja con el tiempo
    mascota.stats.limpieza = mascota.stats.limpieza - 1;

    // Normalizamos y guardamos el estado
    normalizar_stats();

    // Guardamos la partida tras el decremento para persistir el paso del tiempo
    guardar_partida();
    return(0);
END

//------------------------------------------------------------------------------
// FUNCTION: minutos_restantes_sueno
// DESCRIPCIÓN: Devuelve los minutos restantes hasta la hora programada de despertar.
//              Si no está durmiendo devuelve 0.
//------------------------------------------------------------------------------
FUNCTION minutos_restantes_sueno();
PRIVATE
    dias_diff;
    min_actual;
    min_objetivo;
    total_min;
BEGIN
    IF (mascota.sueno.durmiendo == 0)
        return(0);
    END

    dias_diff = mascota.sueno.despertar_dia - reloj.dia;
    min_actual = reloj.hora * 60 + reloj.minutos;
    min_objetivo = mascota.sueno.despertar_hora * 60;

    total_min = dias_diff * 24 * 60 + (min_objetivo - min_actual);

    IF (total_min < 0)
        total_min = 0;
    END

    return(total_min);
END

//------------------------------------------------------------------------------
// FUNCTION: disparar_evento
// DESCRIPCIÓN: Aplica los efectos de un evento aleatorio y muestra un mensaje.
//------------------------------------------------------------------------------
FUNCTION disparar_evento(INT id_evento);
PRIVATE
    id_msg = 0;
    msg = "";
    wait_frames = 0;
    i = 0;
BEGIN
    file = fpg.hud;
    graph = MARCO_DIALOGO;
    x = configuracion.pantalla.ancho / 2;
    y = configuracion.pantalla.alto - configuracion.cuadro_dialogo.alto / 2;

    SWITCH (id_evento)
        CASE 0: // Regalo sorpresa
            mascota.stats.felicidad = mascota.stats.felicidad + 1;
            msg = "Aisha ha recibido un pequeño regalo!";
        END
        CASE 1: // Enfermedad leve
            mascota.stats.salud = mascota.stats.salud - 2;
            msg = "Aisha se encuentra indispuesta...";
        END
        CASE 2: // Encuentra comida
            mascota.stats.hambre = mascota.stats.hambre + 1;
            msg = "Aisha encontró algo de comer.";
        END
        CASE 3: // Se ensucia
            mascota.stats.limpieza = mascota.stats.limpieza - 1;
            msg = "Aisha se ha ensuciado un poco.";
        END
        DEFAULT:
            msg = "";
        END
    END

    normalizar_stats();
    guardar_partida();

    // Mostramos el mensaje durante unos segundos
    id_msg = write(fuente.fichero, x, y, fuente.alineacion.centro, msg);
    wait_frames = configuracion.fps * 3; // ~3 segundos
    FOR (i = 0; i < wait_frames; i++)
        FRAME;
    END
    delete_text(id_msg);

    return(0);
END

//------------------------------------------------------------------------------
// PROCESS: eventos_aleatorios
// DESCRIPCIÓN: Revisa cada minuto y dispara eventos aleatorios con cooldown.
//------------------------------------------------------------------------------
PROCESS eventos_aleatorios();
PRIVATE
    last_min = -1;
    cooldown = 0;
    roll = 0;
    ev = 0;
BEGIN
    LOOP
        // Detectamos cambio de minuto
        IF (reloj.minutos != last_min)
            last_min = reloj.minutos;

            // Reducimos cooldown si aplica
            IF (cooldown > 0)
                cooldown = cooldown - 1;
            END

            // Sólo intentamos un evento si no hay cooldown
            IF (cooldown == 0)
                roll = rand(0, 99); // 0..99
                IF (roll < EVENT_PROB_PCT)
                    ev = rand(0, 3); // elegir evento
                    disparar_evento(ev);
                    cooldown = EVENT_MIN_INTERVAL; // poner cooldown en minutos
                END
            END
        END

        FRAME;
    END
END

Y hasta aquí el ejemplo de hoy. Espero no volver a tardar meses para presentaros el próximo ejemplo.

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.