Building a Fully Dynamic Particle System in Rive with Scripting & AI Agent

Rive gives designers a high level of control over interactive animation, especially through state machines and real-time behavior.

Because Rive is intentionally lightweight and built around dynamic, real-time systems, it doesn’t rely on plugins or preset effect libraries.

As a result, effects that are often plug-and-play in other tools - such as particle systems for confetti, sparks, or snow - are approached differently in Rive. Their behavior is defined explicitly: how many elements exist, how they move, and how they evolve over time.

Until recently, achieving this kind of behavior required a fair amount of manual setup and offered limited flexibility once in place.

With the introduction of scripting and the AI Agent, this approach becomes practical, scalable, and truly dynamic.

This article walks through how a fully dynamic, reusable particle system can be built from scratch in Rive - using scripting to manage behavior and reuse.

The Mental Model

Before writing any code, it’s important to reframe how particles work in Rive.

Artboard = Particle
Script = Particle System

Each particle is represented by a small Artboard - a visual prefab.
The script doesn’t draw shapes - it creates, positions, moves, and recycles Artboard instances.

This separation gives us:

• Visual control in Design Mode

• Behavioral control in Scripting

• A system that’s easy to extend later

Once this mental model clicks, everything else becomes much simpler.

Creating the Particle Artboard

We start by creating a tiny Artboard that represents a single snowflake.

• Size: 24×24

• Simple white ellipse

• Origin centered

• Defined as a Component

This Artboard has no logic, no animation, and no awareness of the system - that’s intentional.

Using an Artboard for each particle lets us swap the visual later - snowflakes, raindrops, stars, or any other shape - without touching the script at all.

Introducing the Script

We then create a Node Script, which acts as the system’s control layer.

The script is responsible for:

• Spawning particles

• Updating their position every frame

• Applying speed, wind, scale, and parallax

• Recycling particles when they leave the screen

The particle is passed into the script as an Artboard input.
This is a key design choice: the script doesn’t care what the particle looks like - only how it behaves.

At this stage, we define the minimal input needed to keep the system fully decoupled from the particle’s visual design.

type MyNode = {
  flake: Input<Artboard>,
}

Working with the Rive AI Agent

One of the most important parts of this process wasn’t just scripting - it was how the scripting was built.
Instead of writing the entire system upfront, the Rive AI Agent was used to iterate on the logic step by step.

The Agent was especially useful for:

• Adding one behavior at a time (falling, looping, wind, scale, parallax)

• Modifying existing logic without breaking the system

• Refining math and edge cases quickly

• Keeping the code readable and intentional

Rather than “generate everything”, the Agent acted like a pair programmer.

The system was built by describing each next step, testing it visually, and layering complexity gradually - exactly how motion is typically designed.

The Agent doesn’t replace understanding. It accelerates iteration.

Drawing and Updating a Single Particle

Before creating a full system, we start by drawing one particle. We:

• Advance the animation by using the advance() function

• Draw the particle Artboard in the draw() function, update it every frame

At this stage, nothing moves yet. This confirms:

• The script is connected

• The Artboard input works

• The render loop is correct

Building incrementally avoids debugging complex systems too early.

Making the System Screen-Aware

To keep the system reusable, the script needs to be aware of the screen size. We expose these inputs:

• screenWidth

• screenHeight

This allows the system to:

• Spawn particles correctly

• Loop them outside screen bounds

• Adapt to different layouts

Later, these values can be bound to a ViewModel instead of being hardcoded.

Before adding complexity, we verify that the rendering loop and Artboard input behave as expected.

// Make sure the system is working by centering a single particle.
Modify the existing SnowParticles factory script.

Center the Flake artboard in the middle of the screen.

Use the existing variables:
- screenWidth
- screenHeight

Set the Flake position so it is centered on both X and Y based on these values

Falling Motion and Seamless Looping

Now we introduce the core behavior: particles fall from above the screen to below it, then loop seamlessly.

Key rules:

• Particles start outside the visible area

• They move downward over time

• Once they fully exit the bottom, they respawn at the top

This prevents visible popping and creates a seamless, infinite loop.

// Create the base falling single particle animation
Add a looping falling animation to the Flake artboard.

Requirements:
- The animation should loop continuously.
- Duration: 3 seconds.
- Start the Flake above the top edge of the screen (outside bounds).
- End the Flake below the bottom edge of the screen (outside bounds).
- Use Ease In for the motion.
- When the animation loops, the Flake should jump back to the starting position above the screen, without visible popping

Scaling Up with Particle Count

A single falling particle doesn’t yet form a system. We introduce particlesCount and let the script:

• Spawn multiple particles

• Randomize their starting X and Y positions

• Stagger their timing

Each particle behaves independently, but follows the same system rules.
This is the moment where we move from an animation to a particle system.

// Turn one snowflake into a particle system.
Modify the existing SnowParticles script to spawn multiple flakes based on `particlesCount`.

Requirements:
- Create `particlesCount` instances of the Flake artboard.
- Each particle uses the existing 3-second looping falling animation.
- Randomize X position across screen width.
- Randomize Y offset so particles are staggered and not synchronized.

Loop behavior:
- When a particle exits the bottom of the screen:
  - Reset it to the top (outside bounds)
  - Re-randomize its X position

Speed as a System Control

Next, we add speedFactor. It behaves exactly like scaling a timeline:

• 1 → normal speed

• 2 → twice as fast

• 0.5 → half speed

Speed affects the entire system uniformly, not individual particles.

// Control animation speed dynamically using an external input
Use `speedFactor` as a multiplier for the falling animation timing.

Rules:
- speedFactor = 1 → normal speed
- speedFactor = 2 → 2x faster
- speedFactor = 0.5 → half speed

Clamp the value:
- minimum = 0.1
- maximum = 3

Apply this uniformly to all particles.
Do not modify any other behavior

Adding Wind

To make the motion feel more natural, we introduce wind. Instead of using raw angles, wind is normalized between -1 and 1:

• -1 → Wind to the left

• 0 → No wind

• 1 → Wind to the right

This value is mapped to a small angle (±15°) and used for slight rotation and horizontal drift
Normalization keeps the system predictable and easy to bind to external data.

// Add sideways motion for wind effect and tilt using a single normalized input.
Use the existing `wind` input, normalized between -1 and 1.

Interpret the value as:
- wind = -1 → blowing left
- wind = 0 → no wind
- wind = 1 → blowing right

Map the value to a maximum rotation of ±15 degrees.

Apply:
- Rotation based on wind direction
- Horizontal drift using the sine of the angle

Keep the falling animation logic unchanged

Expanding the Spawn Range

Once wind is applied, particles can drift sideways.
Instead of correcting positions with offsets, we expand the horizontal spawn range to about 120% of the screen width.

Particles can start slightly outside the screen and naturally drift into view.
This keeps the logic simple and avoids artificial corrections.

// Avoid empty gaps when wind pushes particles sideways.
Expand the horizontal spawn range so particles can enter naturally with wind.

Requirements:
- Start X at: -0.1 * screenWidth
- End X at:  1.1 * screenWidth

Allow particles to spawn outside the visible screen.
Do not change falling speed, rotation logic, or other behavior

Size Variation with Scale Levels

Uniform particles feel artificial. We introduce scaleLevels - a discrete control (1–5) that defines how many size variants exist.

Examples:

• 1 → All particles same size

• 3 → Small / medium / large

• 5 → Full depth range

Each particle randomly selects from predefined size sets, creating controlled variation without chaos.

// Create natural variation in particle sizes.

Add a new input called `scaleLevels` (1–5) to control size variety.

Rules:
- scaleLevels = 1 → [1]
- scaleLevels = 2 → [1, 0.5]
- scaleLevels = 3 → [0.5, 0.75, 1]
- scaleLevels = 4 → [0.4, 0.6, 0.8, 1]
- scaleLevels = 5 → [0.2, 0.4, 0.6, 0.8, 1]

When spawning or respawning a particle:
- Randomly select a scale from the list
- Store it per particle
- Apply it during rendering

Keep all other behavior unchanged

Depth with Parallax

With a boolean input, useParallax, we add depth.

• Larger particles move slightly faster

• Smaller particles move slightly slower

This creates a convincing sense of depth: near elements feel closer, far elements feel distant.
Parallax is optional - the system works without it.

// Add depth: near particles move faster, far ones move slower.
Add a depth effect using the existing boolean input `useParallax`.

Behavior:
- If useParallax = true:
  - Larger particles move faster
  - Smaller particles move slower
  - Keep the effect subtle
- If useParallax = false:
  - All particles move at the same speed

Parallax should be proportional to particle scale.
Do not modify any other logic

Making the System Responsive with Data Binding

To make the particle system truly reusable, it needs to adapt to the size of the Artboard automatically.

We expose the screen width and height as inputs and bind them via Data Binding to a simple ViewModel representing the screen size.

Once bound, the system becomes fully responsive:

• Changing the Artboard size immediately updates the particle area
• Spawn positions and loop boundaries adjust automatically
• The same system works across different screen sizes without modification

At this point, the particle system is no longer tied to a fixed canvas - it becomes data-driven and layout-aware, ready for real product use.

One Script, Multiple Particle Systems

This is where the system really shines. Because:

• The particle visual is an Artboard input

• All behavior is driven by parameters

• The logic is completely generic

The same script can be reused multiple times. In practice, this means:

• One instance can drive background snow

• Another can drive heavier foreground flakes

• Another can control falling stars or decorative particles

Each instance:

• Uses a different particle Artboard

• Has different counts, speeds, and scale levels

• And runs simultaneously on the same screen

You’re not building an effect. You’re building a system.

Why This Matters in Rive

The snow effect shown here is intentionally simple. Once the foundation exists, extending it becomes trivial:

• Particles can move upward instead of downward

• New parameters can be added to control behavior

• Special effects and interactions can be layered on top

• Each particle can become a complex animated element - not just an icon or an image

Because particles are Artboards, each one can include:

• Its own animation

• Internal state machines

• Interaction logic

• Nested components

This highlights one of Rive’s core strengths: you’re not limited to preset effects.
You’re building vector-based, dynamic, interactive systems designed specifically for your product and your use case.

Final Thoughts

This particle system is fully dynamic, flexible, customizable, and reusable.

By combining Rive’s scripting feature with the AI Agent, complex behavior can be built incrementally - without losing clarity or visual control.

One script. Many effects. A reusable foundation.

What's Next?

This particle system is a good example of how scripting unlocks entirely new workflows in Rive - moving from predefined effects to reusable, data-driven systems.

You can explore more about scripting, inputs, and advanced workflows in the official Rive documentation and community resources.

If you want to learn Rive step by step and see how these systems are built in real projects, you can explore the full course here:

🔗 Rive Masterclass for Designers →