You are on page 1of 8

Meagans Particles

by DerVVulfman
This script allows you to create particle effects for the RPGMaker XP system. You can assign individual particle patterns to an event through simple script calls, or complex patterns where the particles may only show after a predetermined set amount of time. The system was designed based on a study of the particle effect systems by PinkMan, Near Fantastica, Anaryu and arevulopapo. A certain degree of streamlining was done, and a reworked method of designing particle behavior was crafted. This makes for a cleaner way to design the effects themselves. As a bonus, particle effects can also be included as a part of the games battle animations, whether used in battle or as an animation displayed on the field map.

Part 1: Creating an effect on the map Part 2: Creating a Battle Animation Effect Part 3: Calling a Particle Effect from a Script Call Sample Script Calls Things to Note Part 4: Defining your Particles Velocity Opacity Rotation Size and Scale Part 5: Chaining your Particles Together

Part 1: Creating an effect on the map It goes without saying that you will want to show your particle effects on the field map. What good would the system be if you didnt? So herein I describe some of the nuances of using the particle effects. Particle effects on the map are generally adding a script call to a map event. The script call may be either particle_fx or particle_chain . Either of these two calls may bring up an effect that has been created for your project. But there are a number of things to consider: ! Constant effects that are running the moment you enter the map:
Map events that have a constant effect are created by an event that runs a parallel process the moment the event is created. But map events that have effects such as fires, portals and like effects cannot have the script call generating them be the first thing run. At least a 1-frame delay must be called before the effect runs, like so:
@>Wait: 1 frame @>Script: particle_fx(1,fire,event)

The reason is this: The events on a map are created before the map itself is generated. The system will attempt to add the particles to the screen, but there is no map screen (Spriteset_Map) yet loaded. To remedy this, any constant particle effects that run the moment the map is loaded must be preceded by a Wait: 1 frame command. You obviously wouldnt need the wait command if it was an action trigger event.

! Whos controlling the particle effects:


As the system uses script calls to generate the particle effects, you can direct your particle effects to be linked to whatever valid event you have on the map, including the player itself. This means that if you have three events on the map, you could have one event running in a parallel process that performs script calls that draw particles onto the other two events.

! Triggered actions on events with particle effects:


As stated earlier, cycling particle effects are generated by a map event that is running a parallel process. As this is the case, it will be unlikely to find an event generating its own cycling particle effect to be able to trigger any other actions such as the opening/closing of a door, talking to an NPC or the like. In all likelihood, creating an object that has a cycling particle effect and performs an action trigger will require a second event. The second event would be the one creating the particle effect and directing it to the first. So, if you have a sparkly pearly gate event (EV001) that opens by the players action, you could create an invisible parallel process event (EV002) that creates the sparkle on the first event: particle_fx(1,sparkle,event)

! Forseen problems with an anti-lag script:


For maps that contain events that run parallel processes, please keep in mind that some anti-lag scripts are designed to temporarily deactivate events that are not within the visible 20x15 grid window of your game. As such, events that are not visible may not run. If you are using a parallel process to create particle effects on other events, the effect may be turned off if the event creating the effect is not within the visible game screen.

Part 2: Creating a Battle Animation Effect Now this is something to enjoy, having the ability to add particle effects to a battle animation, whether it is used on the field map or in battle. Believe it or not, it is almost TOO easy. The particle effects shown in a battle animation are chained particle effects. Chained particle effects are identified by an ID number which is made when creating the chain effect. But the creation of the chained particle effects will be discussed later. To insert a chained particle effect into a battle animation, you will be using a flash effect in your animation. This will be in the upper-right window that says SE and Flash Timing. If you examine the 7th animation: 007: Sword, it will appear as so:
#001 #002 094-Attack06 Target(255,255,255,255),3 None Hit

In order for you to add a particle effect to such an animation, you would create another flash effect which would make the window look like this:
#001 #002 #002 094-Attack06 Target(1,0,0,0),2 Target(255,255,255,255),3 None Hit Hit

Is that it? No. It goes without saying that anyone can add another hit to a battle animation, but it does no good if you do not know what is going on. Meagans Particles has a small area within the script that is entitled Particle Flash Color. This defines the specific color the system uses to see if a particle effect flash is found. By default, the particle effect color is set to Color.new(1,0,0,0) (1=red, 0=green, 0=blue, 0=alpha). And as you can see in the above examples, one of the flash effects has the target flash set to (1,0,0,0). This means, it will trigger our particle effect system because that flash matches the one we defined.
#002 Target(1,0,0,0),2 Hit

But... which effect? On the same line as the flash color is another number that identifies which particle chain to use. In this instance, it is the #2. So, when it realizes that the flash triggers the particle effect system, it just reads the duration as which particle chain to use. Particle chains are described later.
#002 Target(1,0,0,0),2 Hit

Battle animations are normally defaulted to be drawn on the screen. However, battle animations that are drawn on the field map are linked to the event. In this way, there is no bleeding or tearing if the player is walking and the map scrolls.

Part 3: Calling a Particle Effect from a Script Call Stated earlier, you can generate particle effects that cycle constantly, but you can make your system perform effects once triggered. You can make one event run a script call giving itself an animation, or you can craft an event that applies a particle effect upon another event or even to the player itself. There are only two commands that you would use that actually calls the particle effects to the map, and these two script calls are described below: particle_fx Syntax: particle_fx(event_id, effect, target, delay, x-pos, y-pos, z-depth) This command draws a single particle on the screen. While it doesnt sound like it does much, events that repeatedly cycle and draw particle effects (like fires) can create dynamic effects.
event_id effect target The ID of the event the particle(s will be generated. In this way, you can have one event apply a particle effect to a different event. To apply particle effect to the player, set this value to -1 This is the identifying name of the particle effect as listed in the particle effects list of definitions (see below) This determines how the effects are placed in the map. Valid choices are either screen or event. It is recommended that stationary events are set to event while moving events are set to screen. By default, it is set to draw particles on an event target setting. (In Frames) This determines how long before the particle takes before it is generated. By default, it is set to 0. (In Pixels) This determines how far left or right the particle effect is drawn from the center of the event it is applied. By default, it is set to 0. (In Pixels) This determines how far up or down the particle effect is drawn from the center of the event it is applied. By default, it is set to 0. This determines the depth of the particle effect, whether it is more likely to be drawn in front of the event or behind it. By default, it is set to 0

delay x-position y-position z-depth

particle_chain Syntax: particle_chain(event_id, chain_id, target, x-pos, y-pos, z-depth) This command brings up a list of particle effects that are played in succession, creating a more spectacular and longer on-screen effect.
event_id chain_id target The ID of the event the particle(s will be generated. In this way, you can have one event apply a particle effect to a different event. To apply particle effect to the player, set this value to -1 This is the identifying ID number of the particle chain created in your list of chained effects (see below). This determines how the effects are placed in the map. Valid choices are either screen or event. It is recommended that stationary events are set to event while moving events are set to screen. By default, it is set to draw particles on an event target setting. (In Pixels) This determines how far left or right the particle effect is drawn from the center of the event it is applied. By default, it is set to 0. (In Pixels) This determines how far up or down the particle effect is drawn from the center of the event it is applied. By default, it is set to 0. This determines the depth of the particle effect, whether it is more likely to be drawn in front of the event or behind it. By default, it is set to 0

x-position y-position z-depth

Sample Script Calls particle_fx(2, red, screen This sets a particle to be drawn over event #2. It being the red particle effect as described in the list of definitions., and assigned to the screen viewport

particle_fx(1, blue,event, 40,5,10,20) This sets a particle to event #1, it being the blue particle as described in the list of definitions. Assigned to be linked to the event , it turns on after 40 frames. It is off by 5 pixels to the right, and 10 pixels down and has a depth of 20 (being drawn over the event).

particle_fx(-1, fire, screen, 5)

This sets the particle to draw over the player (ie -1), is set to use the fire particle, draws directly to the screen, and will start showing after a 5 frame delay. This sets up the system to draw a chain of particle effects onto the player (-1), the chain of effects identified as ID #4 in your list of chained effects. All other values (target, x-position, delay) are default values.

particle_chain(-1, 4)

Things to Note A common trait among particle engines for RMXP is a bleeding motion effect when the screen scrolls because the player moves towards the edge of a map. Particle effects rendered straight onto the Spritemap tend to lag behind and the effect makes them shift off-center where they should be placed. While this effect is not noticed when the event creating the particles is moving, it is highly noticeable on static events with particle effects such as fireplaces, torches, etc. However, applying 'event' targeting to moving gives its own visual quirk as the particle effect being generated first appears in the tile where the event is moving into. Almost the polar opposite of the 'screen' bleed effect.

Part 4: Defining your Particles This section delves into the actual creation of the individual particles you display on the screen; the appearance, behavior, and how long they last before they fizzle out of existence. Each particle effect is defined by a number of conditions: graphic, motion, gravity, opacity, rotation, size and scale. And it is by these that the behavior of the particles are controlled. The syntax is thus: P_Defined[name] = [image, [horizontal], [vertical], gravity, [opacity], [spin] ,[size], [scale] ]
name image horizontal vertical gravity opacity spin size scale This is a string value identifying the particle effect, and it is by this in which you identify which effect you use in a script call. It should be something recognizable. This is the filename for the graphic image used to generate your particle effect. All particle effect images are kept within the Graphics/Particles folder in your project. This is an array holding three values that control the horizontal velocity and direction of the particle. This is an array holding three values that control the vertical velocity and direction of the particle. This value increases or decreases the vertical motion of the particle effect. This array controls the transparency and fade effects of the particles generated. This array controls the angle and speed of rotation for the particle if any rotation is desired. It may be set to 0, or else positive and negative values may be used. This array sets the initial size of a particle when it is first generated. This sets the rate of growth/shrinkage of a particle after it is generated.

Obviously, a number of values to have for each particle, to be sure. But you can create the movement behavior, the manner a particle fades away, and even how they look, in a single line of data. Additional data for the Horizontal and Vertical particle velocities, the opacity levels, and the like are explained below.

Velocity Sprite velocity, for both horizontal and vertical motion fall under the same basic formula, though vertical motion may be hampered or accelerated by the 'gravity' value. Both horizontal and vertical arrays have the same syntax: Syntax: [ base_value, variance, scale ] Which is calculated with the formula ( base_value + (1 - variance) ) X scale So a value of [10,30,0.5) would generate: ( 10 + (1 to 30) ) X 0.5... or as RGSS would calculate it: value = (10 + rand(30)*0.5

Opacity Particle effects do not last on the screen. Indeed, they fade away either quickly or slowly depending upon the creator's whim. It is here where you set how long a particle may last. And they all follow the same syntax: Syntax: [ base_value, fading_value, base_variance, fading_variance] It's not as complicated as you would think, and all values are based on the typical range of 0-255. The base value indicates the graphics opacity, and the fading value is the value which the opacity is reduced every instance the particle is updated. As such, a base of '255' and a fade value of '1' will take a longer duration to fade than a particle with a base of '160' and a fade value of '4'. But there are also matching 'variance' values which let you give the particles a touch of randomness. Both the base and the rate have random values which can be added to them to change the particle's opacity and how fast/slow they dissipate. Given that, you can create an opacity dissipation formula like so: [160, 10, 5, 3]. This is interpreted like so: The particle's opacity is 160 + rand(10))... or 160-169 opacity, and fades away by 5 + rand(3)... or by a rate of 5-7 each update until the opacity of the particle is 0.

Rotation Even easier to handle is the rotation array of the particles. Merely two values, the only thing you control is the angle the particle is shown and how fast it spins. Syntax: [ angle drawn, rotation speed] Oh, so easy. The first value defines the angle the image is drawn... with 0 being drawn straight. The rotation speed (either positive or negative values) indicates how fast or slow the particle rotates once it is generated.

Size and Scale A double whammy, these two arrays control the initial size of the particle when it is generated and how big it will grow (or reversely how small it shrinks). The syntax is like so: Syntax: [ x-size, y-size ], [ x-scale, y-scale ] The first values indicate how big or small they are when generated... for both x and y size representations. If set to [ 1.0, 1.0 ], the image is set to normal size proportions. But if set to something like [ 1.5, 0.5], then the generated particle is 50% wider and the normal height. The scaling array is pretty simple too. If set to a value of [0.0, 0.0], then there is no size increase or decrease. But if you set to something like [ -0.5, 2.0], then the particle becomes thinner but taller with each frame it lasts on the screen.

Part 5: Chaining your Particles Together Now comes the time when you can create spectacular effects by combining your particles into a single display. And believe it or not, it is not hard at all. The typical syntax for a particle chain is thus: P_Chain[chain_id] = [ [called particle], [called particle], ... [called particle] ] Whereby the chain_id is a numeric value which is used to identify each particle chain, and where each called particle array is a particle effect used in the chain. You can have two, seven, even twenty different particle effects in a particle chain. The syntax of each called particle array is this: [ definition_name, x-position, y-position, z-depth, delay] And it should be pretty clear what each is. NO??? Okay, here we go... again.
definition_name x-position y-position z-depth delay This is a string value identifying the particle effect, and it is by this in which you identify which effect you use in a script call. It should be something recognizable. (In Pixels) This determines how far left or right the particle effect is drawn from the center of the event it is applied. By default, it is set to 0. (In Pixels) This determines how far up or down the particle effect is drawn from the center of the event it is applied. By default, it is set to 0. This determines the depth of the particle effect, whether it is more likely to be drawn in front of the event or behind it. By default, it is set to 0 (In Frames) This determines how long before the particle takes before it is generated. By default, it is set to 0.

So, you could set up a single chain like this: P_Chain[12] = [ [fire, 0,0,0,0], [fire, 0,0,0,10], [fire, 0,0,0,20], [fire, 0,0,0,30]] ...which would generate four fire particles, each 10 frames apart. This particle chain, identified as chain #12, could be called in two ways. It could be called from a script call using the statement, this chain of fire effects hit event #8.
particle_chain(8, 12,event), which lets

Or, you could apply it to a battle animation by setting up an animations flash as so:
#002 Target(1,0,0,0),12 Hit

And thats really it!