What SIMA 2 Could Actually Mean for Game Developers Still Wrestling With NPC Scripts

Anyone who has spent a meaningful amount of time building games professionally knows that NPC behavior is one of those problems that looks straightforward on a design document and turns into something far messier once it meets actual players. The logic appears clean at the start — define the states, write the transitions, test the conditions, ship the feature — but players have a way of wandering into situations that nobody anticipated during development, and when that happens, the NPC either freezes, responds completely out of context, or does something that breaks the tone of the entire scene.

At that point, the developer goes back into the editor, traces through the behavior tree to figure out which branch failed to account for the edge case, patches it, and ships again, only to watch a different edge case surface two weeks later from a different player doing something else nobody expected. This cycle is not a failure of effort or talent. It is a structural limitation of how NPC logic has been built for the better part of two decades, and it sits quietly underneath almost every production game that has ever featured characters meant to feel like they exist inside a world rather than on a track.

The Architecture Problem That Has Never Really Been Solved

Finite state machines were the standard approach for a long time, and they worked reasonably well when games were simpler, and the number of states an NPC needed to manage was small enough to hold in one developer's head. Behavior trees improved on that by making complex conditional logic easier to read, organize, and adjust, and utility AI added a layer of weighted decision-making that gave characters something closer to believable priorities. But all of these systems share the same foundational requirement: a human designer has to anticipate what situations the NPC will face and write explicit responses for each of them before the game ships.

The problem is that anticipation has limits, especially in open-world or sandbox environments where players are not moving through a curated sequence of events. A behavior tree that was thorough enough to cover everything the design team tested can still fail completely when a player approaches an NPC from an angle the level designer never walked through during QA, or completes two quest objectives simultaneously in a way the scripting assumed would always happen sequentially, or simply stands inside a doorway long enough that the NPC's pathfinding logic breaks down.

Post-launch makes this harder in ways that are difficult to fully explain to people outside production. When a content update ships and changes the layout of a space, or adds a new item that interacts with existing systems in ways that weren't fully mapped out, or simply shifts player routing through an area because a new quest marker sends people somewhere different, NPC behavior that was stable before the update can start producing results that look broken to players without a single line of script having changed. The NPC is still following its rules exactly. The rules just no longer describe the world it's living in. Fixing that means a developer — often not the same person who originally built the system — has to go back in, understand what the original logic was trying to accomplish, figure out where the new content has broken that assumption, and rewrite accordingly, all while the support queue fills up with reports from players who think the game is bugged.

What SIMA 2 Is Actually Doing Differently

Google DeepMind's SIMA project has been working toward an approach that doesn't share any of those structural dependencies. Rather than operating through game-specific logic written in advance, SIMA takes in what's on screen visually — exactly what a human player would see — responds to instructions given in natural language, and acts through the same keyboard and mouse interface a human would use, without any special connection to the game's internal code or data structures. There is no behavior tree, no state machine, no list of conditions written by a designer. The agent reads the world as it appears and figures out what to do from that.

SIMA 2, which DeepMind announced in November 2025 and built on top of their Gemini models, takes this significantly further than the original version. Where the first SIMA learned to follow over six hundred specific language-tagged skills — actions like turning left, climbing a ladder, or opening a map — SIMA 2 has a Gemini model embedded as its reasoning core, which means it doesn't just respond to instructions but actively thinks about them, breaks them into steps, evaluates whether those steps are working, and adjusts its approach when they aren't. It can explain what it intends to do before taking action, describe what it observes in the environment while operating, and answer questions from a user without stopping what it's working on.

One of the most important things SIMA 2 demonstrated in testing is that it can perform well in games it was never trained on. The team evaluated it in a Viking survival game called ASKA and in MineDojo, a Minecraft research environment, neither of which were part of the training set, and the agent was able to orient itself, understand what was being asked of it, and make meaningful progress toward goals. That kind of transfer — taking something learned in one context and applying it to a new environment without being retrained — is not something trees do at all. A behavior tree is written for a specific game, in a specific build, accounting for a specific set of situations. When any of those change substantially, the tree has to be rewritten to match.

What This Means for the Problems Developers Actually Run Into

DeepMind is explicit in the games research blog about two specific development scenarios where an agent like SIMA could change how things work in practice.

The first is QA testing during active development, when a build changes frequently and scripted test behaviors become outdated as soon as the thing they were written to test gets modified. An agent that reads the game visually and understands natural language goals doesn't need to be rewritten every time the build changes — it reads what's in front of it and responds to that, which means it can continue testing in a way that reflects the current state of the game rather than a set of hardcoded assumptions about what the game looked like six weeks ago.

The second scenario is post-launch behavior in response to new content or unpredictable player activity. When players do things that weren't anticipated during development — and in any game with a large enough player base, some player will eventually do something nobody on the team considered — a scripted NPC hits the edge of what its logic covers and produces results that feel broken. An agent trained to understand game worlds generally, rather than one specific game specifically, has a better chance of producing something reasonable in situations it hasn't encountered before, because it is drawing on a broader understanding of how game environments work rather than a finite set of rules written about one particular game.

SIMA 2 also demonstrated a self-improvement capability that is worth understanding separately from its in-game behavior. After an initial training phase using human demonstration data, the agent can continue developing its skills through self-directed play in new environments, without any additional data from human players, and the experience it accumulates in that process feeds back into subsequent training generations to produce a more capable version of the agent. This is architecturally different from anything in the scripting toolbox that developers currently work with, and it points toward a system that becomes more capable over time rather than requiring manual updates to keep up with changing conditions.

Where the Real Limits Are Right Now

SIMA 2 is a research project, and DeepMind is clear about what it currently cannot do well. Tasks that require many sequential steps across a long period, where the agent needs to hold a complex goal in mind and verify progress toward it over many actions, are still difficult. The agent's memory within a session is constrained by context window limitations, which matters in situations where earlier events need to inform later decisions. Executing precise, reliable low-level actions — the kind of fine motor control that some gameplay mechanics demand — remains an open problem that the research community as a whole is still working through.

These are genuine limitations for anyone thinking about production use, and it would be inaccurate to suggest that SIMA 2 as it currently exists is ready to replace the NPC scripting pipeline in a shipping game. What it does challenge is the assumption that has been sitting under that pipeline for a long time — that writing enough conditional rules, maintaining them through enough development cycles, and extending them through enough content updates is a workable long-term approach to character behavior in games that keep growing and changing. Developers who have watched that assumption strain under real production conditions already understand where the ceiling is. SIMA 2 is pointing at a different architectural direction, and for the people who build these systems day to day, that is worth taking seriously even before the research reaches production readiness.