(ES) (English Below)

Ando en una época de estar relativamente disperso con mis hobbies (hoy estoy escribiendo y actualizando entradas después de dos años y medio con esto olvidado), con lo que muchas veces recurro a emuladores para echar partidas rápidas o viciarme rápido a lo que sea. Durante 2020 ha habido un boom de nuevos ROM Hacks de Pokémon (¿por qué será…?), y he estado bastante pendiente de lo que se cocía en ThePokéCommunity y en el subreddit de PokemonROMHacks. Así volví a toparme con los randomizadores o aleatorizadores (más información, en inglés, aquí y aquí) y uno de mis trabajos favoritos de ingeniería reversa, las decompilaciones de los juegos de Pokémon (GitHub), concretamente el de primera generación (pokered).

Total, que el pasado mes de diciembre estuve probando mi nuevo iPad 10.2″ de 2020 junto con el pencil para organizar y plantear una barbaridad de cosas; desde mis propios proyectos de investigación hasta fichas de personajes, eventos, y random-facts de mi eterno proyecto de world building de Pokémon. Y en eso que estuve ojeando los randomizadores y pensé: ¿No sería maravilloso hacer un randomizador usando scripts que parseen templates de los tipos de archivos Pokémon/Entrenador/Etc y vuelquen información de bases de datos como sprites, ataques, niveles etc?

Y una cosa llevó a la otra, y estuve un par de semanas hiper-absorto en la idea. Yo hago programación en mi trabajo pero no tengo fluidez suficiente para hacer este proyecto, aunque tengo muchísimas ideas. La cuestión es que no debería de ser terriblemente difícil de ir implementando, gracias a lo homogéneos y cohesivos que son los formatos en pokered. La idea principal, descrita a grandes rasgos, es:

1. Generar una base de datos gigante con datos en formato primera generación (pokered) de todo lo que se quiera usar como Pokémons: sprites, tipos, estadísticas, movimientos que aprenden, datos varios… la clave aquí es “lo que se quiera”. Nada impide generar pseudopokémon usando sprites de Digimon, YuGiOh, Telefang, Monster Rancher, fakémon, Moemon, criaturas de otros RPG o videojuegos… Otros tipos de bases de datos se pueden aplicar para clases de entrenador, sprites que usan, Pokémon que usan, …
2. Tener un sistema de scripts que permitan hacer un randomized supervisado, respetando requisitos a elección del usuario para asegurar una experiencia consistente. El ejemplo más claro que se me ocurre es preservar las proporciones de Pokémon de cada tipo, asegurar que aprendan ataques de sus tipos, o que no evolucionen a niveles absurdos. O por ejemplo, asegurar que haya un número limitado de legendarios en localizaciones específicas.
3. Que dichos scripts usen los datos del paso 1 para crear un pool único de Pokémon en cada ocasión, permitiendo randomizer sus tipos, niveles (y métodos de evolución), localización, etc. Lo mismo aplica a ideas como los tipos de entrenador.

Aquí entra en juego algo clave en videojuegos y experiencias de este tipo: las narrativas que genera el usuario para complementar las limitaciones técnicas. Un ejemplo parecido a esto son los memes de los nuzlockes y todos los runs que hace la gente usando roms randomizadas. Pero hasta aquí nada nuevo, y en el fondo la idea central no es nueva. El randomizador de Sanqui ya hace esto a menor escala, y sin intercalar bichos no-pokémon. El potencial de la idea viene de extender la aleatorización supervisada a otros niveles, como mapas de ciudades, rutas y cuevas, y a los diálogos. Lo segundo es más fácil que lo primero, desde luego. Pero creo que estamos llegando a un punto donde se va a volver posible aleatorizar mapas.

¿Lo bueno de todo esto? que ya escribí parte del pseudocódigo y de decisiones para generar el pooler de los Pokémon, y cómo manejar sus datos. ¿El problema? que no tengo tiempo y me conozco, y acabo con burnout. Así que dejo aquí el pseudocódigo, escrito a mano en un pdf en el propio GoodNotes (y en inglés, pero dudo que eso sea un problema para quien se interese), y al menos que alguien tenga un punto de partida si se anima a seguir con una idea similar.

Enlace al archivo

(EN)

I am in a moment in life where I zone out of my hobbies more often than not (today I am writing and updating blog posts after two and a half years), for which I often resort to emulators to quickly grab something new. There has been a boom of new Pokémon ROM Hacks in 2020 (why would it be), and I have been catching up of what is brewing in ThePokéCommunity and on the PokemonROMHacks subreddit. This is how, once again, I came across randomizers (more information here and here) and one of my favorite works of reverse engineering, the decompilations of Pokémon games (GitHub), specifically the first generation (pokered).

Anyway, last December I’ve been playing around with my new iPad 10.2 ″ (2020) and the Pencil to organize and plan a lot of things; from my own research projects to character sheets, events, and random-facts from my eternal project of Pokémon worldbuilding. When I stumbled upon the randomizers and the decompiled pokered I thought: Wouldn’t it be wonderful to have a randomizer that uses scripts to parse templates of the Pokémon / Trainer / Etc data structure and dump information from databases such as sprites, attacks, levels etc?

One thing led to another and I got hyper fixated in this idea for a couple of weeks. I do coding at work and have a broad grasp of how to conceive and organize coding, but I am not fluent enough at any useful language for this (Python?) to do this project. I have many ideas for it, though. The thing is, it shouldn’t be terribly difficult to implement this way to randomize the ROM thanks to how homogeneous and cohesive the pokered formats are. The main idea, roughly described, is:

1. To generate a giant database with data in first generation format (pokered) of everything you want to use as Pokémon: sprites, types, statistics, leanest, movesets, various data … the key here is “whatever you want.” Nothing stops you from generating pseudopokémon using sprites from Digimon, YuGiOh, Telefang, Monster Rancher, fakémon, Moemon, creatures from other RPGs or video games … think of it as an automated version of inserting other creatures in the game. Other types of databases can be generated and used for trainer classes, sprites that they use, Pokémon that they use, …
2. To have a system of scripts that allow to do a supervised randomization, respecting the user specifications/choices to ensure a consistent experience. The clearest example I can think of is keeping a reasonable ration of Pokémon from each type, ensuring that they learn moves of their newly-assigned types, or that they do not evolve on absurd levels. Or for example, to ensure that there are a limited number of legendaries in specific locations. The potential of this is, everything can be switched on/off or customized with user input, increasing the possibilities even more.
3. For these scripts to use the data from step 1 to create a unique pool of Pokémon each time, allowing randomizing their types, levels (and evolution methods), location, etc. The same applies to ideas like trainer classes.

Something key here comes into play in video games and experiences of this type: the user-generated narratives to fill in the blank spaces, inconsistencies or incongruences due to technical limitations. I.e., think about how we all did it when we got immersed in the games in a 2 inch screen as kids. Another similar example to this is the memes of Nuzlockes and all the runs that people do using random ROMs. But so far there is nothing new my idea. Sanqui’s randomizer already does a lot of these things on a smaller scale, like inserting Pokémon from other generations. The potential of the idea lies in extending supervised randomization to other layers of the game generation, such as city maps, routes and caves, and to the  dialogues and the ‘screenwriting’. The text part is easier than the maps, of course. But I think we’re getting to a point where technology and enthusiasm will soon converge and make possible to randomize maps (think about the possibilities with properly-trained machine learning algorithms…). 

The good thing about all this? I already wrote part of the pseudocode and decisions to generate the pooler of the Pokémon, and how to handle their data. The problem? I don’t have time and I know myself, and I end up burnt out. So I leave the pseudocode here, handwritten in a GoodNotes PDF file, so at least someone may have a starting point if they decided to go for a similar idea (or to continue with this one).

Link to the file