Physics Jam 2026 · Surfing

Making-of RagRat

Sunday Jam, Physics Jam

Mike told me about the Physics Jam after recording a song for fun. I'd never made a game before, though always wanted to, so was amped to try figure out the whole process before the theme dropped. There was mention of a rat.

He suggested making his own game to learn some physics, and helping me out with graphics for a joint project with 'Claude klapping code'. I was sold - a pixel ragdoll 2d rat! Maybe playing pong? Off I went.

Most of my sessions with Claude Code are kept to a quick back and forth, not allowing the model much effort for testing, asking it to add sliders for features while I tweak the parameters. I'll keep adding to documentation in the code (thats the only place it ends up reading it) with a few key main docs. I had it write out the parameters as sentences - which you can see in the prototype below.

Took 11 hours to get the 1st rat, and most of the rest of the night to get gravity working.

Also: The rat idea wasn't originally Mike's either. We probably should mention Sheldon Bengtson, who had the squishy rat idea to begin with. Sheldon, if you're reading this: thanks.

How the squish is built

Here was the vision:

- the rat needs a fat jiggly belly, but the mass of this belly can shift into his head, with his eyes bulging.

First try was FLIP fluid sim with the body as a sack, with the skin having some more rigid areas like the neck and snout, like a sort of stress toy balloon. - but pulling the skin created empty space instead of moving the fluid, and solving the skin against the fluid against the spine was not working, and I didn't want a heavy sim.

Then, ditched the fluid simulation, and keep the bones controlling the flesh, - points inside the body with loose springs between them.

To get the head to bulge by squeezing the stomach — was with conservation of compression — compressed springs distribute their tension through the rest of the body via path of least resistance.

A spring lattice under the skin and compression that has to go somewhere. Squeeze the stomach, the tension takes the cheapest path out, and it leaves through the head.

The fluid idea didn't die, though - I wanted that when he was held upside down, the fat would move to his head - so instead of a voxel grid, it became represented as fluid points on the spine - much cheaper and more manageable.

The animal, layer by layer

The mesh is triangulated once at build time.

The art pipeline

Next I was excited to skin it, so the art pipeline - Each body part - a layer in an SVG; edit in Illustrator, save, refresh, and the rat is wearing it - I tried PNG methods too, but eventually scrapped them as deformed / rotated images don't work well if you are trying to get hard pixels.

The repo opens

Out of java, and into Godot

At this point, I didn't know if what I had was useable for a game, my simple 'handrolled' props were certainly lacking the robustness of a real game engine. I decided on Godot on the premise that it handles vector hard pixel rendering quite well, and would allow me to build levels and adjust parameters without having to build a ui for it - and after checking that it could handle a sim solver in C++ - assuming this would give a performance improvement over the web version - yep around 80x faster on the simulation, and by prompting Claude to build tests to profile the different parts of the sim, were later able to bring it down further.

I figured that doing the port seemed like a mechanical thing it should be able to do autonomously, and was curious - so gave it the goal of keeping the sim the same, but able to handle 8 rats at once at 60hz - but I was way wrong here, and the reason for it, was that in striving for the C++ sim to be bit-identical, it built many tests and protocols and made it impossible to improve anything further until I spent serious time cleaning up all the comments and directions and deliberation written in the ported codebase. At this stage I built rules that failed it when writing any files with more than 15% comment, and failed when editing a dev document to more than 10kb. And must admit it is satisfying to watch it try again and again to trim its comments when starting to write files during a new session. Cleaned the port and removed traces of the original sim from the repo.

AGENTS.md was 35 KB of fifty-four numbered incidents, and a file that size is never read · RECORD.md was a ritual nobody read, including me

A character building studio, and testing some game ideas

I was still planning to maybe migrate to another creature so made an html app to load the body shape, assign the main anchors and bones, and export the SVG for illustrator to edit and do the artwork. The likeness became closer to Mike's original artwork, and I was already quite attached to the character at this stage...either way we can still make some interesting squishy characters in the future.

double-click studio.bat and the whole job is ten steps on one html page

I was still trying more game ideas with the rat before the theme drop. Bowling took the whole day, but I was starting to finally feel comfortable that I had an environment I could make a game in. Also I very quickly tried a climbing type game.

Game Jam Starts! Surfing

I thought there's something musical about it — like the beat is the uneven terrain and the continuous motion of it is the goal.

and he's sliding along the terrain — i guess it would have to be like the crest of a wave..... and the interaction is affecting the terrain? .... hmmm the squash is the score... pump, launch, switch, land ....

The next morning - the hand grabs the wave and pulls the land up under him.

I went for the music, ported an opensource bittune library (DrPetter's sfxr) - kicks, hats and snares, following a string of characters in a godot parameter - "KhhhShhhKhhhKhKhShhh" makes a simple beat. Then another string for a Synth, Then a tempo meter that goes green when you're on the beat.

Flappy rat, the surfboard, and the Ableton VSTs

At a party, mike suggested we try a flappy bird type game - ratFlap was born. Built as a throwaway.

The surfboard goes under him, and it scales as it tilts for a 3d feel.

i realise that our music strings are just not enough — we need to build a little music editor or perhaps get our sounds into ableton so we can author the music for our scenes

So we fetched JUCE and wrote our own VST3 plugins, in a day.

two instruments in Ableton, and stopping the transport prints the score

So levels are written as a song in Live. Hit stop, the plugin saves it, and the game builds the course from what they printed. Drums, bassline, synth stabs, the slick platforms, the poison stretches, one magnetic wheel of cheese — all notes on a piano roll.

The final stretch

The global leaderboard went up, the board got Mike's artwork, and the water learned to poison him.

Then a wheel of cheese that turns the magnet on — authored in Ableton as a note, like everything else. The magnet pulls pickups vertically only, so collecting them can't put you off the tempo. The BPM gauge — turtle at the slow end, rabbit at the fast — went in the next morning.

The pickups, animated in After Effects

Each note on the piano roll becomes one of these in the water. Drawn and animated in After Effects, then mosaiced down to the pixel grid and exported as a filmstrip the game plays back — a loop while it waits, and a second sheet for the moment he takes it.

The Intro Screen

The level picker — a white room with holes in the floor, and a level behind each one. You pick a course by dropping him down it. Drafted by hand, coloured in overnight, flattened and vectorised the next morning, and in the game by that night.

Shipped

Mike's last two pieces landed overnight and were in the game by early afternoon — three stars buys the picture of him at the club.

gamazama.itch.io/ragrat

What's me and what's the AI

Most of the work is iterative. The newer models are very impressive and able to complete many tasks autonomously, but this tends to take very long, and go off the rails most of the time, especially when dealing with physics interactions that aren't really part of its training set. I find it will run terribly useless tests, and when looking at screenshots - will only see what it is looking for, so I try aim it at avoiding all the tests and letting it code short snippets one at a time that I can review, and this goes much faster.

The interaction of physics mechanisms, it could not get right on its own, and we built on them iteratively, and i would build setups of parameters for it to test features and breaking thresholds. Sometimes, I would try set it off autonomously, like the port, which was not very autonomous as its tests were not good, and the vst drum upgrades, which it did very well, but this is more of my curiosity than serious work.

All the music & art was built in the more well-developed software, photoshop, aftereffects, illustrator, ableton. Godot was mostly a (very good) distribution platform with an easy path to c++ in both web and executables.

Also: I ran out of weekly tokens twice. Those tests and doing things autonomously costs wastefully.

What Claude says:

I held the taste, the physics intuition, the direction and every judgement about whether it was any good. It held the implementation. Both halves were load-bearing.