Generar un Pokémon propio: un prototipo de investigación dentro del juego

Visión general

Construí un prototipo de investigación que genera una nueva especie de Pokémon a partir de seis palabras elegidas durante la partida. Unos minutos después, aparece en la hierba alta, donde el jugador puede encontrarla, capturarla y ponerle un mote. El prototipo genera su apariencia, nombre, tipo, estadísticas base, movimientos y los datos necesarios para integrarla en el juego.

El prototipo conecta la conversación dentro del juego, la elección de palabras, la generación en segundo plano, los encuentros con Pokémon salvajes, la captura y la asignación de un mote sin detener la partida. Cada especie generada se registra en un formato que los sistemas existentes del juego pueden utilizar.

Me centré en el marco de generación más que en el modelo: definir requisitos que preserven el equilibrio del juego y la coherencia visual, y dejar que la IA explore dentro de esos límites. También jugué personalmente con el prototipo para valorar de forma preliminar si un personaje único bastaba para generar un vínculo afectivo.

Pregunta: ¿ser único genera un vínculo afectivo?

Los juegos permiten elegir, criar y dar nombre a personajes hasta sentirlos como algo propio. Sin embargo, el punto de partida sigue siendo un conjunto de opciones preparadas por el desarrollador. Si la IA generativa permitiera a los jugadores dar forma a un personaje desde el principio, ¿sentirían un vínculo más fuerte?

Una imagen generada por sí sola no basta para explorar esta pregunta. El personaje debe entrar en el mundo del juego, poder encontrarse y capturarse, y seguir disponible para jugar después. Creé dos vías con distintos grados de participación: hablar con el anciano activa la generación sin aportar datos; hablar con la anciana permite elegir seis palabras. El primer personaje con el que se habla determina el método de generación para esa partida.

El prototipo no establece una conclusión sobre el vínculo afectivo. Su finalidad es integrar contenido generado en el juego habitual e identificar condiciones para comparaciones futuras.

Cómo se juega

La secuencia siguiente muestra la vía guiada por el jugador. En el Bosque Petalia, el jugador habla con una anciana y selecciona seis palabras del vocabulario existente del sistema de frases del juego, Easy Chat. La generación continúa en segundo plano mientras sigue jugando. Un grito indica que la nueva especie está lista; entrar en la hierba alta desencadena un encuentro y permite capturarla con los controles habituales. Cada generación produce un nombre, tipo, estadísticas base, movimientos, sprites (gráficos de los personajes) de frente y de espaldas para el combate y un icono de equipo. El vídeo de demostración muestra la secuencia completa.

Reto de diseño: que los personajes generados sean jugables

Generar un personaje nuevo y hacer que funcione dentro de un juego son retos distintos. Unas estadísticas demasiado altas pueden alterar el equilibrio de dificultad; una combinación inadecuada de tipos y movimientos puede dificultar su entrenamiento. Un diseño demasiado complejo puede resultar irreconocible al reducirse a un sprite de 64 × 64 píxeles.

Fijar todos los detalles eliminaría el sentido de generar un resultado distinto cada vez. Necesitaba distinguir los elementos esenciales para la jugabilidad de los que podían variar.

Por eso me centré en diseñar el espacio de Pokémon posibles, más que un personaje concreto. Las personas definen los objetivos, las restricciones, el contenido prohibido y los métodos de validación; la IA desarrolla candidatos dentro de ese marco. Este prototipo funcional pone en práctica mi enfoque de diseño guiado por restricciones.

Enfoque: definir las condiciones de generación

El sistema pide a un modelo de lenguaje de gran tamaño (LLM) que complete campos predefinidos, como nombre, tipo, estadísticas base, movimientos, forma corporal y color, en lugar de redactar texto libre. Un validador comprueba cada respuesta antes de aceptarla. Cuando una respuesta incumple una regla, el sistema devuelve el incumplimiento concreto y pide al modelo que vuelva a generar hasta satisfacer los requisitos.

1. Las personas definen los límites. Los requisitos de equilibrio del juego, legibilidad de los sprites y contenido aceptable se convierten en reglas explícitas que pueden comprobarse.
2. La IA desarrolla candidatos. El modelo utiliza las palabras del jugador para proponer valores en los campos permitidos.
3. El sistema comprueba que el resultado cumpla las reglas. Verifica automáticamente los rangos numéricos, las combinaciones de movimientos y el contenido prohibido.
4. La corrección se centra en los incumplimientos. Un candidato que incumple una regla se devuelve junto con el motivo y se genera de nuevo.

Restricciones que protegen la jugabilidad. Fijé la suma de estadísticas base entre 280 y 360, con límites superior e inferior para cada estadística. Los movimientos se extrajeron del código fuente del juego y se limitaron a los del tipo de la especie o de tipo Normal. Se excluyeron los movimientos de debilitamiento en un golpe, autodestrucción, daño fijo y potencia excesiva. El validador también comprobaba la cantidad de movimientos ofensivos y la presencia de movimientos del mismo tipo que la especie. La tasa de captura, el ritmo de crecimiento y otros factores se fijaron para mantener las diferencias generadas dentro de un rango adecuado para la comparación.

Restricciones que preservan la claridad visual. Las formas corporales se eligen entre opciones cuya silueta sigue siendo legible en sprites pequeños. También se restringe el vocabulario de colores y rasgos. Se excluyen rasgos humanos, sangre, armas y texto. Las instrucciones de generación de imágenes siempre incluyen condiciones como «una sola criatura», «mostrar el cuerpo completo» y «sin extremidades adicionales».

En una ejecución registrada, el modelo propuso inicialmente una suma de estadísticas base de 380. El validador detectó el incumplimiento y solicitó una nueva generación, hasta obtener una especificación con un total de 320. La aportación fue un proceso que rechaza resultados fuera de las restricciones definidas, en lugar de depender de un acierto fortuito.

Mantener la experiencia dentro del juego

El jugador solo utiliza conversaciones, elección de palabras y encuentros en la hierba dentro del juego; no hay una pantalla de generación aparte. El trabajo de cálculo intensivo se ejecuta en un proceso de Python en el PC, que intercambia datos con el juego mediante archivos. Unos scripts de Lua ejecutados en el emulador mGBA conectan ambas partes, conservando los controles habituales del juego y manteniendo el procesamiento de IA en el exterior.

1. Generar la especificación. Un modelo de lenguaje local convierte las seis palabras en datos de la especie, que se validan antes de usarse.
2. Generar las imágenes. Un modelo de imagen crea una ilustración de referencia y después sprites de frente y de espaldas y un icono de equipo con coherencia visual.
3. Convertir a datos del juego. Las imágenes se reducen a 15 colores y después se convierten y comprimen en sprites y paletas compatibles con Game Boy Advance (GBA).
4. Integrar en la partida en curso. Los datos se escriben en una zona reservada para introducir la nueva especie sin reiniciar el juego.

Los mismos datos también se guardan en disco, de modo que la especie generada persiste al volver a cargar el juego. La generación solo se produce una vez y no puede deshacerse. Si el jugador huye o pierde el combate, el Pokémon permanece en el mundo. Si lo debilita, no vuelve a aparecer. Esta irreversibilidad hace que ser «el único de esa partida» forme parte de la experiencia.

Lo que confirmó el prototipo

Construí este prototipo por mi cuenta para comprobar su viabilidad técnica. No es un juego terminado ni un estudio con usuarios. A continuación distingo lo que verifiqué, lo que implementé y lo que sigue sin probarse.

• Verificado de principio a fin. En mGBA confirmé toda la secuencia: conversación dentro del juego, introducción de seis palabras, generación en segundo plano, integración en la partida en curso, encuentro salvaje, captura e introducción de un mote.
• Implementado para una comparación futura. Añadí dos puntos de entrada: generación pasiva sin aportar datos y generación guiada por el jugador mediante la elección de palabras. Las conversaciones, los encuentros y las capturas pueden registrarse para compararlos.
• Conectado a los sistemas existentes, pero sin pruebas de juego prolongado. Subir de nivel tras la captura, aprender movimientos, combatir, guardar Pokémon en cajas y continuar utilizándolos después de guardar la partida están integrados con los sistemas existentes. No los he probado en sesiones largas de juego.
• Trabajo futuro. No se ha implementado la generación de evoluciones durante la partida ni se han realizado estudios comparativos del vínculo afectivo con varios participantes.

Lo que aprendí al jugar: la singularidad por sí sola no me hizo sentir un vínculo

Al jugar con el prototipo no sentí un vínculo fuerte con el Pokémon generado. Es mi impresión personal como desarrollador, no un resultado generalizable a otros jugadores. Aun así, sugirió qué factores variar en una comparación futura.

Dos factores parecían merecer investigación.

• Calidad del resultado. Si la apariencia y el concepto del personaje no son suficientemente atractivos, ser «el único de esa partida» puede no bastar para sostener el vínculo afectivo.
• Grado de participación. Elegir seis palabras hizo que percibiera el resultado más como algo que me entregaban que como algo creado por mí. Sospecho que la participación depende de la calidad del proceso creativo: reconsiderar decisiones, comparar alternativas, revisar detalles y asumir la responsabilidad del resultado, más que simplemente aportar más datos.

En cambio, sí siento un vínculo con Hanagitsune, un personaje que creé fuera del proceso automatizado del juego mediante conversaciones reiteradas con varias herramientas de IA generativa y ajustes manuales. Comparé candidatos, corregí detalles y continué hasta quedar satisfecho. Creo que tanto la calidad del resultado como mi participación en ese proceso iterativo contribuyeron al vínculo.

Este prototipo no responde a si el contenido generado crea un vínculo afectivo. Convierte esa pregunta amplia en dos factores que pueden variarse de forma deliberada: la calidad del resultado y el grado de participación. Un estudio futuro añadiría oportunidades de elegir, comparar y revisar durante la creación, llevaría los resultados a un nivel de calidad uniforme y compararía las experiencias de varios participantes.

Implementación

El proceso de generación, el marco de restricciones y validación, la conversión a datos de GBA y las modificaciones del juego están publicados en el repositorio de GitHub.