How To Add A Delay In Firing Gamemaker

You've heard of elf on a shelf, now go set up for a particle commodity.

Particles are a great way to add style, colour, and flair to your second games. Whether y'all're looking to create an effect that's visually dazzling or soft and subtle, GameMaker's particle systems can assist you accomplish it.

What is a particle?

A particle is a graphic resource that has certain fixed backdrop which are defined past a particle system.

These properties cannot be manipulated directly for individual particles, but are changed through the code that is used to define the arrangement that a type of particle belongs to.

Particles tin can be used to create beautiful and flashy or subtle and discreet effects in a game without the CPU overhead that instances tin cause.

Fire Effect Particles
Burn issue fabricated with particles, courtesy of Martin Crownover

What is a particle system?

Think of a particle system as a container that holds our particles set up for use.

Nosotros use code to define a series of visual aspects for our particle, and and then we place it in the "container" so that we can take it out and use it whenever we need it.

How exercise I set upwards a particle system in GameMaker?

Before setting up a particle arrangement, it's of import to note that most of a particle systems lawmaking is only ever called once in a game, usually in some type of controller object in the commencement room or level (this is not ever the case, merely it's a general dominion of thumb).

This is because a particle system, once created, stays in memory and is prepare to be used at any time. If you create it more than once, it can quickly increase the memory usage and somewhen crusade serious lag at best, or crash your game at worst.

Since you'd probably like to avoid those kinds of calamities, we'll be showing you how to make a global particle system that tin can exist used by any object at any time.

Role I - CREATING A PARTICLE SYSTEM

To start, we'll need a controller object for the particle system. We'll besides need to define the system properties and give it a proper noun and then we tin can utilize it later.

This particle controller object will exist placed in the first room of your game. To keep things elementary, we'll place the following lawmaking in the Game Start event.

Since this is going to be a global system that any object tin use, nosotros'll prepare it up like this:

Code

global.P_System=part_system_create_layer(layer, true);

GML Visual

Notice that the particle arrangement is given a layer.

In the code above. we're assigning information technology to the layer that the instance running the code is on, but y'all could as easily requite information technology to whatsoever layer present in the room that the controller example will be placed in.

It's good exercise to create a layer specifically for the particle organisation then identify your controller instance on that (or assign the layer when you create the system).

Note that we as well flag the organisation as persistent. This is because we want information technology to persist across all rooms without having to recreate it again. If you set this to faux, trying to admission the system using the global variable will cause an mistake.

That's the system created so, merely what well-nigh the particles? Until we define them, the system is basically useless.

To create a particle, you lot have to define its full general backdrop. These are like object properties, just they but utilise in a general way to individual particles.

What this ways is that if you give the particles a minimum motility speed of one and a maximum move speed of two, any particle created by the organization will have a random speed between one and two pixels per footstep, and an boilerplate speed of 1.5.

Let's proper name and add our commencement particle to the system. The post-obit code should get in the Room First event of the same object nosotros used to create the particle system:

Code

global.Particle1 = part_type_create();

GML Visual

Before we go on, it's worth noting that the GML Visual activeness permits you to enable or disable additive blending for the particle when it's drawn to the screen. We'll explicate what enabling this means in a little while.

And then, we've created a particle type, but we still need to define its general backdrop (ie: how it looks, its speed, rotation, blastoff etc.).

How to define a particle'southward properties

We tin use a number of different functions to define a particle effect:

part_type_shape(ind, shape) - Sets the shape of the particle type to any of the constants above (default is pt_shape_pixel).
part_type_size(ind, size_min, size_max, size_incr, size_wiggle) - Sets the size parameters for the particle type. You specify the minimum starting size, the maximum starting size, and the size increment in each pace (employ a negative number for a decrease in size).
part_type_scale(ind, xscale, yscale) - Sets the horizontal and vertical scale. This factor is multiplied alongside the size parameters we merely mentioned. It's particularly useful when yous demand to scale differently in 10- and y-direction.
part_type_color3(ind, colour1, colour2, colour3) - Indicates which three colours the particule will fade between over the particle'southward lifetime.
part_type_alpha3(ind, alpha1, alpha2, alpha3) - Sets 3 alpha transparency parameters (0-1) for the particle type, which the particle volition merge between over its lifetime.
part_type_speed(ind, speed_min, speed_max, speed_incr, speed_wiggle) - Sets the minimum and maximum speed properties for the particle type. A random value betwixt your minimum and maximum speeds is called when the particle is created. Y'all can indicate a speed increase in each step. Use a negative number to slow the particle downward (the speed will never get smaller than 0).
part_type_direction(ind, dir_min, dir_max, dir_incr, dir_wiggle) - Sets the management backdrop for the particle type. Again, you lot specify a range of directions in counterclockwise degrees (i.e. 0 indicates motion to the right). To permit the particle move in a random direction, choose 0 and 360 as values. You tin can specify an increment in direction for each pace.
part_type_orientation(ind, ang_min, ang_max, ang_incr, ang_wiggle, ang_relative) - Sets the orientation bending properties for the particle type. You specify the minimum angle, the maximum bending, the increase in each footstep, and the corporeality of wiggling in the angle. You tin as well indicate whether the given bending should be relative (1) to the current management of motion or absolute (0). By setting all values to 0 but ang_relative to i, the particle orientation will precisely follow the path of the particle.
part_type_blend(ind, additive) - Sets whether to utilize additive blending (1) or normal blending (0) for the particle type.
part_type_life(ind, life_min, life_max) - Sets the lifetime bounds for the particle blazon.

Before we start looking at applied examples of these functions, let'southward go over a couple of these properties in more detail.

What is a particle wiggle?

When you see wiggle every bit an statement for a particle office, it means that if you place a number between i and 20, the particle will fluctuate betwixt the min and max values for the code (with one being a tedious wiggle and 20 being very fast).
A particle speed minimum of 2 and maximum of v with a wiggle of xx will oscillate very quickly between the min/max speeds for the lifetime of each particle.

What is a particle lifetime?

A lifetime is the length of fourth dimension, measured in game steps, that a particle will exist for.

Then, a lifetime of xxx min and 30 max will take the particle existing for exactly 30 steps, but a lifetime of twenty min and 60 max will have each particle be for a random number of steps between 20 and lx.

What are particle blend options?

If y'all're using GML Visual, particle blending is enabled or disabled when you create a particle blazon, as nosotros discussed earlier. With this, you lot can set the particle to have condiment blending (enabled) or normal blending (disabled).

Having condiment blending means that a particle'due south brightness volition be added to any appears behind it on the screen, such equally sprites, backgrounds, or even other particles. This creates a saturated glowing look that'southward useful for fire and magic effects, for case, but non so useful for things like smoke.

Experiment to see the differences when creating your own particles, merely keep in mind that additive blending will normally increment the texture swaps that render the game, which in plow tin cause lag if you use besides many.

To ascertain our global particle using the functions we detailed above, nosotros'd add something like this (once again, in the Room Start result of the controller, where nosotros defined the particle system):

Code

part_type_shape(global.Particle1, pt_shape_flare);
part_type_size(global.Particle1, 0.01, 0.05, 0, 0.5);
part_type_color3(global.Particle1, c_aqua, c_lime, c_red);
part_type_alpha3(global.Particle1, 0.5, 1, 0);
part_type_speed(global.Particle1, ii, 5, -0.10, 0);
part_type_direction(global.Particle1, 0, 359, 0, twenty);
part_type_blend(global.Particle1, true);
part_type_life(global.Particle1, xxx, 60);
GML Visual

So now that nosotros've divers our particles, how do we make sure they're ready to be used?

PART 2A: CREATING PARTICLES Direct

There are a couple of ways to create particles, and each has its pros and cons. You can use emitters to burst or stream particles, or you can create particles directly at a point in the room.

Which ane you use really depends on what effect you're trying to create, but we'll get-go with the easiest of the two, which is creating particles straight without the employ of an emitter.

You can use the following steps in any event where you desire to make particles appear (step event, a collision upshot, a mouse pressed event, etc.):

Lawmaking
part_particles_create(global.P_System, mouse_x, mouse_y, global.Particle1, 50);
GML Visual

That brusque string of code will create 50 particles of Particle1 from our global system at the position of the mouse cursor (you lot can see this beingness used in the Global Mouse Down event, linked at the end of this article).

The corking thing about that line of code is that it can be used anywhere without any fuss. For instance, if yous accept a rocket, you could place code like this in the pace event to create fume particles at every step, or add it into a standoff event and have a harm effect burst when the rocket is striking.

Particle Trail

You can also utilise this to create particles over an surface area by irresolute the 10/y coords randomly, for case:

Code
echo(l)
{
var _mx = mouse_x - fifty + irandom(100);
var _my = mouse_y - fifty + irandom(100);
part_particles_create(global.P_System, _mx, _my, global.Particle1, v);
}

GML VIsuals

The code above will create 250 particles at a random position within a 100px square area around the mouse cursor position.

Particle Burst

Part 2B: CREATING PARTICLES WITH EMITTERS

Since we've explained the piece of cake fashion to create particles, let's at present go the slightly more complex but versatile way, which is to use emitters.

Emitters are another attribute of the particle arrangement that has to be defined before being used, and then we'll make a global emitter the same as we did for the system and the particle type.

We also have to decide whether to have a static (non-moving) emitter, whether we're going to burst or stream the particles, and what expanse and distribution we're going to have the emitter apply.

Types of particle emitters

A static emitter is one that y'all only need to define once. This is useful for something like a log burn - information technology's non going anywhere, and all nosotros demand it to exercise is crepitation like the adept petty fire it is.

Nonetheless, a fireball would require a dynamic emitter, since we'd desire it to motion across the screen.

As for bursting or streaming, a flare-up is a one-off explosion of particles, whereas a stream is just that - a constant stream of particles every game step.

You can also use emitters to define an expanse for emitting particles (which tin be a rectangle, ellipse, diamond, or line) also as the distribution curve (gaussian, inverse gaussian, or linear).

The following images illustrate the different types of shape available:

The distribution curves are illustrated hither:

Hither'south a ready of instance codes that define two emitters.

1 will exist static and stream particles over the surface area of the whole room, while the other will follow the mouse and flare-up every 30 steps from a small ellipse.

The first code block should go in the Game Start Effect along with the rest of the lawmaking that defines the system:

Code
global.Emitter1 = part_emitter_create(global.P_System);
global.Emitter2 = part_emitter_create(global.P_System);
part_emitter_region(global.P_System, global.Emitter1, 0, room_width, 0, room_height, ps_shape_rectangle, ps_distr_invgaussian);
part_emitter_region(global.P_System, global.Emitter2, mouse_x - 50, mouse_x + 50, mouse_y - 25, mouse_y + 25, ps_shape_ellipse, ps_distr_gaussian);
part_emitter_stream(global.P_System, global.Emitter1, global.Particle1, 10);
alarm[0] = room_speed;
GML Visual

The first emitter volition now constantly stream particles every step, and the second emitter has been setup, just does nothing. Since we want it to be a dynamic emitter and burst particles every 2d, we need to add an Alarm[0] event:

Code

part_emitter_region(global.P_System, global.Emitter2, mouse_x - fifty, mouse_x + 50, mouse_y - 25, mouse_y + 25, ps_shape_ellipse, ps_distr_gaussian);
part_emitter_burst(global.P_System, global.Emitter2, global.Particle1, ten);
alarm[0] = room_speed;
GML Visual

Hither, we change the position of the emitter based on the current mouse cursor position, and and then we burst some particles before resetting the alarm.

You lot tin can call the emitter region functions at whatsoever time and apply them to create some complex effects past tweening values for their area and position. All particles created after each change volition follow the new settings.

But what if you want several objects to emit particles at the same time?

A global emitter can only be in one place at a time, and so you would need to create local emitters in each object. These emitters volition still use the global particle system and whatsoever particles that are within it, but they can be different shapes and sizes and move with the object, making them platonic for rockets, bullets, or anything else that moves.

Y'all can use the same code we used above, only without the global. before the emitter names (if yous drag room1 in the example file to the elevation of the room resource above room0 and run the game, yous can run into examples of this).

Local Particle Emitters

That's the cosmos of particles dealt with, but at that place is 1 more thing that'southward very of import: clean-up!

PART 3: CLEANING UP

As nosotros mentioned earlier, in one case created, a particle organisation (and its particles, emitters etc.) is stored in memory for instant utilize. Merely what happens when you restart the game? Or if your thespian dies and starts the room once again?

Well, if you don't manage the lawmaking right, you get a memory leak.

This is when something starts eating up retentivity because it's been created then dereferenced (ie: the variable that stored it no longer exists, and then the game no longer has access to it). This will cause lag or even block the figurer causing your game to crash.

It'due south a pretty common problem with start-time users of particle systems, but GameMaker allows you to delete particle systems and their emitters, as well equally particles from retention when they're not in use.

First of all, you demand to determine where you lot're going to create the organization and how y'all'll use it. You could create information technology in the Game Get-go event of an object that's in your start room (like a carte or championship screen), but this means that if you restart the game lawmaking using the game_restart() function, it'll be recreated and cause a retentiveness leak.

To avoid that happening, yous'd demand to accept something like this in the Game End event of your object:

Code
part_type_destroy(global.Particle1);
part_emitter_destroy(global.P_System, global.Emitter1);
part_emitter_destroy(global.P_System, global.Emitter2);
part_system_destroy(global.P_System);
game_restart();
GML Visual

This volition remove the defined particle, the emitters, and the system from memory before restarting the game over again.

If you lot take information technology in a controller object that's placed in every game room, you could take the create outcome that defines the particle system and other parts, and then identify the destroy codes in the room end event.

Whenever you lot start thinking most the well-nigh suitable place to create your particle system, don't forget to consider the most suitable place to destroy the arrangement, besides.

You now know the nuts of particles, particle systems, and particle emitters.

Before you lot rush off to adorn your games with all your new-found knowledge, it's worth remembering that while particles are less CPU-hungry than objects, only they're not always the solution. No matter how dazzling the particle upshot, you don't want them to make your game lag or crash.

We also recommend checking out one of the many particle designing tools that are available, such equally:

Geon FX, useful for visually creating and editing particle effects
Sparks, a particle animation tool that will create sprites from particle effects (useful for HTML5 and other occasions where particles cannot exist used).

Happy gamemaking!