[PCE] Momotaro Katsugeki - Diario de la traducción al castellano

Una de las cosas que más me sorprendió tras publicar mi anterior proyecto fue comprobar que mucha gente imaginaba que, gracias a la inteligencia artificial, este tipo de trabajos empiezan a ser casi automáticos. Después de apenas unos días inmerso en Momotaro Katsugeki puedo decir que la realidad es bastante diferente.

Quiero dejar clara una cosa desde el principio, porque me parece de justicia: yo no tengo ni idea de romhacking. No sé programar en ensamblador, no sabría leer una rutina de un procesador de los ochenta y no distingo un banco de memoria de otro. Todo el trabajo técnico de este proyecto lo hace la IA, y no es "ayuda": es la parte más dura y la que hace que esto exista. Sin ella yo no habría pasado del primer día.



Entonces, ¿qué pinto yo aquí? Pues resulta que bastante. Con el paso de los días hemos ido encontrando un reparto de tareas que funciona sorprendentemente bien, aunque no es una división tan limpia como podría parecer:

• Yo pongo buena parte del enfoque: qué problema merece la pena atacar ahora, qué es importante, qué puede esperar y cuándo conviene abandonar temporalmente una línea de investigación.
• Yo juego. Preparo partidas guardadas en puntos concretos, hago capturas, repito recorridos, pruebo comportamientos, comparo resultados y digo: «Esto no está bien».
• Yo pongo el ojo: veo que faltan cinco píxeles, que un sprite no empalma, que un rótulo está descentrado o que algo que técnicamente parece correcto no se comporta como debería.
• Yo hago buena parte de la adaptación gráfica: redibujo la pantalla de título, adapto letras, modifico fuentes, retoco tiles y rehago los elementos que necesitan una intervención artística.
• Yo tomo las decisiones de traducción: qué se traduce, cómo se formula, qué tono debe tener y qué solución encaja mejor con el espacio disponible y con el espíritu del juego.
• Y, sobre todo, pongo algo difícil de convertir en una lista: intución. Una sensación de que quizá estamos buscando en el lugar equivocado, de que determinada prueba puede revelar algo importante o de que una solución que parece correcta va a traer problemas en otro sitio.

Pero tampoco sería correcto decir que la IA simplemente «hace la parte técnica».

Su papel es muchísimo más amplio que eso.

La IA puede analizar la ROM, localizar rutinas, seguir el flujo de ejecución, estudiar estructuras de memoria, interpretar el funcionamiento del motor de texto, calcular geometrías, escribir herramientas y código nuevo, plantear hipótesis, comprobar relaciones entre sistemas que yo quizá ni habría considerado y buscar soluciones que abarcan simultáneamente muchas más posibilidades de las que una persona podría tener presentes.

Y ahí es donde empieza a aparecer algo que no había previsto cuando comenzó el proyecto: la colaboración no funciona en una sola dirección.

No se trata de que yo dé una orden y la IA la ejecute.

Muchas veces soy yo quien se adelanta a lo que la IA va a necesitar.

Si creo que para resolver un problema será necesario observar determinado punto del juego, preparo una partida guardada concreta. Si sospecho que una rutina puede estar relacionada con otra, busco la forma de proporcionarle capturas, breakpoints o resultados de pruebas que permitan comprobarlo. Si veo un comportamiento extraño, no espero a que la IA «lo descubra»: intento reproducirlo, recopilo información y le doy el material necesario para investigarlo.

En otras ocasiones sucede exactamente al revés.

La IA puede estar contemplando una cantidad de posibilidades que yo jamás habría llegado a plantearme. Puede detectar una relación entre dos rutinas aparentemente independientes, proponer una explicación que no se me había pasado por la cabeza o señalar que un problema que estamos intentando solucionar en un punto concreto quizá tenga su origen varias capas más abajo.

Y entonces me toca a mí seguir esa pista.

O comprobar que no lleva a ninguna parte.

O aportar una observación que vuelva a cambiar completamente el enfoque.

Ahí está, para mí, la parte realmente interesante del proyecto.

La intuición humana no aparece «alguna vez» como un golpe de suerte. Está presente continuamente: al decidir qué probar, qué descartar, qué información preparar, cuándo insistir y cuándo cambiar de dirección. Pero esa intuición tampoco es infalible.



Más de una vez una corazonada mía ha resultado ser completamente equivocada y la IA ha podido desmontarla con una medición o una prueba en cuestión de segundos.

Y también ha ocurrido lo contrario: un análisis técnico perfectamente razonable iba encaminado a una solución que, sobre el papel, parecía correcta, pero una prueba dentro del juego revelaba que algo no cuadraba. Ahí entraba de nuevo la observación humana.

Es un proceso de ida y vuelta constante.

Yo aporto contexto, criterio, observación, intuición y dirección; la IA aporta una capacidad de análisis y exploración técnica extraordinariamente amplia. Pero ninguno de los dos trabaja en un compartimento estanco.

Cada descubrimiento modifica lo que sabe el otro.

Cada prueba puede cambiar la estrategia.

Cada problema puede hacer que aparezca una solución que ninguno de los dos habría planteado al principio.

Y creo que esa es la diferencia fundamental entre esto y la idea de «automatizar una traducción».

No existe un botón al que pulsar y esperar.

Existe una investigación en la que hay que saber qué preguntar, cuándo preguntarlo, qué información aportar, qué comprobar, qué poner en duda y hacia dónde mirar cuando parece que no queda ningún camino.

A lo largo del hilo iré mostrando ejemplos de todas estas situaciones, incluidos los errores, las hipótesis equivocadas y los callejones sin salida.

Porque precisamente ahí es donde se entiende mejor cómo estamos trabajando realmente.

La idea es que este primer mensaje vaya creciendo junto con el proyecto.
Iré documentando los principales hitos de la traducción, las decisiones más importantes, los problemas encontrados y las soluciones que hayan permitido seguir avanzando. Siempre que resulte interesante añadiré capturas, gráficos y explicaciones técnicas, procurando que el hilo pueda disfrutarse tanto si simplemente quieres seguir el desarrollo del proyecto como si además sientes curiosidad por el romhacking.

Para evitar un muro de texto, muchos de los aspectos más técnicos aparecerán dentro de bloques desplegables, dejando el cuerpo principal del diario lo más ameno posible.

Ojalá este hilo termine siendo algo más que la presentación de una traducción. Me gustaría que también sirviera para mostrar todo el trabajo que permanece oculto detrás de un parche terminado y que, en la mayoría de los casos, nunca llega a verse.

Aunque fuera de Japón sea un gran desconocido, Momotaro Katsugeki forma parte de una de las franquicias más populares y queridas del país.

La saga principal, Momotaro Densetsu, cosechó un enorme éxito dentro del género del RPG, mientras que Momotaro Dentetsu terminaría convirtiéndose en todo un fenómeno gracias a sus juegos de tablero, una serie que sigue viva hoy en día y que continúa vendiendo millones de copias en Japón.



Momotaro Katsugeki fue una propuesta diferente dentro de ese universo. En lugar de apostar por el rol o los tableros, trasladó a Momotaro al género de las plataformas y la acción, aprovechando además buena parte de lo que hacía tan especial al catálogo de PC Engine: escenarios muy coloridos, personajes enormemente expresivos, animaciones llenas de pequeños detalles y un sentido del humor constante.



Si tuviera que compararlo con otro juego conocido por aquí, probablemente la referencia más clara serían los Ganbare Goemon.

Comparten esa misma mezcla de folclore japonés, fantasía, humor costumbrista y escenarios inspirados en un Japón feudal idealizado, todo ello acompañado por personajes caricaturescos con muchísimo carisma. Es ese tipo de juegos que consiguen arrancarte una sonrisa constantemente gracias a sus animaciones, expresiones y situaciones absurdas.

Dentro de la propia franquicia existen también los Momotaro Dengeki de Game Boy, que recuerdan bastante a esta entrega y ayudan a hacerse una idea del estilo jugable que buscaba Hudson.



Pero precisamente todas esas virtudes esconden también el mayor obstáculo para cualquiera que haya pensado alguna vez en traducirlo.

No sólo estamos ante un juego con una enorme cantidad de diálogos, sino que muchos de ellos aparecen en bocadillos con escritura vertical y lectura de derecha a izquierda, tal y como es habitual en el japonés tradicional. A eso hay que añadir numerosos textos integrados en gráficos, menús y elementos visuales que requieren una adaptación completamente manual.

No es casualidad que, después de más de tres décadas, el juego siga sin contar con una traducción completa a ningún idioma.

Hasta donde he podido comprobar, únicamente existe un intento muy temprano de traducción al inglés que apenas llegó a modificar algunos menús. Nunca llegó a resolver los verdaderos retos técnicos del juego y terminó abandonándose cuando el proyecto apenas había comenzado.

Y quizá esa fue precisamente una de las razones por las que terminé eligiéndolo.



Porque detrás de su aspecto desenfadado se escondía un desafío técnico muy superior al que imaginaba en un primer momento.

Y ahí fue donde comenzó realmente esta aventura.

Cada proyecto comienza mucho antes de encontrar la primera línea de texto. En este caso, todo empezó con una pregunta muy sencilla: ¿cómo está construido realmente Momotaro Katsugeki? La experiencia obtenida con el proyecto anterior servía como punto de partida, pero era evidente que no podía dar nada por sentado, porque cada juego utiliza sus propias rutinas, organiza la información de una forma distinta y plantea problemas completamente diferentes, por mucho que ambos pertenezcan a la misma época. Antes de traducir una sola palabra había que averiguar con qué nos enfrentábamos.

Las primeras sospechas estaban bastante claras incluso antes de abrir la ROM. Sabía que uno de los mayores retos serían los diálogos mostrados en bocadillos verticales, escritos de arriba abajo y con lectura de derecha a izquierda, tal y como es habitual en el japonés tradicional. Mi idea inicial era intentar convertir ese sistema en uno de escritura horizontal, mucho más natural para una traducción al castellano; sobre el papel parecía una buena solución, siempre que fuera técnicamente posible. A eso había que añadir todos los textos integrados en gráficos, la futura adaptación de la pantalla de título, los menús, la localización de punteros, el estudio de las rutinas de impresión, la posible compresión de datos y un largo etcétera de incógnitas que sólo podrían resolverse investigando la ROM desde dentro.

Las primeras horas no estuvieron dedicadas a traducir, sino a comprender. Se comenzó identificando la estructura general de la ROM, comprobando su organización interna y preparando un pequeño conjunto de herramientas de trabajo que permitieran inspeccionar gráficos, fuentes y código con mayor comodidad. Paralelamente, fui recopilando capturas de distintas zonas del juego para facilitar la localización posterior de los diálogos y disponer de referencias visuales durante toda la investigación.

Y entonces llegó la primera buena noticia: muy pronto quedó claro que, al menos una parte muy importante del texto del juego, no estaba comprimida de forma global. Aquello abría una puerta enorme, porque antes incluso de comprender por completo el funcionamiento interno del motor de texto ya era posible empezar a localizar mensajes, estudiar la codificación utilizada y analizar cómo se organizaban los distintos bloques de diálogo. No era, ni mucho menos, el final del problema; en realidad, sólo era el comienzo. Pero por primera vez el proyecto dejaba de ser una idea para convertirse en una investigación con un camino real por delante.

Una herramienta propia desde el primer día

Y muy pronto nos dimos de bruces con un problema que yo no habría sabido ni nombrar.

Resulta que el PC Engine no lleva el procesador que llevan casi todas las máquinas de esa época, sino uno propio con instrucciones que los programas de análisis habituales no conocen. ¿La consecuencia? Que al leer el código del juego, en cuanto aparecía una de esas instrucciones raras, todo lo que venía después salía mal: instrucciones inventadas, saltos a ninguna parte, basura.

Estuvimos un buen rato persiguiendo fantasmas hasta caer en que el problema no estaba en el juego, sino en la herramienta que lo estaba leyendo.

La solución fue construir una a medida. Unos cientos de líneas de código, nada del otro mundo, pero probablemente lo más rentable de todo el proyecto: sin ella, todo lo que viene después habría sido imposible.

Me quedo con la lección, que además es muy de andar por casa: cuando algo no cuadra, a veces no falla lo que estás mirando, sino con qué lo estás mirando.

A partir de ese momento empezaría el verdadero trabajo de ingeniería inversa: localizar las fuentes, entender la codificación del texto, seguir el rastro de los punteros y descubrir, paso a paso, cómo conseguía el juego mostrar cada uno de sus diálogos.

Uno de los primeros objetivos era averiguar cómo almacenaba el juego su texto. La gran incógnita era saber si nos encontraríamos con una ROM completamente comprimida o si, con un poco de suerte, parte del guion estaría almacenado de forma relativamente accesible, porque esa diferencia podía suponer pasar de un proyecto abordable a uno prácticamente imposible sin desarrollar primero un sistema completo de descompresión.

Afortunadamente, las primeras investigaciones trajeron una noticia muy esperanzadora: una parte muy importante del texto del juego aparecía almacenada en claro, utilizando una codificación japonesa de un byte basada en katakana. Aquello significaba que era posible localizar diálogos, analizarlos y empezar a comprender cómo estaban organizados incluso antes de haber desentrañado por completo el motor de texto. No era una solución al problema, pero sí era la primera puerta que conseguíamos abrir.

Dos fuentes, no una

El primer hallazgo importante fue que el juego no tiene una fuente, sino dos, y son completamente distintas: una para los diálogos y otra para los menús. Distinto tamaño de letra, distinta manera de guardarlas y, sobre todo, distinta forma de buscar cada carácter.

Parece un detalle menor y ha sido una de las trampas más caras del proyecto. Varias veces medimos algo en una fuente, lo dimos por bueno y lo aplicamos en la otra, con resultados desastrosos. Al final se convirtió en una de nuestras reglas de trabajo, escrita con todas las letras: lo medido en una fuente no vale para la otra.

Detalles técnicos de la codificación

Las dos fuentes

                 DIÁLOGO              MENÚ
banco            $1E                  $02
base en la ROM   0x3D660              0x4000
tamaño de glifo  8 bytes, 1 bpp       16 bytes (cuerpo + sombra)
cómo se indexa   tabla en 0x43F9B     directo
la usan          intro, tutorial,     rótulos de dificultad
                 diálogos, password


La tabla de caracteres

El juego usa una codificación de un byte. Los códigos por debajo de 0xA0 pasan por una tabla de traducción situada en 0x43F9B, que convierte el código en un número de glifo. Los códigos a partir de 0xA1, en cambio, van por lo que llamamos la "ruta katakana": el código es directamente el glifo, sin tabla intermedia.

Esa segunda ruta resultó ser la clave para meter minúsculas y acentos. Como no pasa por la tabla compartida, podíamos añadir caracteres nuevos sin riesgo de romper ninguna otra pantalla. El conjunto final tiene 101 caracteres:

mayúsculas   A-Z         códigos $41-$5A (la ruta baja, tabla 0x43F9B)
minúsculas   a-z         códigos $A1-$BA (ruta directa, sin saltos)
acentos      á é í ó ú   ü ñ ç  y sus mayúsculas
signos       ¿ ¡ . , : ; … ' " - / ( ) % & +


Un detalle curioso: tres letras minúsculas (b, c y p) tienen además un código alternativo en la ruta baja, herencia de la parrilla de passwords.

Los códigos de control

Mezclados con el texto aparecen bytes que no son letras, sino instrucciones para el motor:

0x01   cabecera de bloque / selecciona fuente
0x02   cabecera alternativa (segunda fuente)
0x00   fin de línea
0xFC   fin de página
0xF0   espera a que el jugador pulse
0xFD   como 0xFE pero en página final
0xFE   espera de botón
0x3C   espacio
0x5C   alterna entre las dos fuentes
0xFB   marcador de posición para un dígito
0xFF   fin del bloque


El 0xFB tiene su propia historia y aparece más abajo, en el capítulo de la escena de los padres.

Un glifo con sorpresa

El código 0x24 resultó ser el kanji 両 (la moneda del juego, el ryō). Lo descubrimos volcando la fuente entera como imagen, que acabó siendo otra de nuestras reglas: antes de dibujar un glifo, volcar la fuente completa. Se ahorran muchas sorpresas.

Dónde vive el texto

El guion está repartido por varios bancos de la ROM:

0x1F077   escena de los padres
0x1F2C9   tutorial del inicio
0x1FC5F   charla de introducción
0x43740   nombres de las localizaciones del mapa
0x48470   tiendas
0x48CF0   objetos y cantidades de dinero


A partir de ahí comenzó uno de los trabajos más importantes de toda la investigación: identificar qué significaba cada byte que aparecía mezclado con el texto. Pronto fueron apareciendo los primeros códigos de control, responsables de cambiar de bocadillo, finalizar un mensaje, introducir pausas o modificar la forma en que el juego representaba los diálogos. Cada nuevo código identificado permitía comprender un poco mejor el funcionamiento interno del motor de texto y acercaba la posibilidad de realizar una traducción completa.

Sin embargo, el descubrimiento que más me llamó la atención fue otro: los diálogos verticales no eran gráficos dibujados manualmente, como en un primer momento podía parecer, sino texto generado dinámicamente por el propio juego. Entre los caracteres aparecían una serie de separadores que todo apuntaba a que indicaban el cambio de columna en los bocadillos verticales. Aquello cambiaba completamente la perspectiva del proyecto, porque el problema ya no consistía únicamente en traducir el japonés al castellano, sino en encontrar la forma de convencer al propio juego de que dejara de escribir en vertical para hacerlo de una manera natural en nuestro idioma.

Fue uno de esos momentos en los que una investigación responde una pregunta y, al mismo tiempo, plantea otras diez mucho más difíciles. Pero también fue la primera vez que tuve la sensación de que el proyecto empezaba a dejar de ser una incógnita para convertirse en un problema que, con paciencia, podía llegar a resolverse.

Cuando pensamos en una traducción solemos imaginar únicamente el texto, pero en muchos juegos de principios de los noventa una parte importante del idioma no está almacenada como tal, sino integrada directamente en los gráficos. Pantallas de título, menús, carteles, indicadores y logotipos forman parte del propio apartado artístico del juego, y Momotaro Katsugeki no es una excepción.

Desde el principio quedó claro que una traducción completa exigiría mucho más que localizar los diálogos: también habría que adaptar una gran cantidad de elementos gráficos para que el resultado final pareciera un lanzamiento pensado desde el primer momento para el mercado español.

Ésta es, por cierto, la parte del proyecto que sí llevo yo enteramente. Es curioso el contraste: mientras al otro lado se están desmenuzando rutinas de ensamblador, yo estoy peleándome con un editor de píxeles y contando cuadraditos.

Algunas tareas fueron relativamente sencillas, como sustituir pequeños textos japoneses integrados en gráficos, pero otras resultaron bastante más laboriosas. La pantalla de título, por ejemplo, obligó a replantear por completo el diseño original para crear una versión en castellano que mantuviera la personalidad del logotipo japonés sin limitarse a copiarlo literalmente. No se trataba simplemente de escribir otro texto, sino de respetar el ritmo, el equilibrio y el carácter del diseño original, adaptándolo al espacio disponible y a las limitaciones propias del hardware de PC Engine.

Algo parecido ocurrió con la tipografía: en algunos casos fue necesario modificar caracteres existentes y en otros crear letras completamente nuevas para que el castellano pudiera representarse con naturalidad, respetando siempre el estilo gráfico del juego. Mi objetivo nunca ha sido que el jugador perciba constantemente que está jugando a una traducción; al contrario, siempre que ha sido posible he intentado que cada elemento adaptado dé la impresión de haber formado parte del juego desde el primer día.


Fuente diseñada para la traducción.

Esa búsqueda de naturalidad ha terminado convirtiéndose en uno de los aspectos que más tiempo está consumiendo durante el proyecto, pero también en uno de los que más satisfacción produce cuando una pantalla empieza a parecer exactamente como la imaginabas.

Una vez comprendida la estructura de la ROM y la codificación del texto, llegó el momento de poner los pies en el suelo y empezar a tocar pantallas reales. Y el punto de partida natural era, como no podía ser de otra manera, el arranque del juego.

El "PULSA BOTÓN RUN"



Lo primero que aparece nada más encender es la pantalla de título, con el rótulo en japonés y, bajo él, un pequeño texto que invita a pulsar el botón de inicio. Ese primer texto era el "PULSA BOTÓN RUN", un mensaje sencillo, directo y perfecto para hacer las primeras pruebas con la fuente latina.

Y aquí empezó el primer aprendizaje importante: no todo el texto del juego se dibuja de la misma manera. Algunos textos se escriben como caracteres normales, pero otros se generan proyectando bloques gráficos en la VRAM y mostrándolos después como sprites. Ese segundo caso es bastante más delicado, porque el juego sólo prepara tantos bloques como necesitaba el texto japonés original. Si la frase en castellano es más larga, los bloques adicionales no existen y acaban apareciendo con basura gráfica.

Ese mismo patrón iba a repetirse en casi todas las pantallas: el texto en castellano casi siempre es más largo que el japonés, y el juego rara vez está preparado para esa diferencia.

El menú EMPEZAR / CONTINUAR

El siguiente paso fue el menú principal: EMPEZAR / CONTINUAR.



Aquí lo interesante no fue el texto en sí (dos palabras cortas que caben sin problema), sino descubrir que el flujo del juego cambia por completo según haya o no una partida guardada. Esa bifurcación, que en principio parecía un detalle sin importancia, terminaría siendo una de las claves de todo el proyecto y protagonizando uno de los capítulos más largos de este diario.

¿Adónde nos lleva cada opción?

La estructura es la siguiente:

• Al elegir EMPEZAR (sin partida guardada) se accede directamente a la pantalla de introducción de la contraseña del canto de Jizo.
• Si hay una partida guardada, al elegir CONTINUAR no se entra directo al password, sino al selector CANTO DE JIZO / CARGAR.
• Desde ese selector, CANTO DE JIZO te lleva a la pantalla de password.
• Desde ese selector, CARGAR te lleva a la pantalla de carga de partidas guardadas.

El detalle que nos habría ahorrado semanas (y que teníamos delante)

Esa bifurcación no la decide una variable suelta que podamos consultar cuando queramos: la resuelve una rutina concreta del juego, que cuenta las partidas guardadas y devuelve el resultado.

En el código tiene esta pinta:

$EA87  JSR $EAE6      ; ¿hay partida guardada?
$EA8A  BCC $EA94      ;   NO -> saltarse el selector
$EA8C  JSR $FBB3      ;   SÍ -> ir al SELECTOR
$EA94  JSR $FC18      ; password


Lo documentamos aquí, en la segunda pantalla del juego. Y luego pasamos días peleándonos con un problema que se resolvía exactamente con esas tres líneas. Lo cuento en el capítulo del botón II, que es donde toca pasar vergüenza.

Esa distinción es clave y aparecerá una y otra vez: según haya o no partida guardada, el flujo del juego cambia. Y, como veremos más adelante, esa dependencia de la partida guardada también acabó causando más de un dolor de cabeza.



Con el prompt traducido y el menú principal resuelto, el siguiente gran reto era la pantalla de passwords. Un capítulo que merece su propio espacio.

Hasta ese momento ya habíamos conseguido comprender buena parte del funcionamiento interno de la ROM: habíamos localizado texto, empezábamos a entender la codificación utilizada por el juego y ya se habían adaptado algunos elementos gráficos. Sin embargo, todavía quedaba un obstáculo que terminaría convirtiéndose en uno de los mayores retos de toda la traducción: la pantalla de passwords.

A simple vista parece uno de los apartados más sencillos del juego, una cuadrícula de caracteres y unas pocas opciones para introducir o cargar una contraseña, pero la realidad era muy distinta. Todo ese sistema estaba diseñado específicamente para el japonés. No bastaba con sustituir unos caracteres por otros; había que replantear por completo la forma en la que el juego mostraba la parrilla, desplazaba el cursor, interpretaba la entrada de datos y gestionaba una gran cantidad de elementos internos que, hasta ese momento, permanecían ocultos.

Lo que sigue a continuación no es una explicación teórica, sino el recorrido real que fue siguiendo esta parte del proyecto. Creo que resume bastante bien la filosofía de toda esta traducción: detrás de un cambio aparentemente pequeño suele esconderse una cantidad enorme de trabajo que el jugador nunca llega a ver.

El infernal canto de Jizo

La pantalla de password ha sido una de las partes más complicadas de la traducción hasta ahora. A simple vista parecía una pantalla relativamente sencilla: una tabla de caracteres, un cursor y unas opciones. Sin embargo, por dentro mezcla varias cosas a la vez: fuente, gráficos generados en VRAM, sprites, tilemaps, lógica japonesa de kana, control de cursor y validación interna de passwords.

Además, el sistema original está diseñado alrededor del silabario japonés. Al pasarlo a una parrilla latina, no basta con cambiar los dibujos de las letras: también hay que adaptar la lógica para que el cursor, los valores internos y la validación sigan funcionando.

1. Cambio de la parrilla japonesa a una parrilla latina



La pantalla original usa caracteres japoneses. Para la traducción se ha sustituido por una parrilla latina con letras, eñe y números.

La distribución final es ésta:


A B C D E F G     a b c d e f g

H I J K L M N     h i j k l m n

Ñ O P Q R S T     ñ o p q r s t

U V W X Y Z       u v w x y z

    0 1 2 3 4     5 6 7 8 9



No es una simple tabla alfabética lineal. Opté por esta disposición porque visualmente encaja mejor en la pantalla y permite separar mayúsculas, minúsculas y números de forma clara. Fue una suerte que el total de los caracteres japoneses en la parrilla coincidiera exactamente con la suma de las letras del abecedario en mayúsculas y minúsculas más los números del 0 al 9. 64 caracteres en total. Esto era importante porque a cada carácter japonés había que asignarle uno latino.

2. Corrección de la lógica del cursor

La parrilla japonesa no es un rectángulo perfecto: tiene huecos. La latina tampoco (la última fila de mayúsculas se queda en seis letras, y la de números arranca desplazada). Hubo que reprogramar los saltos del cursor para que no se metiera en casillas vacías ni se saltara letras.

3. Ajustes especiales de navegación

Algunos movimientos necesitaban tratamiento propio: pasar de la última letra de una fila a la primera de la siguiente, o bajar desde la zona de mayúsculas a la de números sin caer en un hueco.

4. Fuente latina corregida

Los glifos originales estaban pensados para kana, que ocupa todo el ancho de la celda. Las letras latinas necesitan menos y quedan mejor con un pequeño margen. Hubo que redibujar buena parte del abecedario para que la parrilla no pareciera apretada.

5. Solución al problema de la q en adelante

A partir de cierta letra los glifos aparecían desplazados. La causa era un desajuste entre el índice de la tabla y la posición real del glifo en la fuente. Se corrigió reasignando los índices.

6. Buffer inferior: puntos y separadores

Debajo de la parrilla, el juego muestra la contraseña que vas escribiendo, con puntos gruesos como marcadores de las posiciones vacías y barras separando los grupos.



Al principio aparecían letras incorrectas en los huecos, porque los patrones que usaba el juego para los puntos se solapaban con los de los nuevos caracteres latinos. Hubo que reasignarlos para que los huecos vacíos volvieran a mostrarse como puntos y las barras separadoras quedaran en su sitio.

7. Traducción de las opciones de la derecha

Las opciones laterales (introducir, borrar, espacio, terminar) estaban en japonés. Un detalle que descubrí probando: la opción que parecía significar "insertar" era en realidad el espacio, y el juego lo representaba con una interrogación, lo cual resultaba de lo más confuso. Lo cambiamos por un espacio en blanco de verdad, que es lo que cualquiera espera.

8. Texto superior: "¡Introduce el canto de Jizo!"

El mensaje de cabecera no cabía. Hubo que ampliar el número de bloques gráficos que el juego prepara para esa línea.

9. Mensaje de error del canto de Jizo

Cuando la contraseña es incorrecta aparece un mensaje de error. En castellano ocupaba bastante más y se salía de la caja, así que hubo que ensanchar tanto el texto como el gráfico del marco.



10. Prueba de passwords secretos conocidos

Un punto importante: los passwords originales del juego siguen funcionando. La validación es interna y no depende de qué letras se dibujen en la parrilla, así que cualquier contraseña que circule por internet sigue siendo válida.

11. Por qué los passwords ahora parecen no tener sentido

Al cambiar los caracteres de la parrilla, un password que en japonés era una palabra reconocible ahora aparece como una secuencia de letras latinas aparentemente aleatoria. Funciona igual, pero ha perdido la "gracia" de que se leyera como algo.

Tarea pendiente: alias de passwords

Se me ocurrió una idea que aún está por explorar: mantener una tabla de equivalencias para que ciertas palabras en castellano funcionen como alias de los passwords originales. Queda anotada para más adelante.

Estado actual de la pantalla de password

La pantalla está completamente traducida y funcional: parrilla latina, cursor correcto, buffer, opciones, cabecera y mensaje de error. Fue el capítulo más largo de la primera fase del proyecto.

Después de la pantalla de passwords, el siguiente frente fue el selector CANTO DE JIZO / CARGAR. Recordemos el contexto: cuando hay una partida guardada, al elegir CONTINUAR el juego no va directo a la pantalla de password, sino que muestra este pequeño menú con dos opciones.

El problema era doble. Por un lado, el texto en castellano de "CANTO DE JIZO" y "CARGAR" no cabía en el bocadillo original, que estaba pensado para las palabras japonesas, mucho más cortas; el texto se salía por los lados y se cortaba. Por otro lado, al ensanchar el texto apareció un problema de solapamiento: las dos opciones compartían zona de memoria y, como "CANTO DE JIZO" era más largo, invadía el espacio que debía ocupar "CARGAR". El resultado era un texto ilegible en el que ambas líneas se mezclaban.

La causa de fondo: los chunks de sprites

Para entenderlo había que saber cómo dibuja el juego estos menús. El texto no se escribe como caracteres normales: el juego genera bloques gráficos (llamémoslos "chunks") en la VRAM y luego los proyecta como sprites. Cada opción del menú tiene reservado un número fijo de bloques, calculado para el texto japonés. Al traducir a frases más largas, los bloques que faltan no se preparan, así que aparecen con basura gráfica o invaden los bloques de la opción vecina. La solución pasó por ampliar el espacio reservado para cada opción y reorganizar los destinos de memoria para que ninguna línea pisara a la otra.

El bocadillo: ampliar sin descolocar

Una vez resuelto el texto, tocaba el marco. El bocadillo original era demasiado estrecho y había que ensancharlo para que cupiera "CANTO DE JIZO" sin desbordar, pero sin descolocar el resto de la pantalla. El texto del selector está alineado a la izquierda, con un pequeño melocotón como puntero de selección; la frase más larga ("CANTO DE JIZO") marca el ancho necesario, dejando un margen de unos 8 píxeles a cada lado, y el conjunto queda centrado en pantalla. Fue un trabajo de ajuste fino: ampliar el marco, recolocar el texto y asegurarse de que el melocotón siguiera señalando correctamente cada opción.



Un detalle técnico curioso

Durante esta fase hubo un momento de confusión importante: perseguimos durante horas "la lista de sprites" que proyectaba el texto del selector... y no existía. El texto del selector no se dibuja con sprites, sino en el plano de fondo. Lo que parecían patrones de letras eran, en realidad, el relleno negro y las esquinas del marco de la caja. Fue un buen recordatorio de que, en romhacking, a veces la hipótesis más razonable es exactamente la equivocada.

La tercera parada del flujo fue la pantalla de carga de partidas guardadas. Aquí el juego muestra la pregunta "¿Cuál quieres cargar?" y, debajo, la lista de partidas guardadas con su nombre y dificultad. El reto principal era el mismo de siempre: la pregunta en castellano es mucho más larga que el texto japonés, y el bocadillo no estaba preparado para ella. Pero esta pantalla tenía además dos problemas añadidos que terminaron siendo muy ilustrativos: el bloque negro y el artefacto gráfico.

El bloque negro que tapaba la pregunta

En cuanto traducimos la pregunta, apareció un bloque negro que la tapaba parcialmente. Al ensanchar el texto de 3 a 5 bloques por línea, aparecieron unos sprites que ya no encajaban en ninguna parte y se quedaron flotando encima de la pregunta.

La solución de aquel momento fue una chapuza, y lo digo sin acritud: alinearlos sobre las letras "uá" de la palabra "Cuál", de modo que el bloque negro dejara de verse como una mancha y pareciera parte del texto. Funcionaba, se veía igual en todos los emuladores y nos permitió seguir avanzando.

Pero nunca me convenció. Recuerdo haber dicho entonces que ese bloque claramente no estaba donde debía y que aquello acabaría dando problemas. Tardó semanas, pero acabó dándolos, y de qué manera. La historia completa está más abajo, en su propio capítulo.

El artefacto en la partida guardada

El segundo problema era más sutil: junto a la partida guardada aparecía un artefacto gráfico, un recuadro con píxeles sueltos, que curiosamente sólo se veía en un emulador concreto (Mesen) mientras que en otros pasaba desapercibido. El dato más revelador fue que la ROM japonesa original funcionaba perfectamente, es decir, el artefacto era 100% culpa de nuestra traducción.

La causa estaba en la limpieza de la VRAM. Al ensanchar las líneas de la pantalla de carga, las direcciones de memoria donde se dibuja el texto cambiaron, pero la rutina que limpia la VRAM seguía limpiando el rango antiguo, dejando sin limpiar las zonas nuevas, donde se acumulaba basura gráfica. La solución fue ampliar el rango de limpieza para que cubriera todas las líneas nuevas, y tras el ajuste el artefacto desapareció en todos los emuladores.



Lección de este capítulo

Al ensanchar cualquier texto, no basta con que "se vea bien" a primera vista: hay que revisar todas las rutinas que dependen del ancho (la limpieza de memoria, los sprites sobrantes, los tiles reservados...) y, además, probarlo en varios emuladores, porque un bug puede ser invisible en uno y evidente en otro.

Hubo un momento del proyecto en el que dejé de pensar en la pantalla de passwords como un simple menú: empecé a verla como una prisión. Y no es una metáfora. Si el jugador entraba en ella, sólo existían dos formas de salir: introducir una contraseña válida... o pulsar el botón RESET de la consola. No había ninguna opción para regresar al menú anterior.

Así funcionaba el juego original y, probablemente, nadie en Hudson llegó a plantearse que aquello pudiera resultar incómodo. Pero cuanto más tiempo pasaba probando la traducción, más artificial me parecía ese comportamiento. Lo curioso era que el propio juego ya tenía la solución: en otros menús bastaba con pulsar el botón II para volver atrás. ¿Por qué precisamente la pantalla de passwords era una excepción?

La idea parecía tan sencilla que apenas le di importancia. Sólo había que hacer que esa pantalla respondiera igual que las demás; pensé que sería una pequeña mejora de calidad de vida que podría implementar en una tarde. No podía estar más equivocado. Desde el momento en que decidimos añadir esa función, el proyecto dejó de consistir en traducir un juego: ahora intentábamos enseñarle a hacer algo que nunca había sabido hacer.

El primer éxito... y la primera caída

Después de localizar las rutinas implicadas y comprender cómo gestionaba el juego la navegación por los distintos menús, conseguimos que el botón II respondiera. La sensación fue fantástica: pulsabas el botón y abandonabas la pantalla. Problema resuelto. O eso parecía, porque bastó seguir haciendo pruebas durante unos minutos para descubrir que el cambio había empezado a producir efectos completamente inesperados. La pantalla seguía funcionando... pero otras ya no.

El efecto dominó

Lo que vino después fue una de las fases más desconcertantes de toda la investigación. Cada modificación solucionaba un problema y descubría otro distinto. A veces aparecían bloques negros donde antes no existían; en otras ocasiones algunos textos cambiaban ligeramente de posición. Había pantallas que dejaban de actualizar correctamente determinadas zonas de la VRAM, y algunos retornos conducían al lugar equivocado. Y, cuando parecía que por fin todo volvía a estar bajo control, aparecía un nuevo comportamiento inesperado. Era como intentar reparar un reloj tocando únicamente sus engranajes visibles: cada pieza estaba relacionada con otra, y ninguna venía acompañada de un plano que explicara cómo funcionaba el conjunto.

La partida que nunca existió

Uno de los errores más curiosos apareció cuando decidimos probar qué ocurría si el jugador intentaba abandonar la pantalla sin disponer de ninguna partida guardada. La lógica indicaba que simplemente no debería pasar nada, pero eso no fue lo que ocurrió: de algún modo terminábamos accediendo a la pantalla de carga de partidas y, lo más sorprendente, el juego permitía cargar una partida... inexistente.

El resultado era digno de una película de ciencia ficción. El juego arrancaba en escenarios completamente rotos, con variables internas que contenían valores absurdos. El personaje aparecía con cantidades desorbitadas de vidas, enormes reservas de puntos de vida y cantidades de dinero imposibles de conseguir durante una partida normal. Otras veces, en cambio, la partida "funcionaba" de forma engañosa, lo que hacía el error todavía más traicionero. No era un secreto oculto por los desarrolladores, sino simplemente el juego interpretando como una partida válida unos datos que nunca habían sido pensados para representar una partida. Aquello demostraba hasta qué punto una modificación aparentemente inocente podía alterar zonas del programa que, en teoría, no tenían ninguna relación con la pantalla de passwords.

Hipótesis, pruebas y callejones sin salida

Durante esos días el trabajo dejó de parecerse a una traducción y se convirtió en una investigación. Y aquí es donde más claro se ve el reparto de tareas del que hablaba al principio: por un lado se generaban ROMs de prueba y se analizaban rutinas; por otro, yo cargaba cada versión, repetía el mismo recorrido veinte veces, hacía capturas, colocaba puntos de ruptura siguiendo instrucciones y contaba lo que veía. En muchas ocasiones una explicación parecía perfectamente razonable hasta que una simple prueba en pantalla demostraba que estábamos mirando el problema desde el lugar equivocado. Entonces tocaba volver atrás, replantearlo todo y empezar de nuevo.

La batalla entre emuladores

Una de las mayores complicaciones fue conseguir que la solución funcionara igual en todos los emuladores, porque lo que funcionaba en uno fallaba en otro. Resulta que ciertos huecos de memoria arrancan con valores distintos según el emulador: un dato que en uno vale cero, en otro vale cualquier cosa. Y nuestra comprobación tomaba caminos distintos según lo que se encontrara.

Llegamos a probar ocho versiones. Cada una leía el dato de un sitio diferente, tomaba precauciones distintas... y ninguna funcionaba en los dos emuladores a la vez. Algunas ni siquiera arrancaban: se colgaban directamente.

La decisión pragmática

Tras muchos intentos, la conclusión de aquel momento fue clara: el comportamiento "perfecto" (con partida ir al selector, sin partida ir al título) era extremadamente difícil de hacer fiable. Se tomó una decisión pragmática y honesta: que el botón II en el password resetease al título en todos los casos. Era lo más robusto: no rompía nada, no corrompía partidas, funcionaba igual en todas partes y cumplía el objetivo principal de escapar de la prisión.

Y ahí se quedó la cosa durante semanas.

La solución que estaba delante todo el tiempo

Mucho después, ya con el resto del proyecto avanzado, decidí volver sobre este asunto. No me terminaba de gustar haber renunciado al comportamiento correcto.

Y entonces apareció la respuesta más humillante posible: el juego ya sabía tomar esa decisión. La tomaba cada vez que el jugador elegía CONTINUAR desde el menú principal.

$EA87  JSR $EAE6      ; ¿hay partida guardada?
$EA8A  BCC $EA94      ;   NO -> saltarse el selector
$EA8C  JSR $FBB3      ;   SÍ -> ir al SELECTOR


Esa rutina cuenta las partidas guardadas y devuelve el resultado. Lleva ahí desde 1990. Se ejecuta en cada arranque. Está probadísima, por el propio juego, en todos los emuladores del mundo.

Los ocho intentos anteriores habían fallado por lo mismo: cada uno leía un dato por su cuenta, en un momento en que la memoria no estaba preparada para ello, y sobre valores que dependen del emulador. La solución no era leer mejor el dato. Era no leer ninguno y dejar que lo hiciera el juego.

El parche final ocupa diez bytes:

$FF5A  JSR $EAE6     ; que decida el juego
$FF5D  BCC $FF65     ; sin partida -> título
$FF5F  LDX #$FF
$FF61  TXS
$FF62  JMP $EA8C     ; con partida -> selector
$FF65  JMP $E000     ; sin partida -> título


Funciona en Beetle. Funciona en Mesen. Con partida guardada te lleva al selector; sin ella, al título. Exactamente lo que queríamos desde el principio.

La lección

Ésta es probablemente la historia que mejor resume el proyecto entero. Días peleándonos con memoria, emuladores y comportamientos raros, para acabar descubriendo que la solución consistía en llamar a una función que llevaba treinta y cinco años en la ROM. Y lo mejor: la teníamos documentada desde la segunda pantalla del juego.

Hay una tentación constante de escribir código nuevo. Casi siempre es mejor mirar primero si el juego ya sabe hacer lo que necesitas.

Una modificación invisible

Probablemente nadie que juegue a la traducción piense demasiado en esta mejora: entrará en la pantalla, pulsará el botón II, volverá al menú anterior y seguirá jugando. Precisamente ése era el objetivo. Las mejores modificaciones son las que terminan pareciendo parte del juego original, pero detrás de esa acción que apenas dura una fracción de segundo hubo varios días de investigación, incontables pruebas, hipótesis descartadas y una larga cadena de errores que jamás habrían aparecido si nos hubiéramos limitado a traducir los textos.

Fue entonces cuando comprendí que este proyecto ya no consistía únicamente en localizar un juego japonés: también consistía en entenderlo lo bastante bien como para enseñarle a hacer cosas que nunca había hecho.

Con la base estable, el siguiente objetivo fue traducir la charla de introducción que aparece al pulsar EMPEZAR, antes del selector de dificultad. Es el momento en que el juego te da la bienvenida, te explica que cualquiera puede superar "Momotaro Katsugeki" y te anima a elegir el Modo Fácil si es tu primera vez.



Localizar ese texto costó lo suyo: el puntero que el juego usa para leerlo se monta sobre la marcha, así que no basta con buscarlo en la ROM. Tras bastante trabajo apareció la rutina que lo carga. El texto japonés ocupaba 391 bytes y nuestra traducción necesitaba más espacio, así que hubo que reubicarlo en una zona libre y redirigir el puntero. Sólo había que tocar dos bytes; encontrarlos fue lo difícil.

El idioma de los diálogos

Al insertar el texto en español apareció un problema inesperado: los diálogos no mostraban bien los acentos ni las minúsculas.



Éste es uno de esos momentos en los que una investigación da un giro completo. Al principio dimos por hecho que había que dibujar glifos nuevos y buscarles hueco, un trabajo considerable. Pero al estudiar con calma cómo el juego convierte un código en un dibujo, apareció el detalle clave: hay dos caminos distintos, y uno de ellos no pasa por la tabla que comparten todas las pantallas.

Eso significaba que podíamos añadir minúsculas y acentos sin riesgo de romper la parrilla del password ni ninguna otra cosa. De un problema que parecía requerir días pasamos a una solución limpia y segura.

Un detalle que despista mucho

Hay una peculiaridad que confunde a cualquiera que pruebe una versión intermedia: cuando el bocadillo todavía tiene el texto japonés pero ya está cargada la fuente latina, el texto se ve como una ristra de símbolos raros. Parece que algo se ha roto, pero no: los bytes japoneses caen en la ruta directa y se dibujan con las letras latinas que ocupan esas posiciones. En cuanto se inserta el texto en castellano, todo aparece perfecto.

Me ha pasado en cada pantalla nueva. Y en cada una he tenido que recordarme que es lo normal.

El paginado y las pausas de lectura

Un detalle importante de la charla es cómo se muestra en pantalla. El bocadillo sólo enseña 4 líneas a la vez, con 24 caracteres por línea. El texto va haciendo scroll y una flecha indica cuándo pulsar para continuar.



Para la traducción montamos un pequeño repartidor automático: se le da el texto corrido y él lo parte en líneas de 24 caracteres sin cortar palabras, agrupándolas en páginas de 4. Las once páginas de la introducción están hechas así, y alguna línea queda clavada en el límite.

Ese repartidor es el germen de algo más ambicioso: cuando toque traducir el grueso del guion, la idea es que el mismo sistema reparta automáticamente todos los diálogos del juego.

Superada la introducción, lo siguiente era el pequeño tutorial que aparece nada más empezar a jugar, donde el juego te explica que esquives lo que cae del cielo y llegues a la meta. Cuatro frases cortas.



Y aquí llegó el primer choque de verdad con la geometría del juego.

16 celdas para el japonés, 20 para nosotros

El bocadillo original permite 16 caracteres por línea. En japonés sobra: el kana es muy compacto. En castellano no llega ni de lejos. Una frase tan simple como "¡Esquiva los ñordos que caen!" no cabe partida en dos líneas de 16.

Así que tocaba ensanchar el bocadillo. Y ensanchar un bocadillo en este juego resultó ser bastante más complicado de lo que parece, porque no es un gráfico: es un rompecabezas de piezas pequeñas que el juego va colocando según una lista de instrucciones.

Cómo se construye un bocadillo

El juego tiene un motor que lee listas de registros de cinco bytes:

[patrón] [atributo bajo] [atributo alto] [dx] [dy]


Cada registro coloca una pieza en una posición relativa a un punto de anclaje. La lista termina con un $FF.

Un bocadillo típico se compone así:

fila superior:  esquina + relleno + relleno + esquina
fila central:   lateral izquierdo + TEXTO + lateral derecho
fila inferior:  esquina + relleno + relleno + esquina  (con espejo vertical)
                y el "rabillo" que apunta al personaje


Para ensanchar hay que reescribir esa lista: más piezas de relleno, más huecos de texto, y recalcular todas las posiciones. Además hay que ampliar la zona de memoria gráfica que el juego prepara, o las piezas nuevas mostrarán basura.

Y hay dos límites que no se pueden rebasar:

• Las posiciones van con signo: de -128 a +127 respecto al ancla. Si el bocadillo crece mucho y el ancla está en un extremo, las piezas del otro lado se salen de rango.
• El PC Engine sólo puede dibujar 16 piezas por línea horizontal de pantalla. A partir de ahí, las descarta sin avisar.

Los dos nos han mordido, y más de una vez. El segundo, de forma especialmente cruel: el juego no da ningún error, simplemente deja de dibujar cosas.

De 16 a 20 celdas

Al final el tutorial quedó con 20 celdas por línea y un bocadillo de 188 píxeles, centrado en pantalla. Cuatro celdas más no parecen gran cosa, pero son la diferencia entre que una frase quepa o haya que reescribirla entera.



Un detalle de traducción

Una de las frases dice "¡Pulsa I y salta para esquivarlos!". Al principio habíamos escrito "II", por pura inercia: es el botón de salto habitual. Al comprobarlo contra la ROM japonesa, el texto original decía claramente "botón I". Corregido.

Es el tipo de detalle que sólo aparece si uno se molesta en volver al original en lugar de fiarse de lo que le parece lógico.

La primera escena con diálogo de verdad del juego: los padres de Momotaro le dan dinero y unos kibidango antes de que parta hacia la isla de los ogros.



Esta escena tenía de todo: bocadillo estrecho, tres líneas de texto, una imagen de los padres, una flecha de "continuar" y un misterio que nos tuvo un buen rato dándole vueltas.

El bocadillo de tres líneas

El bocadillo de esta escena tiene tres líneas en lugar de dos, así que hubo que reescribir su lista entera: 20 celdas por línea, tres filas, 188 píxeles de ancho. Además hubo que bajar la imagen de los padres dos píxeles y mover la flecha catorce a la derecha para que quedara alineada con la curva de la esquina, como en otros bocadillos del juego.

Sí, dos píxeles. Este proyecto va mucho de eso.

El misterio de los tres marcadores

En el texto original de esta escena aparecían tres bytes idénticos seguidos, justo donde el juego dice cuánto dinero te dan.

La primera hipótesis fue que servían para que el juego insertara ahí la cantidad, y como se rellenaban alineando a la derecha, en castellano quedaba una sangría fea antes del número. La pregunta era: ¿podemos quitarlos?

El análisis inicial decía que no, porque "afectaría a todos los importes del juego". Pero al contarlos de verdad resultó que en toda la ROM hay un único grupo de estos marcadores, y es precisamente éste. Todos los demás importes llevan la cifra escrita directamente en el texto:

ももたろうは100両を てに いれた
ももたろうは50両を  てに いれた
ももたろうは30両を  てに いれた


Seis variantes fijas, una por cantidad. Ninguna usa marcadores.

Con ese dato, la prueba era de lo más tonta: cambiar los tres marcadores por el texto "50" y mirar en el juego si el dinero se sumaba igual. Se sumaba. Eran sólo formato, y la sangría desapareció.

Buen ejemplo de una regla que hemos aprendido a base de perder tiempo: "afecta a todo el juego" hay que contarlo, no suponerlo.



La traducción, y una consulta al original

Al ajustar el texto surgió una duda interesante. Una frase dice "¡Llévate también un kibidango!" y otra "¡Momotaro obtiene un kibidango!". ¿Debía ser "un" o "unos"?

En japonés los sustantivos no marcan número, así que hay que mirar el contexto. Y al leer el original apareció la respuesta:

「キビダンゴモ モッテイクガヨイ！」        <- la madre: SIN cantidad
モモタロウハ キビダンゴヲ ヒトツ テニイレタ！  <- el aviso: ヒトツ = "uno"


Las dos frases no dicen lo mismo. La madre usa un plural indefinido; el aviso especifica uno. Y el juego usa la misma plantilla para el dinero y para el dango, con la cantidad en el mismo sitio.

Al final optamos por el singular en las dos: coincide con lo que el juego te da de verdad, y en castellano un contable pide artículo. Detalles así son los que hacen que una traducción se note trabajada o suene a máquina.

Este capítulo es la continuación de aquel bloque negro que "resolvimos" alineándolo sobre las letras "uá". Y es, probablemente, mi historia favorita del proyecto.

El síntoma

Un día guardé una segunda partida. Tenía una en Normal y empecé otra en Fácil. Al entrar en la pantalla de carga, la segunda entrada aparecía en la misma línea que la primera, al final, separada por un hueco enorme y con el nombre cortado: sólo se leía "NOM".

En la ROM japonesa original la pantalla funcionaba perfectamente. El fallo era nuestro.

Dos diagnósticos equivocados

El primer análisis apuntó a que ambas pantallas compartían un identificador interno y que nuestro parche se estaba aplicando donde no debía. Al comprobarlo contra una partida guardada real, el identificador no coincidía: hipótesis descartada.

El segundo fue peor. Se propuso revertir un cambio de la traducción que parecía sospechoso... que resultó ser exactamente el arreglo del solapamiento de la pregunta. Habríamos roto algo que llevaba semanas funcionando. Se libró por poco, y sólo porque insistí en repasar el diario del proyecto antes de tocar nada.

La causa real

La respuesta estaba en cuánto espacio de memoria gráfica tiene reservado cada línea:

la pregunta      256 px de espacio
partida 1        128 px
partida 2        128 px


Al ensanchar, le habíamos dado cinco piezas (160 px) a la línea de la primera partida. Pero esa línea sólo tiene 128 px asignados. La quinta pieza leía la zona siguiente... que es donde el juego escribe la segunda partida.

O sea: el "NOM" cortado no era la segunda partida mal colocada. Era la quinta pieza de la primera línea mostrando el contenido de la segunda. Al mirar esa zona de memoria apareció "NORMAL 1" entero y perfectamente escrito. La segunda partida nunca estuvo rota; simplemente la leía quien no debía.

Y el "uá"

Aquí llegó lo bueno. Los sprites que habíamos escondido sobre las letras "uá" eran exactamente esos invasores: las piezas sobrantes de haber ensanchado las líneas de 3 a 5 sin comprobar cuánto espacio tenía cada una.

Nunca fueron un "duplicado" que hubiera que ocultar. Eran las líneas de las partidas 2, 3 y 4, leyendo memoria que no les correspondía. La chapuza de alinearlos sobre el "uá" los escondía, pero no los arreglaba. Y por eso el problema reapareció en cuanto guardé una segunda partida.

La solución definitiva fue devolver cada línea a sus cuatro piezas (128 px exactos, lo que tiene asignado). "MUY DIFÍCIL 1", el nombre más largo posible, mide unos 104 píxeles: cabe de sobra.

La moraleja

Aquella intuición de que "ese bloque no está donde debería" era correcta desde el primer día. Lo que faltaba no era una idea mejor, sino medir cuánto espacio tiene asignado cada línea en vez de contar piezas a ojo.

Y una cosa que me llevo de aquí: cuando algo "sobra", casi nunca sobra. Suele ser algo que se ha quedado sin sitio.

Con las pantallas de menú resueltas, tocaba entrar en el juego de verdad. Y el primer objetivo era el mapa: esa pantalla donde se ve el recorrido entre aldeas y aparece un cartelito con el nombre de cada una.



Los nombres son cuentos populares

Lo primero fue localizar los nombres y traducirlos. Y ahí apareció algo bonito: cada aldea es un cuento popular japonés.

タビダチノ村      "la partida", ponerse en camino
ハナサカノ村      Hanasaka Jiisan, el que hace florecer los árboles
キンタロウノ村    Kintarō, el niño forzudo
ネタロウノ村      Netarō, el dormilón
ウラシマノ村      Urashima Tarō, el de la tortuga
カチカチヤマノ村  Kachi-kachi Yama, el monte crepitante
イッスンボウシ村  Issun-bōshi, el enanito
タケトリノ村      Taketori monogatari, el cortador de bambú
オニガシマ        Onigashima, la isla de los ogros


Para traducirlos seguí un criterio mixto: nombre propio cuando el japonés nombra a un personaje (Kintaro, Urashima, Issunboshi) y descriptivo cuando nombra un lugar o un concepto (Partida, Florecer, Dormilón, Bambú, Ogros). Y mantener "Aldea" en las ocho que la llevan.

Hay una pérdida consciente: Kachiyama se come uno de los dos "kachi" del original. かちかち es la onomatopeya del chisporroteo del fuego, y el cuento va precisamente de eso. Pero "Aldea de Kachi-Kachi" se pasaba del límite por un carácter, así que hubo que elegir. Me fastidia, pero es lo que hay.

La fuente que ya teníamos

Al ir a insertar los nombres apareció un problema aparentemente serio: la tabla de caracteres del rótulo no tenía mayúsculas. Sin A, sin K, sin M. Imposible escribir "Aldea de Kintaro".

Se plantearon tres soluciones, todas laboriosas: liberar entradas quitando signos, usar una segunda tabla, o escribirlo todo en minúsculas.

Y entonces hice la pregunta obvia, la del que no sabe nada de esto: ¿no podemos usar la fuente que ya tenemos, la de la intro y el password?

Resulta que ya la estaba usando. El rótulo no tiene fuente propia. Lo que habíamos tomado por "una fuente sin mayúsculas" era en realidad una tabla intermedia, una especie de índice. Y había una segunda vía de acceso que nadie había mirado, en la que las mayúsculas están donde uno esperaría que estuvieran.

Esa pregunta ahorró una tarde entera de trabajo innecesario. A veces preguntar lo evidente sale rentable precisamente porque nadie se molesta en comprobarlo.



El rótulo que se cortaba

Con los nombres insertados, el rótulo del mapa seguía cortándose: sólo se leía "Aldea de". Pero al examinarlo apareció un detalle revelador: el contador interno decía 18 letras dibujadas. El texto completo estaba en memoria; lo que faltaban eran piezas que lo mostrasen.

Ensanchar el rótulo del mapa resultó ser, con diferencia, la parte más laboriosa de este capítulo. Hicieron falta cinco versiones y cada una destapó un problema distinto:

• La caja se fue al fondo de la pantalla. La lista original coloca el rótulo con un truco de cálculo para situarlo por encima del punto de anclaje. Al reescribirla desde cero con valores "limpios", apareció 66 píxeles más abajo, fuera del mapa. Y eso que yo había avisado expresamente de que no tocáramos la altura.
• Faltaban trozos de la caja y del icono vecino. Nos habíamos pasado del límite de 16 piezas por línea de pantalla... pero sólo al contar todas las de la pantalla, no sólo las del rótulo. Los iconos de las aldeas también ocupan.
• El rabillo no empalmaba con el bocadillo. Aquí el diagnóstico correcto salió de mirar la captura: parecía un problema de qué se dibuja delante y qué detrás. Exacto. En el PC Engine el orden importa, y al reescribir la lista el rabillo había quedado por detrás del marco en lugar de por delante.

Una trampa que casi nos cuesta el mapa entero

Para que la caja ancha cupiera había que mover el rótulo de sitio en algunas aldeas. La tabla que da esas posiciones estaba localizada y parecía perfecta para el trabajo.

Antes de tocarla, comprobamos quién más la usaba. Y resultó que esa misma tabla coloca también el icono de la aldea en el mapa. Cambiar las posiciones habría movido las ocho aldeas de sitio, alterando la geografía del juego.

La solución fue darle al rótulo su propia tabla de posiciones, dejando la original intacta. Y el rabillo se dibuja aparte, en la posición de siempre, para que siga apuntando a su aldea aunque la caja se haya desplazado. Esa idea, por cierto, salió de mirar la pantalla y pensar "bueno, si el rabillo ya apunta bien, dejadlo donde está y moved sólo el bocadillo".

Un enigma que resolví jugando

Al probar la traducción noté algo raro: en el mapa, el primer punto se llamaba "Aldea del Florecer", pero al entrar en el pueblo el rótulo decía "Aldea de la Partida". ¿Un pueblo dentro de otro pueblo?

El análisis técnico decía que el mapa leía la tabla desplazada una posición, y la propuesta fue "corregirlo". Menos mal que antes fui a comprobarlo al juego, porque habría sido un error grave: al llegar al segundo punto, el mapa decía "Aldea de Kintaro" y dentro también. Al tercero, "Aldea del Dormilón" en los dos sitios. Todo coherente.

La explicación apareció avanzando en el primer nivel: hay dos aldeas. La primera, nada más empezar, es la aldea natal de Momotaro (タビダチノ村, "la aldea de la partida", de ponerse en camino), donde viven sus padres. Siguiendo el recorrido se llega a una segunda, que ya es la del Florecer, la que el mapa señala como punto 1.

Es decir: ese desplazamiento no es un bug, es la forma que tiene el juego de saltarse el pueblo natal, que no tiene punto propio en el mapa. Si lo hubiéramos "arreglado", habríamos roto la correspondencia entera.

Segunda vez que una comprobación dentro del juego evita que se rompa algo que funcionaba. Y van...

Resuelto el rótulo, quedaba un detalle estético que me molestaba: la caja tiene un ancho fijo, pero los nombres no. "Isla Ogros" son diez letras dentro de un bocadillo pensado para veinte, con un hueco enorme a la derecha.

El japonés no tiene ese problema porque sus nombres son todos de longitud parecida. El castellano es mucho más irregular.

La solución: tres cajas en vez de una

En lugar de calcular el ancho sobre la marcha (lo que obligaría a rehacer la lista de piezas en cada fotograma), se preparan varias cajas de antemano y se elige la que toca:

12 letras -> caja de 128 px
16 letras -> caja de 160 px
20 letras -> caja de 192 px


Una pequeña tabla dice qué ancho necesita cada nombre. Sin cálculos por fotograma, sin riesgo de que el juego vaya a tirones.

Además, en el mapa el ancho condiciona dónde puede colocarse la caja: una de 128 píxeles cabe en sitios donde una de 192 se saldría de la pantalla. Así que las posiciones se recalculan también según el ancho de cada nombre.

Y un detalle que ya hacía Hudson

Al mirar el original para esto, apareció algo que me hizo gracia: los japoneses centraban el texto metiendo espacios delante y detrás. Sin código, sin lógica, a mano. Un espacio aquí, dos allá. Exactamente lo que yo iba a proponer.

Treinta y cinco años después, la solución sigue siendo la misma.

Este capítulo no va del juego, sino del método. Y creo que es de las cosas más útiles que puedo compartir, porque ha cambiado por completo el ritmo del proyecto.

El diario

Todo lo que se investiga se apunta en un diario de trabajo. Ya van más de cien entradas y unas cinco mil líneas. Pero lo importante no es lo que se escribe cuando algo sale bien, sino lo que se escribe cuando sale mal:

Las hipótesis falsas no se borran. Se marcan como descartadas, con el motivo.

Suena a burocracia y es exactamente lo contrario. Media docena de veces hemos estado a punto de repetir un error ya cometido, y el diario lo ha impedido. En una ocasión, un análisis proponía revertir un cambio que resultó ser el arreglo de un bug anterior: leer el diario evitó el desastre.

Las normas

Cada vez que un error nos cuesta tiempo, se convierte en una norma. Ya hay más de cincuenta. Algunas son específicas de este juego, otras valen para cualquier proyecto:

• Medir contra la pantalla, no contra la teoría.
• Una corrección también hay que medirla.
• Lo medido en una fuente no vale para la otra.
• Antes de dar por libre un hueco de memoria, comprobar qué hay dentro.
• Antes de dar por libre una dirección, comprobar quién la llama.
• Antes de parchear una ruta, comprobar que está viva.
• Un cambio debe ser seguro por construcción, no por comprobación.
• "Afecta a todo el juego" hay que contarlo, no suponerlo.
• Un sprite que "sobra" no sobra: es algo que se ha quedado sin sitio.
• Antes de inventar una variable, comprobar si el dato ya está a mano.

Todas nacieron de errores reales. Varios de ellos están contados en este mismo hilo.

Cada versión, numerada y medida

Ninguna ROM se sobrescribe. Cada versión se numera, se registra su firma y se anota qué bytes exactos cambian respecto a la anterior. Ahora mismo vamos por la 135.

Eso permite dos cosas muy valiosas: volver atrás sin miedo, y hacer bisección. Si algo se rompe, se prueban las versiones intermedias hasta dar con la que introdujo el fallo. Ha funcionado varias veces.

Verificar por construcción

La lección más útil de todas: no basta con que el programa que genera la ROM haga lo correcto. Tiene que comprobar que lo ha hecho.

Cada constructor incluye comprobaciones automáticas: que el byte que se va a sustituir es el esperado, que el hueco donde se escribe está realmente vacío, que ninguna pieza se sale de la pantalla, que ninguna línea supera el límite, que las zonas que no debían tocarse siguen idénticas.

Esas comprobaciones han cazado, sólo en la última fase, un salto que provocaba un bucle infinito, un parche escrito en una rutina que nadie ejecutaba, un cálculo mal hecho que leía fuera de una tabla y un bloque de datos a punto de escribirse encima del final de otro.

Ninguno de esos cuatro errores llegó a la ROM. Y eso, en un proyecto donde cada prueba supone arrancar un emulador y jugar hasta la pantalla afectada, vale su peso en oro. Porque el que arranca el emulador soy yo.

Y sobre trabajar así

Si algo he aprendido en estas semanas es que esto no funciona como mucha gente imagina. No es pedir "tradúceme el juego" y esperar. Es una conversación larguísima en la que uno aporta el conocimiento técnico y el otro aporta contexto, criterio, ojos y muchas horas de emulador.

También he aprendido a discutir. Cuando algo no me cuadra, lo digo, aunque no tenga ni idea de por qué. Y varias veces he tenido razón, no porque supiera más, sino porque estaba mirando la pantalla mientras el análisis miraba el código. Al revés pasa igual de a menudo: suelto una teoría con toda mi convicción y una medición de treinta segundos la desmonta.

Ese ir y venir es, para mí, lo más interesante de todo el proyecto.

A día de hoy, el proyecto cuenta con:

• prompt "PULSA BOTÓN RUN" traducido;
• menú principal EMPEZAR / CONTINUAR correcto;
• selector CANTO DE JIZO / CARGAR ensanchado y legible;
• pantalla de carga con la pregunta en una línea, sin bloque negro ni artefacto;
• pantalla de carga funcionando con varias partidas guardadas;
• selección de dificultad con textos y bocadillo correctos;
• pantalla de password completamente traducida y funcional;
• botón II en el password con comportamiento condicional: con partida al selector, sin partida al título, y verificado en Beetle y Mesen;
• charla de introducción traducida y paginada, con minúsculas y acentos;
• tutorial del inicio traducido, con bocadillo de 20 celdas;
• escena de los padres traducida, con bocadillo de tres líneas;
• nombres de las nueve localizaciones traducidos;
• rótulos de aldea y de mapa ensanchados y ajustados al texto;
• passwords secretos originales verificados.

Quedan por delante:

• centrar el texto dentro de los rótulos;
• el menú que aparece al pulsar SELECT;
• los bocadillos que salen junto al personaje al pulsar RUN;
• la conversión de los bocadillos verticales a horizontales, que es la pieza grande: si todos comparten la misma estructura, arreglado uno quedarían arreglados todos, y eso permitiría traducir el grueso del guion casi en bloque;
• el guion completo: aldeanos, tiendas, objetos y escenas;
• las tiendas, que ahora mismo muestran artefactos y dejan el marcador corrupto al salir;
• el "Modo Súper Difícil" cuando se desbloquea, para que su nombre largo no desborde;
• posibles alias para passwords secretos.

Una IA no sustituye el proceso de investigación. Forma parte de él.

Si has llegado hasta aquí, ya sabes que detrás de cada pantalla "sencilla" de este juego hay horas de ensamblador, memoria, pruebas, emuladores y paciencia.

Y quiero terminar como empecé: yo no sé romhacking. Lo que sé es qué quiero conseguir, mirar con atención, jugar mil veces la misma pantalla y decir "esto no está bien" cuando algo no está bien. El trabajo técnico, que es la parte durísima, lo hace la IA. Sin ella este proyecto no existiría, así de claro.

Pero también he descubierto que mi parte no sobra. Que preguntar lo obvio a veces destapa el atajo, que una corazonada delante de la pantalla puede ahorrar días, y que alguien tiene que jugar, mirar y decidir. Nos hemos equivocado los dos, bastantes veces, y casi siempre nos hemos corregido el uno al otro.

Creo que formamos un buen equipo. Y lo mejor es que hace un año esto habría sido sencillamente imposible.



Gracias por leer. Y, cuando salga la traducción, espero que la disfrutes con la misma ilusión con la que la hemos construido.