Dust Effects on Jumping and Running

Dust Effects on Jumping and Running: Adding Weight and Visual Feedback

One of the key elements separating a stiff prototype from a game that feels great in your hands is game feel—the visual, auditory, and tactile feedback of player actions. When a character runs across dirt or stone ground, the lack of any visible physical reaction makes them look like they are floating or sliding across the terrain. Dust is the classic visual tool in 2D platformers to ground the character in the environment, communicating weight, acceleration, and momentum.

In the previous lesson, you explored the fundamentals of particle systems in GameMaker: emitters, particle types, and system lifecycle management to prevent memory leaks. In this lesson, we will put that theory into practice by linking particle generation directly to our player character's state machine and movement variables (`obj_player`), built during our collision and movement modules.

When Should Dust Appear? Three Key Moments

To ensure dust feels natural and provides clear gameplay information rather than cluttering the screen with visual noise, it must respond to specific mechanical triggers within the game loop. There are three critical moments where dust serves an essential expressive purpose:

1. **Continuous Running (Footsteps):** Small flecks of dust or subtle puffs kicked up periodically from the character's heels while moving along the ground at speed. 2. **Jump Takeoff:** A concentrated downward and outward burst spawned at the base of the character on the exact frame they leave the ground via a jump input. 3. **Landing Impact:** A horizontal splash dispersing outward to both sides (left and right) the moment the character stops falling and hits a solid surface again, conveying the absorption of downward momentum.

Recommended Architecture: The Global Effects Manager

In GameMaker projects, it is tempting to instantiate particle systems inside the `Create` event of the player character (`obj_player`). However, in a structured, scalable project, this introduces unwanted coupling: if the player dies and the instance is destroyed, active particles in the air could abruptly vanish, or recreating the system on each respawn could cause memory leaks.

The best practice is to delegate the creation and maintenance of particle systems to a persistent controller object—such as `obj_fx_manager`—or centralize them via safe global references. In this module, we will use a persistent manager object that initializes all particle types during room startup and keeps them ready for any game entity to emit when needed.

Create a new object in your project and name it `obj_fx_manager`. In its object properties, check the **Persistent** box to ensure it persists across room transitions without reinitializing.

// ====================================================================
// OBJECT: obj_fx_manager
// EVENT: Create
// PURPOSE: Initialize the global particle system and configure
//          dust particle types for the player.
// ====================================================================

// 1. Create the global particle system on a deep visual layer
global.part_sys = part_system_create();
part_system_depth(global.part_sys, -100); // Drawn in front of the background but behind the HUD

// 2. Define dust particle for RUNNING
global.pt_dust_run = part_type_create();
part_type_shape(global.pt_dust_run, pt_shape_smoke);
part_type_size(global.pt_dust_run, 0.08, 0.15, -0.005, 0); // Starts small and shrinks
part_type_scale(global.pt_dust_run, 1, 1);
part_type_color1(global.pt_dust_run, c_silver);
part_type_alpha3(global.pt_dust_run, 0.6, 0.4, 0.0);       // Starts semi-opaque and fades out
part_type_speed(global.pt_dust_run, 0.2, 0.6, -0.01, 0);   // Gentle drift speed
part_type_direction(global.pt_dust_run, 70, 110, 0, 0);    // Drifts slightly upward
part_type_gravity(global.pt_dust_run, 0.01, 270);          // Very gentle falling resistance
part_type_life(global.pt_dust_run, 15, 25);                // Short lifetime (15 to 25 steps)

// 3. Define dust particle for JUMPING
global.pt_dust_jump = part_type_create();
part_type_shape(global.pt_dust_jump, pt_shape_smoke);
part_type_size(global.pt_dust_jump, 0.15, 0.25, -0.01, 0);
part_type_scale(global.pt_dust_jump, 1, 1);
part_type_color2(global.pt_dust_jump, c_white, c_gray);
part_type_alpha3(global.pt_dust_jump, 0.8, 0.5, 0.0);
part_type_speed(global.pt_dust_jump, 1.0, 2.0, -0.05, 0);
part_type_direction(global.pt_dust_jump, 20, 160, 0, 10);  // Spreads outward to the sides
part_type_life(global.pt_dust_jump, 20, 30);

// 4. Define dust particle for LANDING
global.pt_dust_land = part_type_create();
part_type_shape(global.pt_dust_land, pt_shape_smoke);
part_type_size(global.pt_dust_land, 0.2, 0.35, -0.012, 0);
part_type_scale(global.pt_dust_land, 1, 0.6);              // Flattened horizontally
part_type_color2(global.pt_dust_land, c_white, c_ltgray);
part_type_alpha3(global.pt_dust_land, 0.9, 0.4, 0.0);
part_type_speed(global.pt_dust_land, 1.5, 3.2, -0.08, 0);  // High-speed outward burst
part_type_life(global.pt_dust_land, 20, 35);

Let's break down the technical choices in this setup. The function `part_type_alpha3` is an essential GameMaker tool: it defines three stages of particle opacity (birth, mid-life, and death). By passing `0.6` at spawn, `0.4` at mid-life, and `0.0` at expiration, we guarantee dust never pops out of existence abruptly with an awkward flicker, dissolving smoothly into the air instead.

Likewise, the negative factor in the third argument of `part_type_size` (the *size increase* parameter) controls size changes per frame. A value like `-0.005` causes the particle to shrink organically until it fades completely away.

Mandatory Memory Cleanup (Clean Up Event)

As emphasized in our introduction to particle systems, low-level data structures allocated by the graphics engine are not managed by GML's automated garbage collector. You must explicitly free each particle type and the particle system itself when the manager object is destroyed or the game shuts down.

// ====================================================================
// OBJECT: obj_fx_manager
// EVENT: Clean Up
// PURPOSE: Destroy particle resources to prevent memory leaks.
// ====================================================================

// Destroy individual particle types
if (variable_global_exists("pt_dust_run")) {
    part_type_destroy(global.pt_dust_run);
}
if (variable_global_exists("pt_dust_jump")) {
    part_type_destroy(global.pt_dust_jump);
}
if (variable_global_exists("pt_dust_land")) {
    part_type_destroy(global.pt_dust_land);
}

// Destroy the parent particle system
if (variable_global_exists("part_sys")) {
    part_system_destroy(global.part_sys);
}

💡 Remember that the Clean Up event executes automatically whether an instance is destroyed via instance_destroy(), a room transition occurs, or the game exits via game_end(). It is GameMaker's safest and most standard location for manual resource cleanup.

Player Setup: State Tracking and Timing Variables

Now that the dust particle definitions are loaded in memory and ready to spawn at any coordinate in the game, open the player object, `obj_player`. To synchronize particle emission with character movement, add two tracking variables to its `Create` event:

// ====================================================================
// OBJECT: obj_player
// EVENT: Create (Supplemental snippet for particle management)
// ====================================================================

// Movement variables inherited from earlier modules:
// hsp = 0;
// vsp = 0;
// grounded = false;

// Control variables for particle effects:
was_grounded = false;     // Stores grounded status from the previous frame
dust_timer = 0;           // Timer to space out run particles
dust_interval = 8;        // Frames between each running dust puff

The `was_grounded` variable is critical: it lets us compare whether the player was airborne on the previous frame and made contact with the floor on the current frame. The `dust_timer` variable prevents a common beginner mistake: spawning run particles on every single frame (which would emit 60 particles per second), producing an overly dense, unreadable cloud.