warvstar

Thanks for the detailed report! We have recently received similar reports on M1 and M2 chips and we are going to investigate further.

Also, you're right about the loading screen for unsupported browsers, that is something we will add ASAP. Thanks again!

Any chance for multi agents and/or a vs-code extension(for diffing / applying changes)? nmv on the vscode extension, I just found your other comment.

It can be, we have our data cached as close to the user as possible, in over 300 locations. It does add some latency, because instead of a 3ms latency to fetch and decompress assets, it now might be 17ms. However, because we also have a memory cache, this can reduce that latency significantly, and we use that for as many small and recently accessed assets as possible. Our virtual fs is multithreaded and works in tandem with Unreals async loading threads, so we are able to fetch multiple assets at a time, reduce wait tune. We also have the ability to know what assets are commonly fetched in a certain period and to fetch those ahead of time.

Of course, if you combine bad networks, lack of storage capacity and large projects, you can be sitting around a while, or may not have the best experience. Keep in mind though, that the browsers don't usually evict data from the cache unless you've used up the storage quota, the system is under storage pressure, or the origin has not been accessed in a while. According to them

We have the ability to stream in content from our CDN, so even devices with little to no storage capacity can run games of near infinite size. The main issue in today's browsers is the 4gb ram limit, although many games can run within that limit. We have MEMORY64 support as well, removing that ram limit, but it will probably be a few months before some browsers enable MEMORY64 without having to use a flag.

That's actually the main thing we've worked on, WebGPU support is small potatoes compared to it, but I'm happy it's getting some attention here. We have an asset streaming system that enables you to stream in large, or near infinite size worlds at runtime, of course you still have to be smart about memory usage. We also have a server-side streaming solution that can be used as fallback, for constrained devices.

Not from the official source, but we (Wonder Interactive Inc.) have a custom version of the engine that compiles to wasm. We are looking to upstream to Epic, or at least have a plugin that doesn't require custom source.

No downloads and the ability to easily and quickly jump into the action, especially useful for multiplayer or social games.

100% agree and when WebGPU comes out, that's going to reduce performance differences by a ton.

We have a gaming platform where users can download and play full games in the browser. We don't use indexedDB though, we use the Cache API.

I assume that also includes the Cache API's Storage?

This makes me feel old, thanks for that.

Looks cool, tons of potential here!

Would love to add this to my game engine.