A first-person shooter prototype with flying drone enemies: 3D AI movement, detection, and hitscan combat without NavMesh.
This project is a first-person shooter prototype built entirely in Blueprints with Unreal Engine 5, developed following this Udemy course. The game loop is straightforward — eliminate all drones in the level — but the enemy type introduces a technically distinct challenge: drones are flying enemies that move in three dimensions, which invalidates the NavMesh-based pathfinding used for every ground-based enemy in the other projects in this series.
You can watch the prototype in action here: YouTube
Flying Enemy AI: Movement Without NavMesh
Unreal’s Navigation Mesh (NavMesh) defines the walkable surface of a level — a 2D surface that ground-based agents traverse. It’s well-suited for humanoid enemies that walk, run, and navigate around obstacles on the ground. Flying enemies, however, don’t walk — they move freely in three dimensions, and a 2D surface can’t represent their movement space.
The standard approach for flying enemy AI is to bypass NavMesh entirely and drive movement directly. The drone’s movement toward a target is computed each tick as the vector from the drone’s current position to the target’s position, normalized and scaled by the drone’s speed. This produces direct-line pursuit — the drone always moves straight toward the player, which is simple but produces the characteristic behavior of flying enemies that path through walls if obstacles exist.
For an open environment with no interior corridors, direct-line movement is sufficient and correct. For a level with obstacles the drone should navigate around, a 3D pathfinding solution is required — either Unreal’s experimental 3D NavMesh (NavMesh with flight agent configuration), or a custom A* implementation in the volume space around the level. For a beginner-scope prototype, direct-line movement in an open environment is the pragmatic choice.
Patrol and Detection
When not pursuing the player, drones patrol — moving between predefined waypoints positioned throughout the level at flight altitude. The patrol behavior cycles through a list of waypoint actors, moving to each in sequence and advancing to the next when within arrival distance.
Detection uses a sphere overlap centered on the drone, checked periodically rather than every tick. When the player enters the detection sphere, the drone transitions from patrol to pursuit. A line-of-sight check — a line trace from the drone to the player that verifies nothing blocks the path — prevents the drone from detecting the player through walls even when the player is within the detection sphere’s radius.
This two-stage detection model (proximity + line of sight) is the minimum viable implementation for enemy detection that doesn’t feel cheap. Proximity-only detection — the player gets detected just by being nearby regardless of cover — removes any stealth or positioning strategy. Adding line of sight preserves the possibility of approaching undetected, which makes the encounter design more interesting even in a simple prototype.
First-Person Shooting: Hitscan from Camera
The player weapon fires via hitscan — a line trace from the camera through the crosshair to whatever the player is aiming at. The trace hits the drone’s collision volume and triggers a damage event that decrements the drone’s health. When health reaches zero, the drone plays a death effect (an explosion particle and sound) and is destroyed.
Shooting a moving flying target is inherently more demanding than shooting a stationary or ground-based enemy — the drone’s constant movement in 3D space means the player must lead the target slightly to compensate for reaction time. This increased difficulty is appropriate for an FPS where the drone’s flight pattern is the core challenge rather than environmental navigation.
The crosshair UI provides visual feedback for the hitscan direction — centered on screen, always pointing where the trace will fire. Hit confirmation feedback (a brief screen flash, a hit sound, a damage number) communicates whether the shot connected without requiring the player to observe the drone’s health bar.
Drone Behavior During Pursuit
Once the drone is pursuing the player, its movement is not purely straight-line. A basic evasion behavior — oscillating the drone’s position around its direct path using a sine wave applied to the lateral axis — makes the drone harder to track with a hitscan weapon. The player must predict the drone’s oscillation to land consistent shots.
This lateral oscillation is a simple but effective difficulty modifier. A faster oscillation frequency or a larger amplitude makes the drone significantly harder to hit without requiring any change to the core pursuit logic. It’s tunable independently of the pursuit speed, which means difficulty can be adjusted on these two axes independently.
Drones that can also attack the player — firing projectiles on a cooldown while within range — add a reciprocal pressure that makes the encounter more dynamic. The player must balance offense (shooting the drone) against defense (avoiding the drone’s projectiles), which is the fundamental tension of a shoot-out with a mobile enemy.
Level Design for a Drone Encounter
The level is an open environment — a courtyard, a rooftop, an open industrial space — that gives drones room to fly and the player room to move. Enclosed spaces work poorly for flying enemy encounters because the drone’s 3D movement advantage disappears in a corridor where it can only move forward and backward.
Cover elements — pillars, crates, low walls — give the player positions from which to observe and shoot drones while being protected from their projectiles. The drones can fly over cover, so it provides partial protection rather than complete safety — the player must move between cover positions as drones reposition, creating a dynamic encounter rather than a static hide-and-shoot loop.
The win condition — eliminate all drones in the level — is tracked by a counter decremented on each drone’s death. The HUD displays the remaining count, giving the player a clear sense of progress. When the counter reaches zero, a game over / level complete screen appears.
Reflection
The drone killer prototype is most interesting for what it reveals about the limits of Unreal’s default AI infrastructure. NavMesh-based pathfinding is extremely well supported — it’s the path of least resistance for ground-based enemies. Flying enemies step outside that infrastructure and require the developer to think about movement and pathfinding differently. That shift in thinking — recognizing when the engine’s default tools apply and when they don’t — is one of the more valuable lessons a beginner project can provide.
The direct-line flight movement implemented here is the simplest possible solution. A production flying enemy in a complex environment would use a volumetric pathfinding approach — either Unreal’s flight navigation or a custom solution — to navigate around obstacles correctly. Understanding the gap between the prototype implementation and a production one is as useful as understanding the prototype itself.
Nicolás Bertoa 
Leave a comment