Introduction to the Particle System

What Is a Particle System and Why Use It?

In 2D game development, visual feedback is essential for delivering punchy, dynamic gameplay. Effects such as sparks flying from a sword clash, smoke plumes rising from a torch, dust kicked up after a landing, or bursts when defeating an enemy greatly enhance the player experience. In previous modules, we created interactive game objects like the player (obj_player), patrolling enemies (obj_enemy), and collectible coins (obj_coin). A common temptation for beginners is to instantiate dozens of standard objects with animated sprites whenever an explosion occurs. However, this approach is extremely inefficient.

Every object instance in GameMaker carries significant technical overhead: it stores dozens of built-in internal variables (x, y, hspeed, vspeed, mask_index, depth, solid, etc.), processes its own events (Create, Step, Draw), and participates in the engine's collision tree. If an explosion spawns 150 shrapnel pieces at once and several explosions occur in quick succession, your frame rate (FPS) will quickly plummet. Particles solve this problem: they are lightweight graphic entities without complex individual event lifecycles, mathematically optimized at a low level to render in bulk through a single unified draw pass.

Particle System Architecture in GameMaker

GameMaker's particle subsystem operates under a hierarchical model composed of three core elements: the Particle System, the Particle Type, and the Particle Emitter. Understanding how these three pieces interact is essential for writing clean, modular code free from performance bottlenecks.

The Particle System serves as the global manager or rendering canvas. It determines which layer or visual depth particles appear on, updates the position of all active particles each game step, and manages the internal memory allocated to them. The Particle Type acts as a blueprint or template defining how an individual particle looks and behaves: its base shape or sprite, start and end sizes, color transitions, speed, movement angle, acceleration, and lifespan in frames. Finally, the Particle Emitter is an optional utility used to designate a specific geometric area in the room (a rectangle, ellipse, diamond, or line) to spawn particles continuously or in periodic bursts.

Lifecycle and Dynamic Memory Management

Unlike standard numeric variables or sprites automatically managed by GameMaker's garbage collector, particle systems, types, and emitters reside in dynamic system memory (pointers or data structure indices). If you create a particle system inside an object's Create event and the room restarts without freeing those resources, that allocated memory remains locked in RAM. This critical bug is known as a memory leak and will eventually cause the game to crash. Therefore, every particle resource created in code must be explicitly destroyed when its managing object ends its lifecycle.

Step-by-Step: Creating an Impact Spark Effect

For our retro 2D platformer project, we will build a centralized visual effects manager object named obj_fx_manager. This object will initialize the particle systems and types used across the game—such as when the player collects coins, hits walls, or strikes enemies. We will begin by implementing a classic glowing spark effect that radiates outward and fades away smoothly.

Open your project, create a new object in the Asset Browser named obj_fx_manager, and add a Create event. In this event, define the system and the spark type's properties:

// --- OBJ_FX_MANAGER: CREATE EVENT ---
// 1. Create global particle system
sys_efectos = part_system_create();

// Assign visual depth so it renders in front of tiles and characters
part_system_depth(sys_efectos, -100);

// 2. Create and define particle type for sparks
part_chispa = part_type_create();

// Built-in engine shape (use pt_shape_spark for a bright retro look)
part_type_shape(part_chispa, pt_shape_spark);

// Size: initial scale between 0.1 and 0.2, decreasing by -0.005 each frame
part_type_size(part_chispa, 0.1, 0.2, -0.005, 0);

// Color: transition from bright yellow to orange-red
part_type_color2(part_chispa, c_yellow, c_red);

// Transparency (Alpha): starts fully opaque (1.0) and fades to transparent (0.0)
part_type_alpha2(part_chispa, 1.0, 0.0);

// Speed: between 2 and 5 pixels per frame, with slight deceleration (-0.1)
part_type_speed(part_chispa, 2.0, 5.0, -0.1, 0);

// Direction: omnidirectional 360-degree spread without forced rotation
part_type_direction(part_chispa, 0, 360, 0, 0);

// Subtle gravity: 0.15 pixels per frame pointing downward (270 degrees)
part_type_gravity(part_chispa, 0.15, 270);

// Lifespan: particle exists between 15 and 30 frames
part_type_life(part_chispa, 15, 30);

// Additive blending to simulate incandescent glow
part_type_blend(part_chispa, true);

💡 GameMaker includes several built-in shapes accessible via constants: pt_shape_pixel, pt_shape_disk, pt_shape_square, pt_shape_line, pt_shape_star, pt_shape_circle, pt_shape_ring, pt_shape_sphere, pt_shape_flare, pt_shape_spark, pt_shape_explosion, pt_shape_cloud, pt_shape_smoke, and pt_shape_snow. These constants let you prototype quickly without importing custom sprite assets.

Now that the particle type is configured, we need a way to spawn it at the exact moment and location an in-game action occurs. For one-shot effects, an emitter is not necessary; the part_particles_create() function allows you to spawn a set number of particles at a precise (x, y) coordinate immediately.

For instance, inside obj_player's collision event with obj_coin, or within obj_coin's Destroy event when collected, we can call the manager's particle system to trigger a burst of golden sparks:

// --- OBJ_COIN: DESTROY EVENT (or collision event with obj_player) ---
// Check that the particle manager exists before emitting
if (instance_exists(obj_fx_manager)) {
    // Spawn 12 sparks centered exactly on the collected coin
    part_particles_create(obj_fx_manager.sys_efectos, x, y, obj_fx_manager.part_chispa, 12);
}

To prevent memory leaks, you must implement the Clean Up event in obj_fx_manager. Unlike the Destroy event (which only fires when an instance is explicitly removed via instance_destroy()), the Clean Up event always runs: when leaving a room, transitioning levels, restarting the game, or closing the window.

// --- OBJ_FX_MANAGER: CLEAN UP EVENT ---
// Destroy associated particle types first
if (part_type_exists(part_chispa)) {
    part_type_destroy(part_chispa);
}

// Destroy the main system last
if (part_system_exists(sys_efectos)) {
    part_system_destroy(sys_efectos);
}