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.

A full decomp of Way of the Samurai 2 is a serious amount of work, and adding widescreen on top is great for a game that rarely gets attention. How did you handle the fps unlock? Old PS2 titles often tie physics or animation timing to the frame rate. Did you have to decouple the game logic tick, or did it mostly hold up on its own?

Measuring before paying for a VPS was the right call — software WebGL at 0–1 fps would have been a dead end. Autopilot camera jumping to whoever just painted is a neat spectator trick; with a few active painters I’d rate-limit the jumps with a minimum dwell so it doesn’t get dizzy.

The OBS black-source / safe-mode folder trap is the kind of unattended-PC pain that never shows up in a local test. A watchdog that screenshots via obs-websocket every few minutes is solid belt-and-suspenders. Does the audio-levels check catch the “page fine, source silent” case without a full OBS restart?

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.

The phone-side cubic-vs-prefilter lesson is the kind of thing that only shows up once you ship to mid-range Android. Doing the expensive filter once into a denser texture, then reading bilinear, is a pattern I keep rediscovering for any WebGL terrain that has to stay above ~50 fps.

Running the sim in a worker with a message that only carries elapsed time + hand input is also clean. Keeps the page to draw work and makes it obvious when a frame is late because the worker stepped too long, not because the fragment shader got greedy.

Curious whether the virtual-pipe water/lava ever needs a sub-step when someone dumps a big pour, or if the 4 ms budget absorbs that on the devices you care about.

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.

Congrats on getting close to wrapping up a project you’ve been on for months. That last stretch is usually the hardest part. When you watch the playthrough back, what’s still bugging you most: enemy readability, weapon feel, or pacing between waves? I’d also love to hear what you cut to get it finished, since that’s often the most useful part for other solo devs.

Starting as a guest with no download is the right call for a browser game. The question I’d test is how quickly you get to the first catch. If account creation or long dialogue comes before that, it’s where browser players drop off.

Physical-yet-arcadey is such a hard balance. Curious about the Mario Kart observation. Was it about drift being a commitment the player enters on purpose, rather than something that emerges from the tire model? That framing changed how I think about steering assists.

Tried it for a minute on desktop. Standing still already got me to 12 with all 3 hearts, because a lot of fruit drops straight onto the basket, so the opening does not feel too hard. Dragging the ball with the mouse never moved the cat, so the rule about falling if you drag too fast or reverse never came up. If that rule is the real difficulty, it needs to show up earlier, and a visible tilt before you lose a life would help people learn it. Also worth checking that mouse drag moves the ball the same way a finger does, or desktop players cannot actually test the hard part.