A CS student with no game-dev experience asked r/gameai whether it’s realistic to specialise in game AI — NPC behaviour, planning, emergent gameplay, RL, multi-agent systems — without learning to build games. The answers from working devs were consistent, and not what the question assumed.
The problem isn’t that the specialisation is uncommon. It’s that game AI isn’t a separable module:
- It’s a thin layer of logic that touches nearly every other system in the game.
- Gameplay systems have to be built with AI hooks in mind — hooks the AI will use, and often abuse.
- You need the engine fundamentals: update loops, frames versus physics ticks, how animations integrate with behaviours, whether agents are physics-driven.
- Selecting a decision-making architecture (utility AI, behaviour trees, planners) is the easy part — the same behaviour can be produced by almost any of them.
- The actual work is the interaction layer: how does the NPC know the player is somewhere they shouldn’t be, or doing something they shouldn’t?
The career answer was blunt too. Large studios do employ NPC and enemy AI specialists, but entry is portfolio-driven — solo prototypes, or finding people to collaborate with. One reply recommended starting with a couple of tutorials until a player character moves in a real engine, then building AI that reacts to that player in different ways. The questioner’s own resolution: build a minimal testbed of basic shapes plus player functionality, then drop different decision systems into it and compare.
The useful inversion here is the shape of the skill tree. The naive model is “learn AI, then apply it to games.” What practitioners describe is the opposite: AI has the widest dependency surface in the codebase, so engine competence is a prerequisite rather than a distraction. Notably, nobody in the thread reached for LLM agents — the replies are about world state, affordances, animation and physics, which is where the engineering actually lives.