Generating a Pokémon of Your Own: An In-Game Research Prototype

Overview

I built a research prototype that 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. The prototype generates its appearance, name, type, base stats, moves, and the data needed to integrate it into the game.

The prototype connects in-game conversation, word selection, background generation, wild encounters, capture, and naming without stopping the game. Each generated species is registered in a form that the existing game systems can use.

My focus was the generation framework rather than the model itself: defining requirements that preserve game balance and visual consistency, then letting AI explore within those boundaries. I also played the prototype myself to make a preliminary assessment of whether a one-of-a-kind character was enough to create attachment.

Question: does being one of a kind create attachment?

Games let players choose, raise, and name characters until they feel uniquely their own. But the starting point is still a set of options prepared by the developer. If generative AI let players shape a character from the outset, would they feel a stronger attachment?

A generated image alone is not enough to explore this question. The character needs to enter the game world, be encountered and caught, and remain available for play afterward. I created two routes with different levels of player involvement: talking to the old man triggers generation without input, while talking to the old woman lets the player choose six words. The first character the player speaks to determines the generation method for that playthrough.

The prototype does not establish a conclusion about attachment. Its purpose is to integrate generated content into ordinary play and identify conditions for future comparisons.

How it plays

The sequence below shows the player-guided route. In Petalburg Woods, the player talks to an old woman and selects six words from the game’s existing Easy Chat vocabulary. Generation continues in the background as the player keeps playing. A cry signals that the new species is ready; entering the tall grass triggers an encounter, and the player can catch it using the usual controls. Each generation produces a name, type, base stats, moves, front and back battle sprites, and a party icon. The demo video shows the complete sequence.

Design challenge: keeping generated characters playable

Generating a new character and making it work within a game are separate challenges. Stats that are too high can disrupt the game’s difficulty balance, while mismatched types and moves can make a character difficult to train. An overly complex design can become unrecognizable when reduced to a 64 × 64-pixel sprite.

Fixing every detail would remove the point of generating a different result each time. I needed to distinguish the elements essential to gameplay from those that could vary.

I therefore focused on designing the space of possible Pokémon rather than a single character. People define the goals, constraints, prohibited content, and validation methods; AI develops candidates within that framework. This working prototype puts my constraint-driven design approach into practice.

Approach: defining the conditions for generation

The system asks a large language model (LLM) to fill predefined fields such as name, type, base stats, moves, body shape, and color, rather than write free-form prose. A validator checks each response before it is accepted. When a response breaks a rule, the system returns the specific violation and asks the model to regenerate until the requirements are met.

1. People define the boundaries. Requirements for game balance, readable sprites, and acceptable content become explicit rules that can be checked.
2. AI develops candidates. The model uses the player’s words to propose values for the permitted fields.
3. The system checks the output against the rules. It checks numerical ranges, move combinations, and prohibited content automatically.
4. Feedback targets only violations. A candidate that breaks a rule is returned with the reason and regenerated.

Constraints that protect gameplay. I set the base stat total to 280–360, with upper and lower limits for each stat. Moves were extracted from the game’s source code and restricted to moves matching the species’ type or Normal-type moves. One-hit KO, self-destructing, fixed-damage, and excessively powerful moves were excluded. The validator also checked the number of attacking moves and whether the species had moves matching its type. Catch rate, growth rate, and other factors were fixed to keep generated differences within a range suitable for comparison.

Constraints that preserve visual clarity. Body shapes are selected from options with silhouettes that remain readable at small sprite sizes. The vocabulary for colors and features is also restricted. Human-like features, blood, weapons, and text are excluded. Image-generation instructions always include safeguards such as “one creature only,” “show the full body,” and “no extra limbs.”

In one recorded run, the model initially proposed a base stat total of 380. The validator detected the violation and requested regeneration, eventually producing a specification with a total of 320. The contribution was a process that rejects outputs outside the defined constraints, rather than relying on a successful result by chance.

Keeping the experience inside the game

The player uses only in-game conversations, word selection, and encounters in the grass; there is no separate generation screen. Computationally intensive work runs in a Python process on the PC, which exchanges data with the game through files. Lua scripts running in the mGBA emulator connect the two, preserving the game’s familiar controls while keeping AI processing external.

1. Generate the specification. A local language model turns the six words into species data, which is validated before use.
2. Generate the visuals. An image model creates a reference illustration, then visually consistent front and back sprites and a party icon.
3. Convert to game data. Images are reduced to 15 colors, then converted and compressed into sprites and palettes compatible with the Game Boy Advance (GBA).
4. Integrate into the running game. Data is written to a reserved area, introducing the new species without restarting the game.

The same data is also written to disk, so the generated species persists when the game is reloaded. Generation happens only once and cannot be undone. If the player flees or loses the encounter, the Pokémon remains in the world. If the player defeats it, it never appears again. This irreversibility makes “only one in that playthrough” part of the experience.

What the prototype confirmed

I built this prototype on my own to test technical feasibility. It is neither a finished game nor a user study. The following distinguishes what I verified, what I implemented, and what remains untested.

• Verified end to end. In mGBA, I confirmed the full sequence from in-game conversation and six-word input through background generation, integration into the running game, wild encounter, capture, and nickname entry.
• Implemented for future comparison. I added two entry points: passive generation without input and player-guided generation through word selection. Conversations, encounters, and captures can be logged for comparison.
• Connected to existing systems, but not tested through extended play. Leveling up after capture, learning moves, battling, storing Pokémon in boxes, and continued use after saving are integrated with the existing game systems. I have not tested these through long play sessions.
• Future work. Generating evolved forms during play has not been implemented, and comparative studies of attachment with multiple participants have not been conducted.

What I learned from playing: uniqueness alone did not make me feel attached

Playing the prototype myself did not make me feel strongly attached to the generated Pokémon. This is my own impression as the developer, not a result that can be generalized to other players. It did, however, suggest what to vary in a future comparison.

Two factors seemed worth investigating.

• Output quality. If the appearance and character concept are not appealing enough, being “the only one in that playthrough” may not be enough to sustain attachment.
• Depth of involvement. Choosing six words made the result feel more like something delivered to me than something I had created. I suspect that involvement depends on the quality of the creative process: reconsidering choices, comparing alternatives, revising details, and taking responsibility for the result, rather than simply providing more input.

By contrast, I feel attached to Hanagitsune, a character I created outside the automated game pipeline through repeated conversations with several generative AI tools and manual refinement. I compared candidates, corrected details, and continued until I was satisfied. I think both the quality of the result and my involvement in the iterative process contributed to that attachment.

This prototype does not answer whether generated content creates attachment. It turns that broad question into two factors that can be varied deliberately: output quality and depth of involvement. A future study would add opportunities to choose, compare, and revise during creation, bring outputs to a consistent quality level, and compare experiences across multiple participants.

Implementation

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