Los proyectos de Decompilación nos permiten pasar de modificar o "hackear" copias de ROMs (con los problemas que esto último conlleva), a modificar un código fuente y unos ficheros equivalentes a los que tenía Game Freak cuando desarrolló los juegos oficiales. Esto nos facilitará mucho el trabajo, y nos permitirá evitar muchos de los errores no recuperables que se producen al trabajar en RH binario, muchas veces por la acción de las propias herramientas utilizadas. (A todo el que ha trabajado en binario, ha perdido algún ROM porque A-Map, XSE, o la herramienta que sea se lo ha corrompido).
Los proyectos de Decompilación de Pokémon se encuentran bajo el usuario de nombre pret (Pokémon Reverse Engineering Team) en Github:
Actualmente, pret cuenta con los siguientes proyectos de Decompilación:
- Esmeralda - pokeemerald
- Rojo Fuego - pokefirered
- Diamante - pokediamond
- Ruby - pokeruby
- Mistery Dungeon Red - pmd-red
- Pinball R&S - pokepinballrs
- Esmeralda [Jap] - pokeemerald-jp
**Además de los proyectos de Decompilación, pret cuenta con proyectos de Desensamblaje. Estos contienen código en lenguaje ASM (pokecrystal, pokestadium, pokepuzzle, poketcg y pokeyellow).
La situación de Decomp en la comunidad
Usar Decompilación representa una mejora sustancial respecto al Rom Hacking tradicional en binario por muchos motivos. A pesar de esto, la mayor parte de la comunidad hispanohablante prefiere seguir usando los métodos "de toda la vida" para hacer sus juegos de Pokémon en GBA.
Esto se debe principalmente a que hay menos tutoriales (en castellano) y a la propagación por la comunidad de una serie de "mitos" sobre Decomp. En lo que queda de artículo intentaré desmentir varios de estos, y voy a exponer por qué usar Decomp no es solo una opción viable, si no que debería ser elegida sobre RH binario en prácticamente cualquier caso.
#1. Para usar Decomp es necesario saber programar.
Esto es una verdad a medias, ya que cuando la gente dice esto se suele olvidar de lo que ocurre con su contraparte, el RH binario.
Es cierto que es necesario modificar el código para cambiar algunas cosas en Decompilación, pero para modificar esas mismas cosas en RH binario también tienes que programar. La diferencia es que en el caso de Decomp, estamos hablando de leer, escribir y modificar código en C; mientras que en RH binario tendremos que hacer un tedioso proceso de ingeniería inversa, para ver dónde y cómo podemos inyectar nuestro código escrito en ASM.
Aquí es donde viene la pregunta, ¿dirías que programar en ASM es un requisito indispensable para hacer un juego en RH binario? No, ¿verdad? Entonces, tampoco te será necesario programar en C para hacer ese juego en Decomp.
La realidad es que la mayor parte de las personas que trabajan en RH binario no saben, ni necesitan saber programar en ASM. De la misma manera, esas personas no necesitarán saber programar en C para usar Decompilación.
Además, sea cual sea el caso, creo que el código C de Decomp es bastante más legible que los bytes en crudo o un troncho de código ASM sacado del debugger. Os dejo unas imágenes para que podáis comparar, y escojáis la que os parezca mejor para vuestra salud mental. (No sé vosotros, pero yo me quedo con el de arriba).
Estas 3 imágenes contienen exactamente el mismo código -CreateMon-, representado de formas distintas.
-------------Código C - Decompilación-------------
-------------Hex Crudo (bytecode) - RH Binario ------------------------- ASM@thumb - RH binario (No$gba debugger)-------------
#2. Decomp es más difícil que binario.
Esto es simplemente falso. En Decomp, la mayor parte de las tareas que se hacen con frecuencia (crear mapas, scripts, modificar gráficos, trainers, tilesets, etc), son muy similares a su contraparte en RH binario.
Por ejemplo, todo lo relacionado con los mapas y los tilesets se puede modificar trabajando con una aplicación llamada Porymap, el editor de mapas de Decomp.
Porymap es el sucesor moderno de A-Map para Decompilación. Posee más funciones, es más rápido y más sencillo de usar. A diferencia de A-Map, Porymap es de código abierto y recibe actualizaciones y mejoras constantes. Esto es maravilloso ya que, si hay algo que funciona mal, no tendrás que esperar 10 años a una actualización que no llegará nunca (Sí, me refiero a ti, estúpido Advance Map 1.95. Nadie te quiere).
Scripting
Otro de los puntos que la gente cree que es peor en Decomp es el scripting. Los scripts de Decomp son exactamente iguales que los scripts de RH binario en XSE. Obviando, claro está, que resultan mucho más fáciles de leer y editar en Decomp. Para el que lo quiera consultar, aquí tenéis una lista completa de los comandos de scripting y la documentación complementaria de los mismos para decomp.
Al igual que antes, os dejo el mismo script visto en Decomp y abierto posteriormente con XSE.
--------------------------- Script XSE | RH Binario ----------------------------------------- Script .inc | Decompilación ---------------------------
He de añadir, que además del horrible sistema de scripts de toda la vida, en Decomp se puede hacer uso de Poryscript, que nos facilitará bastante la tarea de hacer los scripts. A continuación podéis ver el mismo script anterior realizado en Poryscript.
------------------------- Poryscript | Decompilación -------------------------
Cambiar gráficos
Creo que cualquier persona que haya trabajado en RH binario sabe lo tremendamente pesado que puede ser encontrar y cambiar una imagen dentro del ROM. En Decomp es bastante sencillo, os dirigís a la carpeta graphics, buscáis la imagen en cuestión y la editáis. Tan sencillo como sustituir una imagen en una carpeta de vuestro equipo.
#3. Decompilación tiene menos recursos que binario.
Si bien es cierto que no hay muchos tutoriales en el foro, hay más recursos y de mayor calidad para Decompilación que para binario. Esto se debe a que, desde hace ya tiempo, muchos de los usuarios de la comunidad inglesa están trabajando en Decomp.
Desarrollar todos estos recursos para Decomp es más fácil y rápido, además de dar mucha más libertad a la hora de arreglar los errores de los mismos. Por si esto no fuese suficiente, de cara al usuario final (nosotros), estos recursos son mucho más flexibles que en binario, ya que podemos instalarlos, actualizarlos y desinstalarlos según necesitemos.
En binario, por otro lado, una vez instalas el CFRU, te quedas con él, y si en algún momento descubren algún error o sale alguna versión nueva, no podrás usarlo a no ser que pases todo tu trabajo a otra ROM nueva.
A continuación, os dejo algunos de los recursos más usados.
Battle Engine Upgrade de DizzyEgg
Se trata de un engine de combate actualizado hasta la 7ª gen. Incluye lo siguiente:
- Todos los Pokémon (7ª gen).
- Ataques con animaciones (7ª gen).
- Habilidades (7ª gen).
- Objetos (7ª gen).
- Split físico-especial.
- Tipo Hada.
- Megaevoluciones.
- Multi combates (cooperativo con IA).
- Mensajes de entrenadores en mitad del combate.
Sistema de paletas dinámicas para los NPC
Este sistema es similar al que existe en Fred para binario, aunque no presenta los numerosos bugs que traía este último.
Gracias a este sistema, las paletas de nuestros NPC se irán cargando de forma dinámica en memoria (según necesite el juego), permitiéndonos usar muchas más paletas para nuestros NPC. Para los que no lo sepan, en el juego original hay 4 paletas comunes para los NPC cargadas en todo momento, así como una paleta que se carga de forma dinámica (lo que fuerza a casi todos los overworld a compartir unas pocas paletas).
Este sistema también elimina las paletas de reflejo, así que ya no tendremos que preocuparnos de ellas al insertar nuevos NPC. A pesar de esto, y a diferencia del sistema de paletas dinámicas de Fred, en Decomp sí es compatible con los reflejos del NPC en el agua.
La diferencia es que la paleta de colores del reflejo se calcula en el código, realizando varios operaciones sobre la paleta normal. Esto elimina el sistema original, el cual requería de la creación de dos paletas por parte del usuario para cada NPC: la paleta normal y la paleta de reflejo.
Sistema de triple capa para los mapas
Como algunos seguro que ya sabéis, GBA tiene 4 capas de vídeo BG0-BG3. En los juegos de Pokémon, la superior de estas capas (BG0), es usada para imprimir texto; mientras que las otras 3 (BG1-BG3) son usadas para cargar los gráficos del mapeado. BG1 se carga por encima de los NPC y el jugador, mientras que BG2 y BG3 van por debajo de los mismos.
Teniendo en cuenta que se usan 3 capas de vídeo para cargar los gráficos del mapa, uno podría esperar que cada "bloque" o "metatile" del mapa contase con estas 3 mismas capas. Sin embargo, cada metatile cuenta únicamente con 2 capas de gráficos (quedando siempre una vacía), dándonos a elegir en que 2 capas de BG1-BG3 queremos que se dibujen los gráficos del metatile.
Para poder aprovechar mejor el sistema que carga los gráficos de los mapas, se ha desarrollado un sistema de triple capa, que como podréis adivinar, nos permite hacer uso de las 3 capas en cada uno de nuestros metatiles. Esto facilita bastante la creación de los mapas y permite ahorrar espacio en el Tileset, acercando un poco más el mapping al de RPG Maker.
-------------------- Sistema de triple capa en Porymap --------------------
Últimas palabras
Por si aún no os habéis enterado, en la comunidad inglesa el RH binario ha muerto, y todo el mundo se ha pasado a Decompilación. Spherical Ice está pasando Pokémon Gaia, Ghoulslash está haciendo lo mismo con su juego, y Sovereign of the Skies ha sido rebooteado en Decomp.
Mientras tanto, en la comunidad hispana sigue prevaleciendo el uso del RH binario. Esto se debe en parte a una falta de información, así como a la existencia de ciertos prejuicios respecto a Decomp. Espero haber disipado alguno de ellos en este artículo.
Las cosas están cambiando drásticamente en el desarrollo de fangames de Pokémon para GBA, y nosotros no nos podemos quedar atrás. Os recomiendo que probéis Decomp, y que lo uséis para trabajar durante un par de semanas, no os arrepentiréis.
¿Seguiréis abriendo un back up con HxD para modificar un número mágico en HEX, o le daréis una oportunidad a Decompilación?
La elección es vuestra.
Más sobre Decompilación
Si aún no os habéis decidido, estad atentos a las noticias publicadas en la web. Cubriremos las ventajas que ofrece Decomp vs RH Binario de forma extensa en un próximo artículo de la Web.
Por otro lado, si no podéis esperar a probar Decomp, os recomiendo que estéis atentos a los tutoriales en la Web y el Foro.
Comentarios