Hi. I'm the name at the top of the longer ViralBalls articles: the ones about why a bouncing ball feels heavy, why certain colours stop a thumb mid-scroll, and why you can watch a power washer clean a driveway for four minutes without blinking.
I write about the ideas behind ViralBalls, and those ideas come from building it. Every article starts with something we ran into while working on the engine, the modes or the sound, and ends with something you can test in the simulator yourself.
This page isn't a résumé. It's a better guide to whether my articles are worth your time: what I write about, how each one gets made, and the work in this project that the writing comes from.
What I write about
Three topics keep pulling me back.
Simulation that looks right, not just simulation that is right. A physically accurate bounce and a satisfying bounce are not always the same thing. Real elastic collisions can trap a ball in a boring loop, grazing the same stretch of wall forever. Watchable physics bends the rules a little, and I'm interested in exactly how much.
Sound as part of the physics. Mute a video of a falling boulder and it turns into foam. Pitch, attack and low end tell your brain how much mass it's looking at. I write about that because in ViralBalls, sound isn't laid on top after the fact. Every wall hit fires an audio event in the same frame it happens.
Why people keep watching. Completion, symmetry, near misses, the small release when a ball finally slips through a gap. That's where psychology meets frame timing. I try to stay on the side of what we can see and test, and to say so when an idea is a hunch.
The work behind the writing
ViralBalls started as a first commit in February 2026 and has grown, one small change at a time, into a browser physics sandbox with ten game modes. The articles come out of building it. Here's some of what that taught us.
A fixed clock beats a fast one
The engine runs on a fixed 60 steps per second. It doesn't matter if your laptop draws at 144Hz or your phone drops to 40. Time builds up in an accumulator, and the physics advances in identical 1/60th-of-a-second slices. Without that, the same setup plays out differently on different machines, and a clip you loved becomes impossible to recreate.
This sounds like a dry engineering detail. It changed how I think about video. Once a simulation is repeatable, you can iterate on it like an edit: change one value, run it again, compare.
Randomness you can replay
Every run is driven by a seeded random number generator (mulberry32, if you're curious). Same seed, same settings, same video, frame for frame. Hit restart and you get a new seed and a new story.
That one decision makes a feature like the simulation finder possible. It runs the engine headless, without drawing anything, across hundreds of seeds, looking for one where the ball escapes within a fraction of a second of the length you asked for. Want a 30-second clip that ends on the beat? It searches for a seed that does exactly that, and nobody has to fake the ending.
Bounces need a nudge
A pure mirror reflection is honest but often dull. The ball skims along at a shallow angle and hits the same few spots over and over. So the engine picks a new direction within 60 degrees either side of the wall's normal. That keeps the bounces spread around the ring, and it's the reason the classic mode feels lively instead of stuck.
On top of that sits what we call the cinematic director. It shapes rebounds slightly toward near misses and dramatic moments, and it gives the ball moods (calm, aggressive, chaotic) that change its speed, trail and glow. None of it breaks the illusion of physics. It makes sure the physics has a plot.
Ten modes, ten small experiments
Each mode began as a question. What if hitting a wall spawned another ball (multiply)? What if the ball painted the arena (paint)? What if it grew with every bounce until it filled the space (grow)? What if walls cracked apart into fragments (shatter)?
Building each one meant deciding what the viewer should feel, then picking the rules that would get them there. Accumulation is about pressure building. Portal is about surprise. Colour match is about the little click of sorting. Most of my articles are about those decisions, with the code as the proof.
Sound made in the browser
The audio runs on the Web Audio API. Hit sounds come from oscillators shaped in real time, songs can play from MIDI files that get parsed and turned into notes as the ball bounces, and wall breaks have their own generated sounds. Writing the article on sound and visual weight meant listening to the same collision with a dozen different envelopes and noting which ones made the ball feel like steel and which made it feel like a ping-pong ball.
Export is part of the design
Everything ends as an MP4 recorded in the browser, often at 1080 by 1920 for vertical feeds. That puts a hard limit on what's worth building. A detail that disappears after compression on a phone screen isn't worth a week of work. A lot of my colour advice comes straight from watching our own exports fall apart: thin lines vanishing, muddy gradients banding, dark reds turning to sludge.
Things I got wrong at first
A few beliefs didn't survive contact with the simulator.
I assumed faster always meant more exciting. It doesn't. Past a certain speed the eye stops tracking the ball and the clip turns into noise. The modes that hold attention best tend to start slow and let speed build, which is why increasing bounciness exists as a setting at all.
I thought more effects would read as more polish. Stack confetti, shatter, shockwave, glow and a colour trail on every hit and the screen gets busy fast. One strong effect on the moment that matters usually beats five on every frame.
And I underrated silence. A short gap in the sound right before a ball slips through the last wall makes the release land harder than any extra layer of audio.
How an article gets made
Every piece goes through roughly the same steps.
- Start with a question we ran into while building. "Why does this mode feel slow?" is a better starting point than "write about engagement."
- Rebuild it in the simulator. If an article makes a claim about motion, colour or timing, we set it up in ViralBalls and record it. If we can't show it, we soften the claim or cut it.
- Read what's already known. Psychology and perception research is messy, so I separate findings that are well supported from ideas that are popular but thin. When something is our own observation, I say so.
- Cut the padding. If a paragraph would survive being deleted, it gets deleted.
- Keep it current. Platforms change their interfaces and our tool changes too. When a setting or screenshot goes out of date, we fix the article instead of leaving it to rot.
What I won't do
I won't tell you a setting will make your video go viral. Nobody can promise that, and anyone who does is selling something. I can tell you which settings make a clip easier to watch to the end, and why, and you can test it yourself in about thirty seconds.
I also won't dress up opinions as science. "Lime green stands out on YouTube right now" is an observation about what we see in feeds, not a law of nature. When I lean on a study, I'll describe what it found without stretching it.
Read these first
If you're new here, these are the articles I'd start with:
- Why We Can't Stop Watching: The Psychology of Satisfying Content, on completion, repetition and why your brain likes watching other people finish things.
- How Sound Design Influences the Perception of Visual Weight, on frequency, foley and making a small object feel huge.
- How to Calibrate Color Palettes for Dopamine-Driven Engagement, on contrast, the 60-30-10 split and testing a palette before you post.
Then go break something in the simulator. Most of what I know came from doing that.
Get in touch
Spotted a mistake, disagree with a claim, or have an idea you want covered? Use the feedback page. It reaches the people who write and build this, and corrections go straight into the article.