If you've ever tried to make an NPC chase a player, you know that a basic roblox enemy ai script state machine is pretty much the only way to keep your code from turning into a messy pile of unreadable spaghetti. We've all been there—starting with a simple "move to player" script and then realizing we need the enemy to patrol, hide, attack, and maybe even run away when its health is low. Before you know it, you have fifty nested if statements and a headache.
State machines aren't nearly as scary as the name sounds. At its heart, a state machine is just a fancy way of saying your AI can only do one thing at a time. It's either idling, patrolling, chasing, or attacking. By forcing the AI into these specific buckets, you make your life ten times easier when it comes to debugging.
Why You Should Stop Using Spaghetti Logic
When you're first starting out in Roblox Studio, it's tempting to just throw everything into a while true do loop. You check the distance to the player, check the health, check if the enemy is touching a wall, and then try to fire off a bunch of functions. The problem is that these actions often conflict. Your enemy might try to "Patrol" and "Chase" in the same frame, leading to that weird jittery movement where the NPC looks like it's having a breakdown.
A state machine fixes this by creating a clear hierarchy. It says, "If I am in the CHASING state, I don't care about the patrol points right now." This separation of concerns is what makes professional games feel polished. It's the difference between a zombie that gets stuck on a pebble and an enemy that feels like it actually has a brain.
Setting Up the State Logic
To get a roblox enemy ai script state machine running, you usually want to use a ModuleScript. Why? Because if you decide to have fifty different types of enemies, you don't want to copy-paste the same logic into fifty different scripts. You want one "brain" module that all your NPCs can reference.
Inside your script, you'll want to define your states. Most people use a simple table or an "enum-style" setup. For example:
lua local States = { Idle = "Idle", Patrol = "Patrol", Chase = "Chase", Attack = "Attack", Dead = "Dead" }
By using these strings (or numbers, if you want to be slightly more efficient), you can easily track what the NPC is doing. The core of your script will then revolve around a "SwitchState" function. This function is the gatekeeper; it handles the exit logic for the old state and the setup logic for the new one.
The Heartbeat of the AI
The biggest debate usually comes down to how often the AI should "think." You could use a while task.wait(0.1) do loop, which is usually plenty for a standard enemy. You don't need the AI to recalculate its entire existence 60 times a second—that's just a waste of server resources.
Inside this loop, you check for "transitions." Transitions are the "if" statements that move the NPC from one state to another. For instance: * If the state is Idle and a player is within 50 studs, switch to Chase. * If the state is Chase and the player is within 5 studs, switch to Attack. * If the state is Chase and the player disappears or gets too far away, switch back to Patrol.
By keeping these checks inside a structured loop, you ensure that the AI is always responsive without being a lag machine.
Handling the Idle and Patrol States
The Idle state is usually your default. The NPC might play a subtle animation, like looking around or shifting its weight. It's the "waiting room" of your AI logic.
Patrol is where things get a bit more interesting. Usually, you'll have a folder in your workspace filled with Parts that act as waypoints. Your state machine will pick the next waypoint, use PathfindingService to get there, and then move to the next one. The trick here is to make sure the AI doesn't get stuck. Always include a timeout or a distance check so that if the NPC can't reach a point, it just gives up and tries the next one.
Perfecting the Chase State
This is where most developers run into trouble. A simple Humanoid:MoveTo() is fine if the world is a flat baseplate, but as soon as you add walls, stairs, or jumps, your AI is going to struggle.
When your roblox enemy ai script state machine enters the Chase state, you need to decide how often to update the path. If you recalculate the path to the player every single frame, your game will lag. If you do it too slowly, the player will easily outmaneuver the AI. A good middle ground is recalculating every 0.2 to 0.5 seconds, or only when the player has moved a significant distance from their last recorded position.
Don't forget to use Raycasting here! If the AI has a direct line of sight to the player, you don't even need pathfinding. Just move directly toward them. This saves a lot of processing power and makes the AI look a lot more aggressive and "smart."
Transitions and "Cleanup"
One of the most overlooked parts of building an AI state machine is the "cleanup" phase. When an NPC switches from Attacking to Chasing, you might need to stop an animation, reset a cooldown, or disconnect a touched event.
If you don't clean up your states, you'll end up with "ghost" behaviors. You've probably seen this in games where an enemy keeps playing a sword-swinging animation while it's walking toward you. That happens because the developer didn't tell the "Attack" state to stop its animations when it transitioned back to "Chase."
A simple way to handle this is to have an OnEnter and OnExit logic block for every state. When the state changes, the script automatically runs the exit code for the old state and the entry code for the new one.
Adding Some Personality
Once the basic roblox enemy ai script state machine is working, you can start adding the fun stuff. Maybe when the AI is in the Idle state, it has a 10% chance to play a whistling sound. Or maybe when it's in the Chase state, it shouts a random voice line from a folder in SoundService.
You can also add "sub-states." For example, the Attack state could have different modes depending on the NPC's health. If it's high health, it stays in a "Melee" sub-state. If it's low, it switches to "Ranged" and tries to keep its distance. Because you built it as a state machine, adding these extra layers is just a matter of adding a few more if checks in a specific section, rather than rewriting the whole thing.
Performance Considerations for Big Games
If you're making a game with 100 NPCs, you have to be careful. Running a full state machine on the server for every single zombie can get heavy. One common trick is to only run the AI logic for NPCs that are near a player. If an NPC is 500 studs away in a closed room, do you really need it to be patrolling and raycasting? Probably not. You can put it into a "Sleep" state where it does nothing until a player gets closer.
Also, try to keep your PathfindingService calls in check. Pathfinding is expensive. If you have a horde of 20 enemies chasing one player, they don't all need to calculate their own path. You could have one "leader" calculate the path and the others follow slightly offset positions, or just have them do simple magnitude checks until they actually get stuck.
Final Thoughts on State Machines
Building a roblox enemy ai script state machine might feel like extra work upfront compared to just writing a quick script, but it pays off so much in the long run. It makes your code organized, it makes your enemies feel more alive, and most importantly, it stops you from pulling your hair out when you want to add a new feature three months from now.
Start simple. Get a cube to switch between red (Idle) and green (Patrol). Once you have that logic down, swapping the colors for actual animations and pathfinding is the easy part. Just remember to keep your states distinct, clean up after yourself, and don't over-complicate the logic until the foundation is solid. Happy coding!