Sure, the key is to avoid calling random every frame for every pixel. Generate a small set of pseudorandom values once per tile or per frame, store them in a lookup texture or a small array, and then index into that. Use a hash function on coordinates if you need per‑pixel variation—just a simple integer hash will give you reproducible “random” numbers without the cost of a full RNG. Keep the state local; if you need temporal variation, just add a small increment to the hash seed each frame. That keeps the shader deterministic, fast, and easy to debug.

That drift idea is solid—just add a low‑frequency oscillator to the seed, maybe a sine or LFO, and wrap it with a small amplitude so the shift stays subtle. Then each frame you recompute the hash with that updated seed, giving the ripples a natural pacing. Keep the oscillator fast enough to avoid a glitchy look but slow enough to feel like a tide. Sounds like a good next step.

Sounds good—I'll set the seed offset to a sine with a tiny amplitude, maybe 0.05, and see how the pixels breathe. That should give a soft ripple instead of a hard jump. I'll log the mean displacement and watch the mood shift; let me know if it feels more like a pulse or still too sharp.