Particle System Simulation in Python

A particle system is one of those ideas where the implementation is short but the visual payoff is huge. Every fire effect, every smoke trail, every magic spell, every star field in every game and movie you've ever seen is some variation of "a few thousand dots, each following its own version of the same physics rules". Once you've built one, you can build all of them.

The Mental Model

A particle is just a struct with a few numbers:

A particle system is a bag of particles. Every frame, you do the same thing to all of them: apply forces, move them, age them, draw them. Then on certain frames you emit new particles to replace the ones that died.

That's the whole architecture. The art is in choosing emit patterns and force rules.

Why You Vectorize

The naive way to write this is one Python object per particle, with a for particle in particles: particle.update() loop. That works for 100 particles. It crawls at 10,000.

The NumPy way stores every particle's data in a 2D array and updates all of them in one expression:

self.vel[alive, 1] += gravity      # apply gravity to every alive particle at once
self.pos[alive]    += self.vel[alive]   # move every alive particle at once

This is the same trick that makes the Mandelbrot snippet fast. NumPy is ~50x faster than a Python loop here, which is the difference between a particle system that holds 500 particles and one that holds 50,000.

The Recycling Trick

Notice the snippet pre-allocates a fixed pool of n=4000 particles up front, then "emits" by finding particles whose life <= 0 and resetting their fields. It never grows the array.

This matters because:

This is exactly how production game engines do it. The pattern is called object pooling.

The Physics, In Three Lines

The step() method has three operations and that's it:

self.vel[alive, 1] += gravity     # forces accelerate the particle
self.vel[alive]   *= drag          # drag slows it down
self.pos[alive]   += self.vel[alive]   # velocity moves the position

This is the simplest possible numerical integration — Euler integration. It's not the most accurate (energy slowly creeps up over time), but for visual effects nobody cares. For a physics simulation where accuracy matters (planets, molecules), you'd use velocity Verlet or RK4 instead.

Drag Is Underrated

Adding vel *= drag (with drag = 0.99) makes the difference between particles that fly off the screen and particles that arc and float gracefully. Each frame, every particle keeps 99% of its velocity. After 60 frames, it's down to ~55%. After 200 frames, ~13%. That natural deceleration is what makes smoke look like smoke and explosions look like explosions instead of straight-line missiles.

Emit Patterns Are The Whole Personality

The step() method is identical across every particle effect you'll ever write. The only thing that changes is how new particles are spawned:

Every one of these uses the same step() and the same render function.

Fading And Resizing With Life

The fade = life / max_life trick is a tiny but huge detail. Each particle's transparency and size follows its remaining life:

Without this, particles pop in and out of existence — which looks terrible. With it, the system breathes.

What's Hard About This In Pyodide

The snippet above renders static snapshots at chosen frames rather than running a true animation. The reason: this code runs in a Web Worker, which doesn't have a real-time canvas to draw to. For a real animated version, you'd:

The four-frame fireworks panel and the steady-state fountain shot capture the essence of what an animation would look like — particles in different stages of their life, fading, falling, dispersing.

What To Try Next

Run the snippet above and you'll see fireworks captured across four moments — the bursts firing, the trails arcing, the embers fading — and a continuous blue fountain spraying upward in steady state, all driven by the same three-line physics loop.