JellyBlob - wobbly jellies and slime-trail combat in Three.js

Showcase
, , ,
1

Hi everyone!

I’ve been working on JellyBlob, a multiplayer browser game where you grow a jelly, leave slippery trails and try to make someone else’s next turn a bad one. You can hop over trails; running into another jelly just makes you bounce.

Play JellyBlob - free, no download or account needed. Quiet rooms have clearly labelled bots, so there’s something to play against.

Jelly rush effects and continuous slime trails
Jelly rush effects and continuous slime trails1120×630 42.2 KB

The speed effect and trails in a close-up renderer test scene.

Getting it to feel like jelly

The client uses Three.js directly with TypeScript and WebGLRenderer. A few bits that might be interesting here:

  • The bodies: MeshPhysicalMaterial with transmission, clearcoat and a low IOR, plus vertex-shader wobble through onBeforeCompile. The squish is a visual deformation over simpler gameplay physics.
  • The trails: continuous, low-domed BufferGeometry with animated colour flow. The leading end follows the rendered jelly so it stays attached while turning. Decorative trail particles are pooled and instanced.
  • The arena: instanced floor tiles and food, with a custom shader for the river’s flow and ripples.

One useful cheat: the floor is brighter in Three’s transmission capture pass than it is in the main view. That keeps the jelly colours bright over a dark arena without making the whole floor brighter.

Translucent jelly over the arena floor beside the river
Translucent jelly over the arena floor beside the river1120×735 65.2 KB

Another renderer test scene, showing the floor through the jelly.

A performance fix worth sharing

One surprisingly expensive part was uploading unused space in preallocated geometry buffers. Reducing drawRange doesn’t reduce those uploads. Using BufferAttribute update ranges for just the active data, and leaving empty buffers alone, cut uploads from about 6.7 MB to 77 kB per frame in one fixed 32-jelly test scene with empty wakes. Draw calls and triangle counts stayed the same. That’s a controlled renderer measurement, not a general FPS claim.

Multiplayer runs on an authoritative server at 30 Hz, sending snapshots at 15 Hz. The client predicts your own movement and interpolates the other players, so the animation isn’t tied to the snapshot rate.

I’ve been building this with a lot of help from Codex, and doing plenty of playtesting and visual tweaking along the way.

I’d love some eyes on the material and motion: does it read as jelly on your screen, and are the trails easy to judge when things get busy? If you try it on a phone, the model and browser would be useful too.