There is a temptation in game AI development to start from the algorithm. You pick a behavior architecture, you write the decision tree or the policy gradient, and then you ask whether players find the result enjoyable. We tried that approach early on and it produced opponents that were technically impressive and deeply unsatisfying to fight. The algorithm was doing exactly what it was designed to do. The problem was that nobody had asked what the player was supposed to feel.
At M10, the design philosophy we settled on is the reverse. We start with the feeling we want the player to have at a specific point in a match, and then we work backward to figure out what the AI system needs to do to produce that feeling. It sounds straightforward written out like that, but in practice it changes almost every technical decision you make.
What "Feeling" Means in a Competitive Context
In a single-player game, the feeling you are designing toward is often something like wonder or dread or satisfaction. In a competitive shooter, the target feelings are narrower and more specific. The player we are designing for wants to feel that their skill matters, that the opponent genuinely reacted to what they just did, and that when they lose a round they understand why. Those three things turn out to be in tension with each other.
Skill mattering requires that better play produces better outcomes reliably. Genuine reaction requires that the opponent tracks your actual behavior, not a preset pattern. Legibility requires that the opponent's logic is readable enough that you can form a theory of what it will do next. A pure skill-reading AI that adapts aggressively to everything you do can become illegible. An AI tuned entirely for legibility becomes predictable and stops feeling like it reacts to you at all. Getting all three at once is the design problem we have been working on for two years.
The Difference Between Punishing and Responsive
One of the earliest things we learned from playtesting is that players distinguish very sharply between an opponent that punishes them and an opponent that responds to them, even when the mechanical outcome is identical. Both behaviors might result in the player getting eliminated from a flank. But one of them feels like the opponent noticed them and adapted. The other feels like the opponent is a wall with good aim.
The distinction comes down to timing and specificity. A punishing AI fires the instant a player makes a mistake, with no observable wind-up or decision overhead. A responsive AI shows a brief window of detection and adjustment before it acts, and the action it takes is specifically countered to what the player just did rather than being a generic threat. Playtesters described the second version as feeling more alive, even in sessions where their kill-death ratio was worse against it. That was a signal worth paying attention to.
We are not saying that responsiveness is always better than raw punishment. At the top of the skill distribution, the most competitive players often want opponents that fire with minimal hesitation. The responsive-feeling behavior that feels fair to a mid-range player reads as sluggish to someone with very low reaction thresholds. We have to tune differently across skill brackets, and that starts from knowing what each bracket is actually trying to feel during a match.
How This Changes the Technical Architecture
Starting from the player experience instead of the algorithm has concrete effects on how we build the system. The clearest example is what we call the readable tell. Every opponent in our AI has a brief observable reaction phase before it executes a counter-move. The duration of that phase and the visibility of the tell are not fixed values. They are parameters we tune per skill bracket based on what reaction window feels fair versus frustrating to players at that level.
That design requirement comes directly from the player-experience question, not from any AI architecture decision. If we had started by building a behavior tree and then asked whether it felt fair, we would probably have tuned the firing speed and accuracy parameters. We would never have landed on the concept of a deliberately observable tell, because that concept does not exist in behavior tree vocabulary.
Similarly, the way our AI selects counter-strategies comes from the question: what does a player expect to work as a counter to their current playstyle? We want the opponent to be a challenge, but we also want the player to have a genuine theory of how to beat it. That means the opponent's behavior has to be learnable. Learnable behavior requires that the opponent's responses be consistent enough that a player can form a mental model of them within a few rounds. Pure online learning, where the opponent changes its approach every few seconds, breaks that learnability contract. We cap how quickly the AI adapts its counter-strategy specifically to preserve the player's ability to form a working theory of the opponent.
Where This Philosophy Has Limits
There are situations where designing from the player feeling first runs into problems. The clearest one is the boundary between "feels like the opponent learned me" and "feels like the opponent is cheating." Those two experiences can be produced by the exact same AI behavior depending on how the player is performing that day. A player who is on form will experience a sharp opponent as validating. A player who is off form will experience the same opponent as unfair.
We have not fully solved this. Our current approach is to use the live skill-reading signal from the matchmaking system to modulate the adaptation rate of the AI during a session. If the system detects that the player is performing significantly below their baseline over a stretch of rounds, the AI's adaptation speed steps back slightly. The player experiences this as the opponent becoming slightly more predictable, which gives them a recovery window. It is a design intervention that would be invisible on paper and would read as weird if you described it technically. But playtesters in the sessions where we enabled it consistently rated their experience as more fair, without being able to articulate why.
This is the kind of design decision that only surfaces if you are asking the right question from the start. The question is not: what should the AI do when the player is underperforming? The question is: what should the player feel when they are underperforming? Those questions have different answers, and the second one is the one worth building toward.
What We Are Still Figuring Out
The player-first framing has been the right way to build this. I am confident in that. But it creates a persistent challenge: you have to keep doing the fieldwork. The feelings players want from a competitive shooter are not static. They shift as the meta shifts, as player skill distributions change, and as players themselves grow more experienced with the system. An AI that felt like a meaningful challenge in our early playtests started feeling predictable to the same players twelve weeks later, not because we changed anything, but because they had adapted to it.
We are building player experience measurement into our ongoing process rather than treating it as a one-time calibration. What that looks like in practice is a regular cadence of small observation sessions, paired with behavioral telemetry from matches. The telemetry tells us what happened. The observation sessions tell us what the player thought was happening. Both matter, and they regularly disagree with each other. Resolving those disagreements is most of the design work.