My Own Pokémon Generation

Overview

AI generates a new Pokémon species from six words chosen during play. A few minutes later, it appears in the tall grass, where the player can encounter it, catch it, and give it a nickname. This research prototype creates not only its appearance and name, but also its type, base stats, moves, and the data required for it to function in the game.

In the prototype, conversation, word input, background generation, wild encounters, capturing, and naming were all connected into a single experience without stopping the game. New species are registered not just as images, but as species that existing game systems can handle.

The focus was not the generative model itself, but a framework in which people define the conditions that preserve game balance and visual consistency, then allow AI to explore within those boundaries. By playing the prototype myself, I also made an initial examination of whether being one of a kind was enough to create attachment.

Question — Does being one of a kind create attachment?

Games invite players to choose, develop, and name characters until they feel uniquely their own. Yet those relationships still begin with options prepared by the developer. If generative AI allowed a player to shape a character from its very origin, would that create a stronger sense of attachment?

Generating a single image is not enough to investigate this question. The result has to enter the game world, appear as an encounter, be caught, and remain usable afterwards. I therefore created two routes with different levels of player involvement. Talking to the old man triggers generation without input; talking to the old woman lets the player choose six words. Whichever character the player speaks to first determines the generation method for that playthrough.

The prototype is not intended to settle that question. Its purpose is to establish a way to integrate generated content into ordinary play and to identify conditions that future studies can compare.

Flow of play

The following shows the player-guided route. In Petalburg Woods, the player talks to an old woman and chooses six words from the game’s existing Easy Chat vocabulary. Generation continues in the background while the player carries on playing; when it is ready, a cry is heard. Entering the tall grass makes the new species appear, and it can be caught using the same controls as any other wild Pokémon. Its name, type, base stats, moves, front and back battle sprites, and party icon are generated each time. The complete flow is shown in the demo video.

Design challenge — Unconstrained generation breaks the game

The ability of AI to come up with new characters and the ability for those characters to work within a game are separate issues. If their abilities are too high, the difficulty balance breaks, and if their type and moves don't match, they become hard to train. If their appearance is too complex, it becomes impossible to recognize their shape when converted into a 64×64 pixel sprite.

On the other hand, if everything is fixed, there is no point in having something that changes each time it is executed. What is needed is not to take away the AI's freedom, but to separate the parts that should be preserved as play from the parts that can be allowed to change.

The design focus therefore shifted from a single Pokémon to the space in which Pokémon can be generated. People define the goals, constraints, prohibitions, and validation methods; AI produces candidates within that framework. The prototype puts the constraint-driven approach described in my design philosophy into practice.

Approach — Design the conditions for generation, not the output

Rather than asking the LLM for unrestricted prose, the system asks it to fill predefined fields such as name, type, base stats, moves, body shape, and colour. A validator checks every response before it is accepted. If a rule is broken, the system tells the model which one and asks it to regenerate until all conditions are met.

1. People define the boundaries. Game balance, legibility at sprite scale, and prohibited expressions become explicit, inspectable rules.
2. AI develops candidates. Using the player’s words, the model proposes values for the permitted fields.
3. The system validates the rules. It automatically checks numerical ranges, move combinations, and prohibited expressions.
4. Feedback targets only violations. A candidate that fails a rule is returned with the reason and regenerated.

Constraints that protect play. The total base stats were set in the range of 280 to 360, with upper and lower limits also set for each individual stat. Moves were extracted from the game's source and limited to those matching the species' type or Normal type. Furthermore, one-hit KO moves, self-destruct moves, fixed-damage moves, and excessively powerful moves were excluded, and the number of offensive moves and the presence of type-matching moves were also checked. Capture rate, growth rate, and other factors were fixed to ensure that differences due to generation remained within a comparable range.

Constraints that preserve appearance. The body shape is chosen from candidates that are easy to maintain the outline even for small sprites, and the vocabulary for colors and features is also limited. Human-like features, bleeding, weapons, and text are excluded. Finally, conditions to prevent defects, such as 'only one body,' 'full body,' and 'do not create extra limbs,' are always added to the image generation instructions.

According to one record, the model initially proposed a total base stat of 380. The framework detected violations and prompted regeneration, eventually converging to a specification of 320. The important point is not that a good result happened by chance, but that a process was designed in which results that fell outside the framework were not adopted.

Complete the experience within the game

The only things the player interacts with are in-game conversations, word choices, and encounters in the grass. There is no need to open a separate screen for generation. On the other hand, computationally intensive processing is handled by a Python process on the PC, which collaborates with the game via files. By having Lua scripts on mGBA bridge the two, the operation feels like an existing game while keeping the external AI processing separate.

1. Create the specification. A local language model converts six words into validated species data.
2. Create the visuals. An image model draws a reference illustration, then derives visually consistent front and back sprites and a party icon.
3. Convert to game data. Reduce the image to 15 colors, and convert and compress it into sprites and palettes that the GBA can handle.
4. Apply to the game in progress. Write data to the reserved area and introduce a new species without restarting the game.

The same data is written to disk, so the generated species remains after the game is reloaded. Generation happens only once and cannot be undone. If the player runs away or loses the encounter, the Pokémon remains in the world; if the player defeats it, it never appears again. This irreversibility gives “one of a kind” a consequence within the experience.

What the prototype confirmed

This is a feasibility verification created by a single person, and it is not a completed game or a user experiment. The achieved points and unverified areas are divided as follows.

• Verified end-to-end. On mGBA, I confirmed the complete flow from in-game conversation and six-word input through background generation, live game integration, wild encounter, capture, and nickname entry.
• Implemented for future comparison. Two entry points were prepared: passive generation without input and player-guided generation through word selection. Conversations, encounters, and captures can be recorded for comparison.
• There is a foundation, but the scope has not been tested end-to-end. Leveling up after capture, learning moves, battling, storing in the box, and continued use after saving are connected to the existing system, but testing through long hours of play has not been conducted.
• Unimplemented scope. The functions of generating the evolution destination on the spot and conducting comparative experiments on attachment among multiple participants were left as future tasks.

What I learned from playing it — Uniqueness alone did not create attachment

From playing the prototype myself, I did not develop a strong attachment to the generated Pokémon. This is solely the personal impression of the implementer and is not an experiment result that can be generalized. However, it did provide a clue as to what to change next for comparison.

There are two conditions that seem likely to influence attachment.

• The quality of the output. If it does not surpass the level at which one can feel charm in its appearance or settings, the rarity of being 'the only one in the world' alone cannot sustain attachment.
• Depth of involvement. Simply choosing six words made me feel that the result was more 'delivered' to me than 'created by myself.' It can be considered that what generates a sense of involvement is not the amount of input, but the quality of the creation process, such as reselecting, comparing, revising, and taking responsibility for the outcome.

By contrast, I do feel attached to Hanagitsune, a character created outside the automated game pipeline through repeated dialogue with several generative AIs and hands-on refinement. I compared candidates, corrected details, and continued until I was satisfied. This suggests that attachment came from both the quality of the result and a process that involved judgement and iteration.

This prototype does not answer the question, 'Does generated content foster attachment?' It divided the vague question into two elements that can be intentionally altered: the quality of the generated material and the depth of engagement. In the next verification, it will be necessary to incorporate choices, comparisons, and modifications into the creation process, standardize the quality of the generated material, and conduct comparisons among multiple participants.

Implementation

The generation pipeline, constraint and validation framework, GBA data conversion, and game-side modifications are published in the GitHub repository.