Designing and Programming a Basic Patrol Enemy

Introduction to Autonomous Behavior in 2D Games

Up to this point in the course, gameplay in our platformer project has been driven primarily by player input: the player presses a key or pushes a stick, and the character responds on screen. However, for a game world to feel alive, challenging, and dynamic, it is essential to introduce entities whose movements follow internal logical rules independent of player controls. This set of predefined behaviors is what we call basic Artificial Intelligence (AI) or behavior scripting in game development.

The fundamental AI archetype in 2D platformers is the patrol enemy. From the iconic Goombas in Super Mario Bros. to the Metools in Mega Man or wandering sentries in Hollow Knight, the constant horizontal pacing from left to right—rebounding off walls or turning at ledges—is a timeless design convention. In this lesson, we will build a patrol enemy from scratch that traverses the level autonomously, interacts with existing terrain (`obj_wall`), and reverses direction upon encountering a solid obstacle.

Asset Preparation: Sprite and Collision Mask

Before writing a single line of code, we must prepare the graphical asset for our enemy and properly configure its collision geometry in GameMaker. Precise physical collisions and visual rendering depend directly on how the sprite origin and mask are defined.

Start by creating a new Sprite asset in the Asset Browser (right-click the Sprites folder -> Create -> Sprite) and name it canonically `spr_enemy_patrol`. To maintain visual consistency with our retro character, use a resolution of 16x16 or 32x32 pixels. If you do not yet have a finished walk cycle, draw a simple stylized block or creature with a distinct color (such as red or purple) featuring two visible eyes pointing clearly to the right.

💡 Golden rule of orientation: By universal convention in 2D game development, all side-scrolling sprites with horizontal facing should be drawn facing RIGHT by default. This simplifies mathematical calculations, as the positive horizontal axis (+X) directly corresponds to a positive image scale.

There are two critical settings to configure inside the `spr_enemy_patrol` sprite editor:

Once the sprite is created and configured, create the corresponding object. Right-click the Objects folder, select Create -> Object, name it `obj_enemy_patrol`, and assign the `spr_enemy_patrol` sprite. There is no need to check GameMaker's built-in 'Solid' box; we will manage all physical interactions through explicit GML Code to guarantee precise control free of engine quirks.

Variable Structure in the Create Event

The enemy must track its kinematic state in memory: its walking speed, the direction it is currently moving, its vertical velocity, and the gravitational force keeping it grounded. All of these variables must be initialized in the **Create** event of `obj_enemy_patrol`.

Open `obj_enemy_patrol`, add the **Create** event, and enter the following GML code block:

/// @description Patrol enemy initialization

// Horizontal movement parameters
move_speed = 1.5;         // Movement speed in pixels per frame
move_dir = 1;             // Direction: 1 = Right, -1 = Left
hsp = 0;                  // Calculated horizontal speed (custom hspeed)

// Vertical movement and gravity parameters
vsp = 0;                  // Current vertical speed
grav = 0.3;               // Downward gravitational acceleration
vsp_max = 8;              // Terminal fall speed limit

// Initial visual facing
image_xscale = move_dir;

Let us examine the logic behind these variables. Instead of using GameMaker's built-in `hspeed` and `vspeed`—which automatically translate the instance internally before we can perform precise collision checks—we declare custom variables `hsp` and `vsp`. This technique, introduced when programming the player character in previous modules, lets us calculate exactly where the entity wants to go and verify that the space is clear before modifying the actual `x` and `y` coordinates.

The `move_dir` variable acts as a 1D unit vector. It will only take two values in this implementation: `1` (moving right) or `-1` (moving left). Multiplying `move_dir` by `move_speed` directly yields the exact velocity and direction without requiring cumbersome nested conditional statements.

Movement and Collision Logic in the Step Event

The **Step** event runs once every frame (typically 60 times per second). Here we process basic physics, evaluate collisions against solid geometry (`obj_wall`), and reverse the movement direction whenever the enemy collides head-on with an obstacle.

Add the **Step -> Step** event to `obj_enemy_patrol` and insert the following code structured into distinct phases: applying forces, collision resolution, and coordinate updates.

/// @description Patrol logic and physics collisions

// =========================================================================
// 1. APPLY GRAVITY
// =========================================================================
if (vsp < vsp_max) {
    vsp += grav;
}

// =========================================================================
// 2. HORIZONTAL SPEED CALCULATION
// =========================================================================
hsp = move_dir * move_speed;

// =========================================================================
// 3. HORIZONTAL COLLISION DETECTION & RESOLUTION (WALLS)
// =========================================================================
// Check if there is a solid object at the target position
if (place_meeting(x + hsp, y, obj_wall)) {
    // Move pixel by pixel until flush against the obstacle
    while (!place_meeting(x + sign(hsp), y, obj_wall)) {
        x += sign(hsp);
    }
    
    // Halt movement for this frame
    hsp = 0;
    
    // Reverse direction for subsequent frames
    move_dir = -move_dir;
}

// Apply horizontal displacement to X axis
x += hsp;

// =========================================================================
// 4. VERTICAL COLLISION DETECTION & RESOLUTION (FLOORS AND CEILINGS)
// =========================================================================
if (place_meeting(x, y + vsp, obj_wall)) {
    // Move pixel by pixel vertically toward the surface
    while (!place_meeting(x, y + sign(vsp), obj_wall)) {
        y += sign(vsp);
    }
    
    // Reset vertical speed upon landing or hitting ceiling
    vsp = 0;
}

// Apply vertical displacement to Y axis
y += vsp;

// =========================================================================
// 5. VISUAL FACING (SPRITE FLIPPING)
// =========================================================================
if (move_dir != 0) {
    image_xscale = move_dir;
}

Mathematical Breakdown of Direction Inversion

Pay close attention to the line `move_dir = -move_dir;`. This concise mathematical operation eliminates the need for branching `if/else` checks. If `move_dir` is `1`, `-1 * 1` evaluates to `-1`. On the next flip, `-(-1)` evaluates to `1`. In a single line, we toggle the heading indefinitely whenever a wall is hit.

The `sign(hsp)` function returns `1` for positive values, `-1` for negative values, and `0` for zero. Paired with the `while (!place_meeting(x + sign(hsp), y, obj_wall))` loop, it guarantees a pixel-perfect contact point. The enemy will never float 0.5 pixels away from a wall or embed itself inside solid geometry before turning around, preventing visual jitter and clipping.

The place_meeting Function vs. Alternatives

GameMaker provides three core functions for checking object overlap: `place_meeting`, `position_meeting`, and `instance_place`. Understanding their differences is crucial for robust AI design:

Fall Prevention: Ledge Detection

With the code implemented so far, the enemy will reliably patrol from wall to wall. However, if we place it on an elevated, free-floating platform with no enclosing walls, it will walk straight off the edge and fall under gravity until reaching the bottom of the room.

In level design, we frequently want certain patrol enemies to remain confined to their assigned platform, guarding a ledge without dropping off. To achieve this, we equip our enemy with a forward ground probe.

The logic works by projecting a virtual check slightly ahead of the enemy and a couple of pixels below its feet. If that projected point lacks solid ground (`!position_meeting` or `!place_meeting`), the enemy knows an edge is ahead and can immediately halt and reverse direction, just as if it had struck a wall.

This check must run before `x += hsp` is applied, allowing the enemy to respond to the ledge before taking the step that would send it falling into the abyss.