AI-Native Games: Put the Model Inside a Deliberate Game Loop

There are two different ways to bring AI into a game. A team can use it to help create the game, or the game can call a model while someone is playing. The second choice changes the product itself, including its timing, rules, cost, and failure behavior.

Tokyo AI’s AI x Games, held on 13 February 2026, examined both sides through indie development, the history of game AI, development workflows, and engineering practice.

Distinguish a production tool from a gameplay dependency

Jerry Chi, Head of Supercell’s Tokyo AI Innovation Lab, explicitly separates AI-powered development from AI-native games. Generating an asset before release gives the team an opportunity to review and revise it. Generating dialogue or behavior during play makes the model part of an ongoing experience.

That distinction changes how success should be evaluated. A development tool can be useful if it saves an artist or engineer time while producing work they can accept. A runtime feature must also support the player’s understanding of the game. It needs to arrive at the right moment and behave consistently enough for choices to feel meaningful.

The design question is therefore what the model adds to play. A flexible conversation, an adaptive companion, or a new way to create an object can be compelling, but each needs a purpose within the game’s broader structure.

Start with the loop the player will repeat

Jun Misaki, Founder and CEO of Pit-Step, uses NINJA CATS: Tactics to explore voice-driven interaction as part of a game concept. His presentation connects collecting, raising characters through conversation, and tactical battles. The voice interaction is situated inside a larger loop rather than standing alone as a technical demonstration.

Misaki also discusses sensory, mechanical, and emotional hooks. This provides a useful lens for an AI feature: does it look or sound distinctive, create an interesting choice, or help the player care about what happens? Merely producing a new sentence on every turn does not answer those questions.

For a small studio, narrowing the feature can make the experiment more informative. One recurring interaction with a clear role in the loop may reveal more than a large world with many loosely connected generated possibilities.

Keep game state understandable

Youichiro Miyake’s programme brings the history of commercial game AI into the discussion, while Masayuki Yamagishi and Gautier Boeda add development and engineering perspectives. That wider context is a reminder that a game includes several kinds of intelligence and control, not all of which need the same technique.

From a systems perspective, expressive output and authoritative state deserve a clear boundary. A character can phrase a response creatively while the game decides whether an item exists, a quest is complete, or a reward has been earned. Otherwise, an improvised line of dialogue can accidentally change the rules the player is trying to learn.

The team also needs a deliberate response when inference is slow or unavailable. A pause may be acceptable in one interaction and disruptive in another. This is a design choice as well as an infrastructure concern.

Foundry’s perspective: prototype one interaction, then test the surrounding game

Consider an illustrative companion character that helps a player solve a puzzle. A PoC can produce charming dialogue. A playable feature must also respect what the player has discovered, avoid revealing a solution too early, and respond usefully when the request is unclear.

We would keep puzzle progress in explicit game state and give the model a bounded view of it. The permitted responses might include a hint, a question, or a reaction, with the game checking any proposed state-changing action separately. The character’s words should not become the authority on whether the puzzle has been solved.

Evaluation can then focus on sequences of play. Does the companion reveal information it should not know? Does it repeat a hint after the player has already acted on it? Can the interaction continue naturally after a delayed response? These tests are more revealing than rating isolated lines for fluency.

The next step is to test with players and observe whether the feature improves the intended experience. Engineering measures such as response time and inference cost matter, but so do confusion, repetition, and whether players understand what they can do next. A more articulate model is not automatically a better game mechanic.

A bounded release makes those tradeoffs easier to examine before the feature becomes a dependency throughout the game. For Foundry Labs’ consumer AI and human-computer interaction work, the opportunity is to connect model capability to a deliberate product loop, with rules and feedback that make the experience coherent.

Sources and further reading

This article draws on the AI x Games - Revolutionizing Game Development and Game Experience programme and the talks identified above. Tokyo AI (TAI) connects researchers, engineers, and industry; explore Foundry Labs’ community work for more context.

Talk materials from Jerry Chi, Youichiro Miyake, and Jun Misaki are available upon request. Please use our contact form and include the event title and speaker name.

Speaker profiles

Jerry Chi. Head of Supercell’s Tokyo AI Innovation Lab. His talk explores new kinds of independent games enabled by AI. LinkedIn.

Jun Misaki. Founder and CEO of Pit-Step, building AI-native games as an independent studio. LinkedIn.

Youichiro Miyake. Lead AI Researcher at Square Enix and Project Professor at the University of Tokyo. LinkedIn.

Masayuki Yamagishi. CEO of NextNinja and game producer. His talk examines AI-driven game development. LinkedIn.

Gautier Boeda. AI Engineer at Square Enix. His talk approaches game development from an AI engineering perspective. LinkedIn.

All articles