These days it's fashionable to brag about your AI achievements, even if all you did was bolt on a pixel-fixer for textures, a job that used to belong to a junior artist. Not a dusty job, by the way, and the artist still does it better and faster than the model, but the spirit of the times says to let go of junior Vasya and hire clever little Claude. And you end up with a rather odd feeling... if neural networks have already learned to recognize images, generate text and music, drive cars, play complex geopolitical strategy games and solve a huge number of problems that until very recently were considered exclusively human, what's stopping us from dropping a model into a modern game and handing it control of an NPC, to make it feel more alive and woven into the lore?
But then you fire up something ultra-modern (Pragmata, PUBG, pick your own), and it suddenly turns out that inside there are still the good old finite state machines, Behavior Trees, heuristics and a ton of ifs telling the NPC that if the player is close enough, attack; if the player ran off, look around for a bit, then shout a bit, then ...pick your own..., and if the search drags on too long, pretend you never noticed anything at all and go back to your NPC business, bravely guarding the loot chest from the cheeky stares of the local wildlife, which, by the way, also runs on heuristics.
And all of this happens in modern AAA projects, where hundreds of threads work on rendering a single frame, physics is computed at several levels of detail, animation uses incredibly sophisticated blending systems and procedural animation, navigation is built on enormous graphs, and developers happily use ML for individual parts of the graphics pipeline, audio processing or content generation. But when it comes to the question "what should this particular NPC be doing right now," it suddenly turns out that the old switch over states is still the best engineering solution.
This looks strange if you view it through the eyes of someone dazed by the ML hype and used to thinking that any sufficiently complex behavior should sooner or later be handed over to a neural net. If we can already train models to play games at a human level, why not take yet another soldier, give him a set of possible actions and let him figure out on his own when to shoot, retreat or look for cover? I'll let you in on a little secret: on one of our recent projects we actually tried this, and you know what happened... after a few fine-tuning cycles, the NPCs stopped putting on a show for the player.
On paper, though, it all looked pretty good, because the game loop of an ordinary NPC really does resemble RML: there's the state of the surrounding world, there's a set of actions, every action changes the state, and there's some reward that tells the system how well it did. Then we start training and wait for the agent to find a strategy that maximizes the reward. It doesn't work... as I said above.
It doesn't work because game development has one nasty quirk that everyone forgets: game AI doesn't have to be "algorithmically smart" at all, but it does have to be "behaviorally human." That's a game design term, don't try to describe it with math, you won't succeed anyway. What's more, the smarter an NPC gets, the worse the game becomes, and the feeling that the world revolves around the player disappears.
Picture a typical situation: the player walks into a room, an enemy spots him, a firefight starts, the player retreats around a corner, the NPC follows, the player keeps backing off, the NPC keeps chasing, then the player ducks into a side corridor and tries to break away again, while the enemy keeps hunting for the target the whole time. Because from the point of view of ML and the information available to it, the player is still somewhere nearby: someone broke into your house and made a racket, so it's reasonable to keep chasing.
Then we drag this model into the game, and the player, after running into a few of these NPCs, realizes the enemy will chase him forever, stops seeing it as an opponent to fight and starts seeing it as a system whose behavior can be exploited. He backs off to the right distance, waits for the NPC to end up in a convenient spot, and turns its predictability against it.
What does the designer do? He puts a timer on the chase, so that after thirty seconds the enemy gives up and goes back. And it doesn't matter at all whether the NPC has actually lost the player, how likely it is that the player is still in the next room, how well the perception system could reconstruct his position, or how logical it would be for a real person to keep searching.
The designer's task lives on a completely different level altogether: it isn't modeling a soldier's behavior in the real world, it's trying to build a sequence of events that will be interesting for the person sitting in front of the screen. Remember that a game is a theater for an audience of one; I'll keep coming back to this.
When we write a regular program, it's enough to clearly define what a correct result means and turn that into an algorithm, but in a game the correct result is very often impossible to define at all, because we care not only about what the computer did, but about what the player felt while it was doing it.
If an NPC lost a fight, that might be a bad outcome because the AI turned out too weak, or it might be a great outcome because after twenty attempts the player finally learned to read its attacks and felt that he had gotten better and "smarter" than the game (this is called the delayed victory effect). The game might deliberately kill you the first few times, no matter how powerful your weapon is, and send you back to respawn, or, the other way around, quietly weaken the boss a bit with every reload, but... shh... you didn't hear it from me, I'm just thinking out loud.
If an NPC killed the player, that might mean the game AI did its job perfectly, or it might mean the designer got the balance wrong and the player simply never had a chance to win. Now we want to teach a neural net all of this, and how exactly are we going to write player enjoyment into a reward function?
The reward function
Let's say we decided to train our enemy with RML after all and started with a function like this: ten points for killing the player, minus five for taking damage and minus a hundred for dying. In other words, we showed the neural net that it should kill the player while trying not to die itself.
And the model finds a strategy where it's far more profitable never to leave cover at all than to risk taking damage. So the NPCs spend the whole game hiding in corners, because from the point of view of the given function that turns out to be a pretty decent strategy. Well... would you enjoy playing that?
Fine, we bump up the kill-the-player reward until it's so large that the other penalties become negligible, and negligible things, as you remember, stop getting any attention. Now the NPCs behave insanely aggressively, because that's what turns out to be mathematically optimal.
Then we add a penalty for chasing too long, and the model gives up on searching for the player entirely, because after a few training runs the potential reward no longer justifies the risk. In the end we don't like the resulting behavior as a whole, so we start tweaking weights, adding extra conditions, introducing new rewards, changing coefficients and running training again, and after a while we almost inevitably run into the fact that fixing one situation affects several others, because the model doesn't know our intentions and doesn't understand what exactly we considered a side effect; it's just trying to find the most profitable strategy within the space we gave it.
We could, of course, keep refining the reward function, but that gradually drags us into a nasty loop: the more details we add to the evaluation function, the more it starts to look like an attempt to describe the entire game design with one giant prompt. At some point a perfectly reasonable question arises: why are we even trying to make a neural network derive rules that we already know and could simply write directly in code?
If the designer says the NPC should stop chasing the player after thirty seconds, then we have no particular reason to make the model discover this rule on its own through training; we can just write it.
if (timeSinceLostPlayer > 30.0f)
returnToPost();Profit... our NPCs started behaving sensibly and predictably. And once you've put a dozen or so of these checks back into the code, you realize that "dumb AI" is a perfectly meaningful part of game design.
The game keeps changing
Okay, say someone used executive authority to push this poor neural net, wrapped in a mile-long prompt, into the game. Then the designer comes along and wants the enemy to be more aggressive, then the level designer comes and says we need to take the player's movement speed into account, a week later the weapons designer adds a new gun and that has to go into the prompt somehow too, then a cover system gets added (I've already written about the cover system, if you're interested), then a new enemy type appears that has to work together with the old one, then it turns out that on one of the maps the NPCs get stuck in doorways way too often. After playtests the first designer comes back and says the enemy feels too predictable and its behavior needs to be changed slightly. Slightly, dammit... have you seen what we've piled up here this month? And this is completely ordinary, normal development.
In that sense Behavior Trees, FSMs or Utility AI look all warm, clear and fluffy, giving you a convenient interface between programmer and designer, because the designer needs to see not just the result of the system's work, and the programmer needs to understand why it picked this particular behavior at this moment.
When there's a behavior tree in front of you, you can open it, curse the designer's clumsy hands and the spaghetti nodes, but still walk it from top to bottom and see that the NPC first checks whether it can attack, then tries to take cover, after that, if the target is lost, starts a search, and only then goes back to patrolling.
If needed, you can add a new condition, reorder priorities, change a wait time, change the search radius or switch off a chunk of behavior entirely, and check the result right away. And this shows clearly why good game AI shouldn't just be an RML system that can make decisions, but a tool that's tuned with sliders and configs, not with a prompt.
Now tell me, how do modern ML models work? If we forget about development convenience for a minute and imagine that by some miracle we already have a perfect neural network capable of analyzing the state of the game world almost instantly and choosing the optimal action, the slider problem doesn't go anywhere.
We really would get a very good decision-making algorithm, but not necessarily a good game opponent. What you get is an NPC that can see the player anywhere on the level, knows the range of its weapon perfectly, instantly picks the optimal cover and understands perfectly when to attack, when to retreat and when to call for backup. What a great... boss, is it? But then the question is: how do you even beat it? Did you come to the game to get stomped all the time, or to do the stomping after a long workday?
If an NPC always picks a position where the player can't reach it, never makes an unnecessary move, reacts instantly to every player action and always uses the most effective attack, then the player won't be able to learn how to win, because he'll just keep dying. A dozen such "victories" and your game goes in the trash as cheating and unbeatable, because there are a dozen other unplayed games waiting in the backlog.
And that's why game developers do some rather strange things to "game AI" that from the outside look like degrading the system. They limit its field of view, add reaction delays, forbid it from using certain abilities too often, reduce its accuracy, introduce "ability cooldowns," make the enemy change position for no particular reason and deliberately leave the player an opening to attack.
If you look at this through the eyes of someone trying to build the most efficient autonomous agent possible, it all looks almost like deliberately making the algorithm worse. Don't look at the game as an engineer; look at it through the eyes of a game designer who needs to build an interesting combat system. The player doesn't need a mathematically optimal opponent, but an opponent whose behavior leaves enough room to observe it, understand it, predict it and ultimately use that knowledge to win. And once again I bring you back to the idea of "theater for an audience of one."
Predictability is game design too
In other words, an overly smart and unpredictable AI turns out to be worse than a simple, nominally dumb one, for which the player can build his own model of the world behind the screen in his head.
First he notices that the enemy shoots, then after a few encounters he realizes that after a certain attack the NPC retreats, then he notices that if he gets within a certain distance, the enemy switches to a shotgun, after which he discovers that if he ducks behind cover and quickly peeks out from the other side, the NPC starts repositioning, and after a few hours of play all of this turns into a kind of internal rulebook that the player starts using completely automatically. This is called "player mastery progression"; game designers spend almost two years learning it... and many still don't get it.
That's the moment "good game AI" is born, which is what games exist for in the first place: the player stops merely reacting to the system and starts understanding it, because he knows both what's happening now and what will happen in a few seconds. That means he can plan his own strategy in advance, or set up the situation he needs, or force the opponent to choose a particular action and then use the outcome of that decision to his own advantage.
But if the NPC's behavior stays unpredictable every single time, it becomes much harder for the player to build such a model, and instead of a feeling of gradual "mastery" you get fatigue from having to guess every time.
That's why some game AIs are made fairly limited, and it doesn't necessarily mean the developers were lazy and couldn't make them smarter. They could, but such limitations let the player see the structure of the opponent's behavior, and without that structure a big part of the space for learning, experimentation and recognizing one's own progress disappears. Most of my colleagues agree that an AI that's too smart destroys immersion, that very "theater for an audience of one."
An NPC has to make mistakes
This is actually one of the most interesting problems in game AI: choosing the right place and time where the system is allowed to be imperfect. Eyesight that's too poor irritates the player and makes the game feel dumb, eyesight that's too good feels like cheating, reactions that are too slow make combat boring, instant reactions make a person feel inadequate, and perfectly chosen positions plus flawless weapon use quickly turn any enemy from an interesting challenge into a "hard game."
So NPCs are left some chance to make a mistake: pick a less-than-ideal cover, stay behind a wall too long, not notice the player's movement right away, or give up the chase after 30 seconds. But these mistakes mustn't look like random glitches; the player should perceive them as a natural part of the character's behavior.
And here a rather subtle difference appears between random stupidity and controlled weakness. When an NPC periodically stares at a wall or starts running aimlessly around the room, the player almost instantly decides the game is broken, but if an enemy sometimes stays behind cover too long, doesn't react to a shot right away or lets itself be flanked, the player may quite naturally decide he's found its weak spot and can now deliberately exploit it in the next encounter.
In terms of internal implementation these two behaviors may be just a few lines of code apart, but in terms of player experience there's a huge difference between them, because in the first case the person discovers a developer's bug, and in the second they discover a new pattern in the game system that can be studied and used.
Where games do use ML
You might think machine learning is a poor fit for games... it isn't, or rather, not quite, because game engines have a huge number of tasks where ML turns out to be a perfectly natural and very useful tool; they just sit a little off to the side of the NPC's actual "brain."
We have huge amounts of motion capture data that needs to be cleaned, smoothed, classified or converted into a more convenient form for further use, and this is exactly where a model works beautifully: you can show it lots of good examples and let it learn to reproduce the needed transformation. But the final pass is still cleaned up by a human; that's called the "human touch."
It doesn't really matter why the model decided to tweak a particular animation frame a little, as long as after processing the motion looks natural and the character stops jittering. The same goes for voice, image processing, facial animation... and so on and so forth
But even in these tasks ML doesn't fully replace existing algorithms, and what looks far more interesting is a combination, where classical code does the work for which the rules are well known and where predictability matters to us, and machine learning is used where formalizing all those rules by hand would be too expensive or practically impossible.
And we finally arrive at the main reason classical game AI keeps living on in the era of Claude and ChatGPT and keeps eating up game designers' effort. A neural net has no trouble at all making decisions; it's no effort for it to go through a huge number of options, compute path costs, evaluate several candidates, pick the maximum or run several thousand checks in a single frame. But when the question is whether an NPC, ten seconds after losing the player, should keep searching, hide, return to its post or give up the chase because at that moment the player will find it more interesting to move on through the level, we're no longer describing a technical problem, we're describing a design vision.
And that vision translates very poorly into a prompt or a reward function, so you end up stuffing in fight duration, the probability of the player dying, the amount of damage dealt, time spent in the danger zone, variety of attacks used, the number of successful dodges and dozens of other parameters. At some point this function starts looking like a separate GDD, and a fairly natural question comes up: do we really need a neural network that will try to derive from these numbers a behavior the designer already knows?
If we know in advance that after losing the player the NPC should search for him for twenty seconds and then return to its starting position, there's little point in making the system discover that pattern on its own. If we know the boss should change phase after losing a certain amount of health, that transition doesn't have to be the result of a multi-million-step training loop. If we know the enemy should sometimes leave the player an opening to attack, that opening can be built directly into its behavior.
There's no technological defeat here, because a designer or game developer is under no obligation to use the most complex technology available where a simpler tool fits.
The old tech is here to stay
When you look at a modern game engine, it turns out that most of its technologies have been around for decades and continue to coexist peacefully with the most modern systems.
Inside a single project you can find ECS, a job system, complex physics, DLSS, world streaming and a huge number of asynchronous subsystems, and right next to them sits some old finite state machine that is essentially still driving the NPCs: after the Chase state it moves them to Search, and after that, if the target is never found, sends them back to Patrol.
FSMs, Behavior Trees, Utility AI and scripting systems let you describe the designer's vision for a specific game, on a specific map, in a specific context, while keeping it transparent enough for the developer that it can be tested, balanced, debugged and changed along with the rest of the game.
Machine learning solves a different problem: it lets you find patterns where describing them by hand is too hard and the number of possible variants is so large that it's much cheaper for the programmer to give the system a huge number of examples and let it find a suitable solution itself.
Meanwhile classical AI can decide that the NPC should be in combat mode right now, the navigation system can find a suitable path to cover, and an ML model can be used somewhere inside the animation or behavior layer to pick a more natural movement, estimate the probability of some event or automatically tune parameters that are hard for a designer to calculate.
This hybrid approach looks far more natural than the idea of replacing all of game AI with one giant neural network, because game AI is rarely a single problem; it always consists of many subsystems, each with its own trade-offs between quality, performance and development cost.
Why games don't use ML
I often hear that games are at the forefront of technological progress; that's both true and not true. In development, technologies don't so much push each other out as get added to the shared toolbox, and an old system keeps living as long as it solves its particular problem well.
If we need to find a path on a navmesh as fast as possible, you don't need a neural net there. If we need to determine what state an NPC is in, we can use an FSM, and again no neural net needed. If we need a convenient way to describe and reorder behavior priorities, we can use a Behavior Tree, and once again no neural net needed. If we need to choose an action based on a large number of parameters, Utility AI will be more convenient than a neural net with prompts. If we need to automatically find a pattern in a huge dataset, well, that's where machine learning is actually needed... or we could sit a crowd of QA testers down to play and tick liked/didn't-like boxes, and get that data that way too.
It would be strange to expect the arrival of neural networks to automatically cancel all other approaches, because the ultimate goal of game development is building a system that has to be made to do exactly what a particular game needs, and to do it fast, reliably and cheaply enough that the team can grow the project, fix bugs and change the original design.
If the designer knows for sure that after thirty seconds of chasing the soldier should stop searching and return to his post, there's nothing particularly modern or outdated about simply writing that rule in code.
But if we need natural character movement across tens of thousands of different situations that can't possibly be enumerated by hand, or need to recover a pattern in a huge dataset that a human can't formalize on their own, that's where machine learning starts to pay off.
And it may well turn out that the future of game AI has nothing to do with replacing all FSMs, Behavior Trees and other classical systems with one universal neural network, and more to do with learning to combine different approaches properly, leaving predictability and control in the hands of the programmer and the designer.
And therein lies the paradox of game AI: we want the computer to be able to make complex decisions, but only as long as those decisions remain part of a game world we can understand, balance and change. The developer's job isn't to prove that the machine can be smart, fast and accurate, but to build a set of rules and exceptions in which the person in front of the screen remains the center of that game world rather than one of the variables in some equation, even if he really is one.
But what about LLM-driven NPCs?
Fine, the reader will say, that all sounds nice when it comes to FSMs and Behavior Trees, but it's 2026, and every conference is full of demos where NPCs talk to the player out loud, remember the previous conversation and seemingly "decide" things on their own. That's true, and I too was impressed by Inworld AI with Ubisoft and their NEO NPC project, where you have a knowledge base and a character's speech style, and then LLM magic turns it all into a voice track and facial animation in real time. It looks impressive: you just sit there and talk to an NPC like a living person who remembers something from your last conversation, reacts unusually to your intonation and now and then slips in an unexpected line; all in all, the marketing wow-effect is real. Hmm... but I also remember being amazed by Fallout 2 and its dialogue system, when on my third and even fourth playthrough I kept getting different lines and different reactions.
So this whole generative layer is tied to dialogue with a human, to voice-over and reactions to a human, or really to text, which is the same class of problems chatbots cover. There's no strictly defined correct answer, but there's a huge space of acceptable options, and the model handles that beautifully, because the cost of a mistake is low and the range of what's acceptable is wide.
But the decision-making core (should the NPC attack right now, look for cover, call for backup or give up the chase) is still sitting on massive FSMs, and Ubisoft mentions this in very fine print at the very end of the presentation, and even in the latest iterations of the prototype (the project is now called Teammates) it's still just a chat with an NPC. Three years of development and nearly two hundred developers have led us to yet another chatbot, not a new combat system... There's your answer to how ready this is to replace the good old switch over states.
All articles