EL ÚLTIMO ZARPE — Lo único que sobrevive al bucle es lo que entiendes

Un roguelike sin meta-progresión, donde solo se acumula comprensión · Videojuego propio · Roguelike de preparación

Cliente

Side project — juego propio

Rol

Diseño de juego, desarrollo y dirección de arte

Periodo

Julio 2026 – en curso

Stack

Godot 4.7, GDScript, JSON como capa de reglas, Prototipo HTML/SVG como oráculo, Dirección de arte

El roguelike moderno enseña a memorizar builds: mueres, ganas monedas permanentes, vuelves más fuerte. La dificultad no la resuelve el jugador, la erosiona el desbloqueo. El Último Zarpe hace lo contrario — sin monedas persistentes, sin árbol de mejoras. Un puerto llamado Grisal, unos días contados, un barco que zarpa con o sin ti. Preparas el viaje con dinero limitado, información contradictoria y una bodega que no da para todo. Normalmente mueres. Lo que aprendes al morir es todo lo que te llevas.

El problema: Un juego que mata constantemente tiene un margen de error muy estrecho

Si una muerte se siente arbitraria, el jugador no aprende: se va. Además, una medición incómoda tras el port reveló que el juego supuestamente rejugable tenía solo 6 puzzles posibles en modo largo — memorizable en una tarde. Tres parámetros de dificultad no hacían absolutamente nada.

Cómo se abordó

1. El problema real no era el bucle, era la injusticia. Un juego que mata al jugador constantemente tiene un margen de error muy estrecho: si una muerte se siente arbitraria, el jugador no aprende, se va. La primera decisión de diseño no fue de contenido sino de contrato — nunca mentir al jugador sobre las reglas; sí sobre los hechos. Y «justo» aquí no es una promesa de intenciones: cada viaje generado se demuestra soluble antes de dejarte empezar. Un verificador prueba por fuerza bruta que existe al menos una combinación de compras que sobrevive, con margen económico. Si no la encuentra, ese viaje no llega al jugador.
2. Reintentar es el mismo puzzle, no uno nuevo. La decisión más contraintuitiva del proyecto: volver a Grisal repite la misma semilla a propósito. La tentación de un roguelike es dar una partida nueva tras cada muerte, pero eso convierte el fracaso en ruido — si el próximo viaje es otro, lo que aprendiste sobre este no vale nada. Repitiendo la semilla, el segundo intento es el mismo enemigo con más luz: el jugador vuelve al puerto sabiendo que el agua se acaba el día 3, y esta vez gasta sus preguntas en otra cosa.
3. El prototipo primero, en HTML. Antes de tocar Godot construí el juego entero como una página HTML con SVG y JS —jugable de principio a fin— para poder discutir el diseño jugándolo en vez de imaginándolo. Cuando la mecánica quedó clara, ese prototipo pasó a ser algo más útil que documentación: la especificación ejecutable del port. El motor de Godot no se consideró correcto hasta que generaba exactamente el mismo viaje que el prototipo para la misma semilla.
4. Se midió que el juego aburría, y se arregló con números. Tras el port, una medición incómoda: en modo largo solo existían 6 puzzles posibles, y tres parámetros de dificultad no hacían nada en absoluto. El juego que en teoría era infinitamente rejugable era, en la práctica, memorizable en una tarde. La respuesta fue ampliar el repertorio —de 6 a 12 peligros, de 13 a 18 objetos— y, sobre todo, sacar las reglas del código y meterlas en datos. Hoy la dificultad vive en un JSON que se tunea entre partidas de playtest sin recompilar.
5. El mapa del puerto también es una variable. El puerto tiene once lugares y no abren todos cada partida: la misma semilla que genera el viaje sortea cuáles están abiertos hoy, así que la ruta óptima deja de ser memorizable. Dos salvaguardas evitan que la rotación degenere en frustración. Hay un suelo de información —si el sorteo deja el puerto demasiado pobre, se abren lugares extra— y una regla más dura, aprendida a base de romperla: lo que apaga una mecánica no rota. Al principio el callejón, donde vive el único informador capaz de señalar que una pista es falsa, entraba en el sorteo. Costó variedad (de 126 mapas posibles a 56) y valió la pena.

semilla → travesía: Semilla + dureza + longitud → Generación del viaje → Verificador de solubilidad → Rotación de lugares del puerto → Suelo de información → Preparación · acciones del día → Travesía en cascada → Bitácora · qué te mató

Solución: Solubilidad demostrada y reglas fuera del código

Un verificador prueba por fuerza bruta que cada viaje generado tiene al menos una combinación de compras que sobrevive con margen económico; si no la encuentra, ese viaje no llega al jugador. El repertorio pasó de 6 a 12 peligros y de 13 a 18 objetos, y la dificultad vive hoy en un JSON que se tunea entre partidas de playtest sin recompilar.

Decisiones de producto

• mi rol: Diseño de juego, desarrollo y dirección de arte
• el contrato con el jugador: Nunca mentir sobre las reglas; sí sobre los hechos. Las pistas pueden ser falsas y la gente miente en la taberna, pero el sistema es justo — y eso se demuestra, no se promete.
• decisión más contraintuitiva: Volver a Grisal repite la misma semilla a propósito. Si el próximo viaje fuera otro, lo aprendido sobre este no valdría nada. El segundo intento es el mismo enemigo con más luz.
• estado: Jugable de principio a fin. Ejecutable autocontenido de Windows, verificado en directorio limpio. Sin tienda ni fecha.

Resultados

El juego es jugable de principio a fin y se distribuye como ejecutable autocontenido de Windows, verificado en un directorio limpio. Todo lo medible hoy es de sistema, no de jugadores: aún no hay playtests externos, ni métricas de retención, ni tienda, ni fecha. Cualquier cifra de aquí habla de la solidez del sistema, no de que a alguien le haya gustado. Ese es el siguiente paso, no un resultado ya conseguido.

• 405/405 — combinaciones con paridad exacta contra el prototipo, en dos oráculos
• 792 — puzzles posibles en modo largo — eran 6
• 56 — mapas de puerto distintos por rotación de lugares

"Lo que rota son voces, nunca mecánicas. En ~44% de las partidas el jugador perdía la capacidad de detectar mentiras sin que nada se lo dijera: exactamente el tipo de dificultad de la que no se puede aprender."

Qué se aprendió

1. Medir la variedad antes de creértela. El juego infinitamente rejugable tenía seis puzzles. No lo detectó una intuición de diseño: lo detectó contar. Si un sistema generativo no se instrumenta, se asume que funciona porque es generativo.
2. Un prototipo jugable vale más como oráculo que como documento. Escribir el juego dos veces — primero en HTML para jugarlo, después en el motor — dio una definición de correcto que no admite opinión: mismo resultado para la misma semilla, o el port está mal.
3. Lo que falta, y lo sé. Los días de preparación siguen siendo decorativos, el agua obligatoria convierte una compra en un no-trámite, y casi nunca queda un peligro sin pista honesta — que es justo lo que daría sentido pleno a la bitácora entre bucles.

En desarrollo. Build de Windows funcional; sin tienda ni fecha todavía.