Configuring a Follow Camera in GameMaker

Introduction to 2D Game Camera Systems

Up to this point in the course, most of our testing has taken place in single-screen setups where the entire action fits within a single fixed display. However, in classic 2D platformers (such as Super Mario World, Sonic the Hedgehog, or Celeste), the game world is substantially larger than what the player can see at any given moment. To allow players to explore underground caverns, mountain peaks, or long obstacle courses, the engine must decide with pinpoint accuracy which portion of the world to project onto the screen at each tick.

The system responsible for this task is the virtual camera. Far from being a mere aesthetic detail, the camera is a critical narrative and gameplay tool: it dictates pacing, provides anticipation for upcoming hazards, prevents blind jumps, and conveys physical impact through screen shakes, acceleration, and dynamic framing. In GameMaker, rendering what the player sees relies on a three-tier architecture: the Room, the Camera, and the Viewport.

Core Concepts: Rooms, Cameras, and Viewports

To avoid common beginner confusion, it is essential to clarify the distinction between these three fundamental GameMaker concepts:

Think of the Room as a miniature diorama city built on a large table. The Camera is a film camera mounted on a tripod or dolly hovering over the table, framing an area of 480 by 270 millimeters. The Viewport is the television set in your living room displaying the feed sent by that film camera. If the camera pans to the right, the picture on the TV changes, even though the diorama itself never moves an inch.

Native Setup via the Room Editor

GameMaker provides a built-in, no-code mechanism to assign a follow camera directly from the Room Properties panel. While this approach has limitations in advanced commercial projects, it is the fastest way to understand how the underlying view subsystem operates.

To enable this system step by step in your platformer room:

1. In the Asset Browser, open your level room (for example, `rm_level_1`). 2. In the room properties panel on the left, expand the section titled **Viewports and Cameras**. 3. Check the **Enable Viewports** box. If this is unchecked, GameMaker will stretch or crop the entire room to fit the main window without using any cameras. 4. Expand the **Viewport 0** tab and check **Visible**. 5. Under **Camera Properties**, set the framing width and height. To preserve our retro aesthetic with crisp pixels and a 16:9 widescreen aspect ratio, set `Width: 480` and `Height: 270`. 6. Under **Viewport Properties**, set the display output size. You can use `Width: 1920` and `Height: 1080` (an exact 4x integer scale of the internal camera resolution). 7. Under **Object Following**, click the object selector and choose our playable character: `obj_player`. 8. Adjust the **Horizontal Border** and **Vertical Border** values. These represent the minimum distance (in pixels) the player can get to the edge of the frame before the camera starts moving. Set `Horizontal Border: 200` and `Vertical Border: 100`. 9. The **Horizontal Speed** and **Vertical Speed** fields determine the maximum speed at which the camera tracks the player. Setting these to `-1` forces the camera to lock onto the player instantly and rigidly.

💡 Important: Setting speed to -1 means every micro-movement and jump from the player is mirrored instantly on screen without dampening, which can cause visual fatigue and feel mechanically rigid. However, if you set a fixed tracking speed such as 4 or 6 pixels per frame, any movement faster than that (such as sprinting or falling) will cause the character to outrun the camera and leave the screen.

Because of these limitations in basic object following (lack of spring dampening, inability to lead the player's view, lack of programmatic screen shakes or dynamic zooming), professional 2D games generally bypass the Room Editor's built-in following in favor of a dedicated camera controller object written in GML Code.

The Camera Controller: obj_camera

To gain full control over the visual presentation, we will create a dedicated controller object called `obj_camera`. This object will be solely responsible for calculating optimal view coordinates, preventing the camera from revealing empty space outside the level, and applying smooth mathematical interpolation.

Create a new object in your Asset Browser and name it `obj_camera`. It does not require a sprite, as it acts purely as an invisible logic manager in the scene.

Initialization in the Create Event

In the **Create** event of `obj_camera`, we initialize the active virtual camera, declare our base resolution, and configure the viewport using GameMaker's camera functions. Add the following code to the Create event:

/// Create Event of obj_camera

// 1. Define base frame resolution (retro 16:9 aspect ratio)
ancho_camara = 480;
alto_camara  = 270;
escala_ventana = 3; // Window desktop scale (480*3 = 1440, 270*3 = 810)

// 2. Create the internal GameMaker camera
camara = camera_create_view(0, 0, ancho_camara, alto_camara, 0, -1, -1, -1, 0, 0);

// 3. Enable viewports and bind the camera to Viewport 0
view_enabled = true;
view_visible[0] = true;
view_set_camera(0, camara);

// 4. Configure OS window size and drawing buffer (Application Surface)
window_set_size(ancho_camara * escala_ventana, alto_camara * escala_ventana);
surface_resize(application_surface, ancho_camara * escala_ventana, alto_camara * escala_ventana);

// Center the desktop window after resizing
alarm[0] = 1;

// 5. Tracking and interpolation variables
objetivo = obj_jugador;
suavizado = 0.1; // Interpolation factor (between 0.01 and 1.0)

// Center camera on target initially if it exists
if (instance_exists(objetivo)) {
    x = objetivo.x - (ancho_camara / 2);
    y = objetivo.y - (alto_camara / 2);
} else {
    x = 0;
    y = 0;
}

// Apply initial position directly to camera
camera_set_view_pos(camara, x, y);

To ensure the game window centers properly on the player's desktop after calling `window_set_size()`, add the **Alarm 0** event to `obj_camera` with a single function call:

/// Alarm 0 Event of obj_camera
window_center();

The Critical Event Choice: Step vs. End Step

One of the most common pitfalls in GameMaker development is placing camera follow logic in the standard **Step** event. Updating the camera position in Step introduces a temporal race condition determined by the internal instance execution order.

If `obj_camera` runs its Step event before `obj_player` processes its input, speeds, and collisions in its own Step event, the camera will position itself based on the player's previous frame coordinates. When the player moves an instant later, the final render will draw the character offset by one frame relative to the background. This produces an unpleasant shuddering effect known as camera jitter, noticeably degrading visual fluidity.

For this reason, camera positioning must ALWAYS run in the **End Step** event. In this phase, GameMaker guarantees that all gameplay entities have already resolved their velocities, physics collisions, and position integrations, allowing the camera to track the final, authoritative position of the player before any **Draw** events fire.

Smooth Tracking with Linear Interpolation (lerp)

Cinematic and responsive camera tracking avoids clamping the character rigidly to the center of the screen, opting instead for elastic dampening. In game development mathematics, this is accomplished using the `lerp()` function (short for *Linear Interpolation*).

The function `lerp(a, b, t)` takes a starting point `a`, a target destination `b`, and a normalized percentage or blend factor `t` (where 0 represents 0% and 1 represents 100%). Each frame, the function calculates an intermediate position by traveling a percentage of the remaining distance. As the camera gets closer to the target, the absolute distance traveled shrinks, producing an organic ease-out deceleration.