Nice that it’s all worklet-side. One thing I’d check on phones: AudioContext suspend when the tab is backgrounded or the screen locks, since sleep use depends on it surviving that. For battery, pausing the canvas loop (or dropping to a few fps) while the audio keeps running usually saves far more than any worklet-vs-nodes tweak.

Nice to see the XR jam back for another round. Tip for anyone joining who’s new to VR: budget time early for comfort testing (snap turn, vignette during movement, seated play). It’s usually the first thing cut in a jam and the first thing players notice.

Nice topic for a series. Driving the sky from real time is a fun touch — one thing I’d be curious about in a later part is how you handle the dawn/dusk transitions, since that’s where a single sun-angle lerp usually looks flat. Do you plan to tie ambient light / fog color into the same time value too?

Fun effect. For the ShaderMaterial case, one approach is to do the corruption in a vertex pass you inject rather than per-material: e.g. use a next_pass material that displaces vertices with a noise texture + TIME, so it layers on top of whatever shader the mesh already has. Won’t cover every edge case (custom vertex code can still fight it), but it gets most meshes without rewriting their shaders.

Love that the whole pass is hand-built. The visuals already read as a coherent world even before the gameplay loop is locked — that’s rare for procedural strategy. Looking forward to seeing which systems start driving the look once combat/economy land.

Cracked-glass as a tutorial topic is useful because the effect fails loudly when UVs or normals are wrong — easy to learn from. In a browser export I’ve had to watch overdraw on the shatter pass more than the look itself; once the shards fan out, fill-rate eats mid-range GPUs fast.

Curious whether the tutorial stays on a single draw call with a dissolve mask, or spawns mesh shards. The former has been kinder to web exports in my experience.

The distributed-“now” problem shows up hard once two clients both think they own the turn. Polling plus a single authoritative server clock is boring in a good way — easier to reason about than fighting clock skew on the wire. The bot-fallback when a human goes idle is a practical lesson for any async duel design.

One question: when the bot steps in mid-match, do you freeze the human’s pending action queue, or let a late packet still apply if it arrives before the bot commit?

Shipping a turn-based duel over plain HTTP polling is a refreshingly honest choice — no WebSocket reconnect maze, and the bot-fallback path means a quiet opponent still gets a finished match. Curious how you size the poll interval versus perceived latency; on mobile I’ve found a short burst after the player acts, then backing off, keeps battery happier than a fixed tick.

Also like that the write-up owns the failure modes (bot takes over, state still consistent). That’s the part most “I made a multiplayer game” posts skip.

Pulling Godot’s own WebGLTexture through texture_get_native_handle + GL.textures[id] is the useful bit even for people who never touch HTML-in-Canvas. Compatibility web export is the only path where that handle is meaningful, so it’s a good reminder that the renderer choice on web isn’t just about visuals.

Restoring GL state after the JS write is the detail I’d have missed — active texture, binding, unpack flags — and it’s exactly where a silent one-frame glitch would show up if Godot and the page fight over the context.

Agree this stays an experiment until Mozilla/WebKit move. Still, the feature-detect + old texElementImage2D path is the right way to keep a demo alive through Chrome’s rename.

Congrats on shipping a first Godot build. One thing that surprised me later: input timing in an HTML5 export can feel a beat later than the editor, so mid-air flips and short tap windows often need a tighter threshold than the desktop build. Worth checking early if you plan a browser demo.