NPCs feel predictable or broken.
They get stuck, ignore the player or repeat the same pattern.
Debug views that explain each decision
Game AI development for Unreal Engine
We build NPC behaviour that reads well in play with StateTree, Behavior Trees, EQS and Smart Objects, and add language models only where they help the game.
ST_Enemy_Grunt any state → Combat on sight (AI Perception: sight)
├─ Idle → Patrol after a short wait
├─ Patrol → Investigate on noise (AI Perception: hearing)
├─ Investigate → back to Patrol after 8 s
└─ Combat → Investigate when the target is lost
├─ Take cover EQS: cover points hidden from the target
├─ Suppress fire while the target is behind cover
└─ Flank EQS: positions outside the target's view coneWhy teams bring us in
AI logic is a pile of special cases.
Every new enemy type copies and edits the last one.
Reusable behaviours designers can combine
You want LLM characters but are unsure they can ship.
Latency, cost, content risk and platform rules all need answers.
A prototype with the risks measured
AI systems we build
StateTree and Behavior Trees
Readable decision logic for enemies and companions, and Mass with StateTree for crowds, with debug views designers can use.
Perception, EQS and Smart Objects
AI Perception, Environment Query System queries and Smart Objects for believable positioning and interaction.
Navigation
Navmesh setup, dynamic obstacles, navigation links and large worlds with World Partition.
LLM-driven dialogue
Characters that answer in natural language, grounded in lore and quest state, with content filters, cost limits and authored fallback lines.
Bots for testing
Automated players that explore levels and run scenarios overnight, feeding crash and performance reports.
Studio automation
Scripts and AI-assisted tools for repetitive production work, such as asset checks, localisation exports or bug triage.
In practice
How we build an NPC behaviour
We start from what the player should see: the enemy hears a noise, investigates, finds the player and takes cover. Each scenario becomes a small test level before any decision logic is written.
The logic is built with StateTree or Behavior Trees, with EQS for positions and Smart Objects for interactions. Designers get Gameplay Debugger and Visual Logger views that show why an NPC chose what it did, so tuning does not need a programmer.
For LLM features the prototype comes first. We measure latency, cost per session and how often the filters trigger, and you decide with real numbers whether the feature ships.
Who builds the AI
See the whole team.
Vish
AI & Automation EngineerBuilds the AI systems, the LLM prototypes and the test bots.
Jana
Game & UX DesignerWrites the behaviour scenarios with your designers and runs the playtests.
Jordan
QA & Test Automation EngineerTurns the bots into nightly test runs.
Game AI FAQ
Can LLM characters ship in a commercial game?
They can, with clear limits: filtered output, fallback lines, cost controls and a plan for platform and age-rating requirements. We prototype first so you can judge the risk.
Do you train models on our data?
Your code, assets and data are never used to train third-party or general-purpose models. Any model we train for your game, such as a bot policy, belongs to you.
StateTree or Behavior Trees?
Both are good tools. StateTree suits many newer projects, and existing Behavior Tree setups often do not need replacing. We recommend one per project and explain why.
Related services
Start a project
Tell us about the project
Send us the engine version, where the project is and the work you need done. We reply within two business days with who we would put on it, or tell you it is not a fit.
Prefer email?hello@moduleforge.studio