If you want to know when/if I realise any of those features, I send a newsletter every friday with what's new: https://polygonjs.com/newsletter

And the type of project you're describing isn't my personal interest, so no need to share it with me. But I'm curious about tools you've used to control memory with just javascript. I know there are extensions or browser flags you can toggle on, but those still seemed cumbersome. That was one of the main reason that motivated the rewrite, and I find it a relief that I can now detect memory leaks in the test suite, or have an easy way to have arenas (and arenas of arenas) so many objects can be freed/recycled very quickly.

So if you have a good way to control/manage memory in js, I'd be curious to hear.

And you mention "webgpu webxr" as if those worked together, but isn't webxr completely decorrelated from the render api? Or do you mean threejs implementation where those might be intertwined? I assumed webxr would work equally well under webgl or webgpu, since my understanding is that it mostly provides camera projection matrices and ray hit functions. But it could be that my knowledge is out of date, since I haven't touched webxr in the last 2 years.

> But as my game’s story has increased to be hours long

For those situations, on most projects I work on, I create a specific control node, which allows changing the state to predefined scenarii, or saving your current state. This requires the SDK for now unfortunately. But this can then be used with or without the editor, and allows you to quickly change from one state to a completely different one with 1 click or hotkey. I found that's the kind of technique that replaced hot reload for me. This made sure that only the state is updated, which limits the chance of bugs due to side-effects. Now that I write this, I realise this needs a proper documentation, I'll work on that.

Sounds good!

Yeah so I have no sophisticated tools, just guessed calculations done mostly at run time (add up how much do gpu compressed textures should take for a model, mesh+blendshape memory estimates, other data structures). And obv for audio and animations just ensuring what’s not needed is never in memory and just knowing how much the biggest ones cost. To come up with an estimate of an upper bound and obv with lots of testing. ios safari doesn’t even publicly expose how much memory usage is allowed to a tab (and it changes) so really the final test is that stuff stops crashing. But my testing put the crash window between 500mb-1gb on an iphone pro. over 1gb usually guarantees a crash. Not really enough to make a proper game by today’s standards but hey they shipped gta san andreas at 32mb ram on ps2 so I’m sure I can push things further.

To answer your webxr webgpu question, no, it still doesn’t mostly work. If you’re interested in reading up on it:

https://github.com/immersive-web/WebXR-WebGPU-Binding/blob/m...

Post by a Chrome dev: https://toji.dev/2025/03/03/experimenting-with-webgpu-in-web...

Webxr webgpu attempts iirc some advanced reprojection for increasing FPS that takes into account the depth buffer. And vision pro at least today has some nausea inducing bugs around that for at least the official immersive web examples hosted on github.io. so its better if a depth texture isn’t supplied today. the fallback reprojection works better more smoothly.

For the story stuff, I have similar things setup in my project to essentially reload the game at a certain point in the story but still I personally find HMR to be much faster wherever possible.