Infinite PokémonWhy generative gameplay needs an authoritative game engine
Letting a model invent content is useful. Letting it redefine combat, grant inventory, or execute arbitrary code is a different and much riskier design. Infinite Pokémon draws a hard boundary between creative generation and game authority.
The model proposes; the engine decides
The generation harness can suggest names, descriptions, biome choices, story hooks, creature profiles, NPC policies, and bounded interior layouts. TypeScript code remains responsible for legal movement, damage, capture odds, item effects, prices, rewards, collision, and saving.
Generated output is structured data. It never becomes JavaScript, shell commands, or arbitrary HTML inside the game. The compiler converts accepted recipes into objects the existing engine already understands.
Validation protects both play and continuity
Schema validation answers whether a proposal has the right shape. Geometry validation answers whether exits, doors, tutorial roles, and important services remain reachable. Dependency checks answer whether the world changed while the proposal was being prepared.
These checks do not prove originality, balance, or narrative truth. They create a dependable mechanical floor so creative quality can be judged separately from whether the game still works.
Failures remain visible
A destination that is still queued, generating, failed, paused, or disconnected keeps the trainer on the current side of the boundary. The interface reports the real state and offers retry or cancellation instead of pretending generation is complete.
This is a useful general pattern for AI-native games: make uncertain work asynchronous, keep the deterministic loop responsive, and expose the boundary between a proposal and accepted state.
Continue reading
Editorial basis: written from the project’s implementation, tests, and versioned documentation with assistance from OpenAI Codex. Claims are limited to the current prototype.