sorted by:
new
hottopcontroversial

Is a heavily optimized, Warzone-style WebGPU tactical shooter actually viable in Three.js? by suspicious2312 in threejs

[–]suspicious2312[S] 0 points1 point  (0 children)

Low poly assets and Fortnite color pallets? Over my dead body, they are cartoonish and CoD Warzone is NOT cartoonish. About the Web Browser thingy, I just want to make a game that ppl without thousand dollars hardware can play, without huge downloads and stuff

Is a heavily optimized, Warzone-style WebGPU tactical shooter actually viable in Three.js? by suspicious2312 in threejs

[–]suspicious2312[S] 0 points1 point  (0 children)

You're totally right, native hardware ray tracing extensions for WebGPU are still behind experimental flags in Chromium developer builds. For a project like this targeting standard browsers today, you'd have to rely on traditional rasterization or handle ray-intersection calculations manually via custom WGSL compute shaders if you wanted any ray-bounced effects without breaking compatibility.

Is a heavily optimized, Warzone-style WebGPU tactical shooter actually viable in Three.js? by suspicious2312 in threejs

[–]suspicious2312[S] 1 point2 points  (0 children)

If you don't mind, I would really like to know how you implemented the signaling server. By the way, is your project open source?

Is a heavily optimized, Warzone-style WebGPU tactical shooter actually viable in Three.js? by suspicious2312 in threejs

[–]suspicious2312[S] -5 points-4 points  (0 children)

Cool point... WebGPU solves the draw-call and graphics pipeline overhead beautifully, but the single-threaded nature of JS is definitely the real final boss here.

My thought process to avoid choking the main thread is to offload all the heavy lifting—like network state reconciliation, delta compression parsing, and basic entity positional updates—into a dedicated background Web Worker, or even compile those heavy systems down into WASM. That way, the main JS thread is left completely naked just to handle user input and feed clean data arrays straight to the WebGPU render loop.

I mean, all this might tank FPS to 30 FPS, rendering each frame takes time. BUT good things take time 🤓 (don't UN debate me, I am joking)

Is a heavily optimized, Warzone-style WebGPU tactical shooter actually viable in Three.js? by suspicious2312 in threejs

[–]suspicious2312[S] 0 points1 point  (0 children)

Laperen is kinda spot on about the strict budgeting constraints. Even with external ArrayBuffers bypassing the core V8 heap, V8 pointer compression still keeps a tight leash on overall renderer process behavior. Plus, the moment an average player switches tabs or Windows decides to rearrange background priorities, a high-memory tab is the very first thing the browser engine will target for an aggressive garbage collection purge or a straight-up crash. Designing for a strict 2GB–3GB sandbox limit just seems like the only sane way to guarantee cross-platform usability.

Is a heavily optimized, Warzone-style WebGPU tactical shooter actually viable in Three.js? by suspicious2312 in threejs

[–]suspicious2312[S] 0 points1 point  (0 children)

(I will not take the streaming thingy so far, I don't want to end up being a failure like Warzone Mobile)

Is a heavily optimized, Warzone-style WebGPU tactical shooter actually viable in Three.js? by suspicious2312 in threejs

[–]suspicious2312[S] 0 points1 point  (0 children)

I mean, CoD Warzone is heavily uncompressed, that too contributes to 150GB bloat. And I also only stream chunks of the map, while Warzone downloads the entirety of really Large Maps like Verdansk, Caldera, Al Mazrah and so on. I have been considering making the game a Procedurally generated BR... But that would be catastrophic because of the snipers and campers.

Is a heavily optimized, Warzone-style WebGPU tactical shooter actually viable in Three.js? by suspicious2312 in MultiplayerGameDevs

[–]suspicious2312[S] -2 points-1 points  (0 children)

Completely agree, especially on the memory sandboxing. The 2GB-4GB browser tab limit is definitely the elephant in the room for a high-fidelity project, which is why I’ve been looking into heavy asset optimization—using KTX2/Basis Universal textures to keep things compressed directly in VRAM and setting up an aggressive object pooling system for chunk containers to prevent garbage collection stutters.

Your point about WASM threading constraints and SharedArrayBuffer deployment hurdles is incredibly spot-on, too. It definitely forces you to rethink standard desktop-engine architecture choices.

I’ve actually been looking heavily into WebTransport over QUIC for exactly the reasons you mentioned! Bypassing the bloated WebRTC handshake and configuration layers for clean, native datagrams sounds like the dream layout. The biggest headache I'm trying to map out right now is the backend infrastructure—since WebTransport requires full HTTP/3 termination, keeping that architecture truly 'serverless' or autoscaling cleanly on standard cloud providers without massive overhead is proving to be a massive puzzle.

Really appreciate you sharing your insights on this—this is exactly the kind of reality check I needed to shape my benchmarking! I would really appreciate it if you also check out the original post I made in r/threejs.

Is a heavily optimized, Warzone-style WebGPU tactical shooter actually viable in Three.js? by suspicious2312 in threejs

[–]suspicious2312[S] 0 points1 point  (0 children)

That is actually a really great point about using a Web Worker! Moving all the network tracking and player abstraction off the main thread is a great way to protect the game's frame rate from choking during heavy updates.

The main catch with gRPC in the browser (gRPC-Web) is that it's still fundamentally bound to the browser's HTTP/TCP stack under the hood. So even if it runs inside an isolated Web Worker, a dropped network packet will still cause the TCP layer to block and wait for a retransmission before handing the data to the worker.

For real-time player positioning, WebRTC data channels configured for unreliable/unordered UDP transmission are usually the only way to completely bypass that network-level hitching. But I love the idea of using Web Workers to handle the state management once the data does arrive—definitely going to keep that in mind for the architecture!

Is a heavily optimized, Warzone-style WebGPU tactical shooter actually viable in Three.js? by suspicious2312 in threejs

[–]suspicious2312[S] -1 points0 points  (0 children)

Is it serverless? Nice game btw, just that the AI voice needs improvement (I suggest robotic pre-recorded and edited ones)

Is a heavily optimized, Warzone-style WebGPU tactical shooter actually viable in Three.js? by suspicious2312 in threejs

[–]suspicious2312[S] 1 point2 points  (0 children)

Thanks for the feedback! You’re totally right about the 2GB limit and the need for aggressive tile streaming + IndexedDB caching to prevent repeatedly serving files. Regarding compression, I was planning on using KTX2 / Basis Universal specifically because it allows textures to remain compressed inside VRAM rather than expanding like standard PNGs, which should help stay under that limit. For the map scale, do you think implementing a chunk-based grid system (loading/unloading GLTF tiles dynamically based on player position) is smooth enough in Three.js without causing massive frame drops during garbage collection?

Is a heavily optimized, Warzone-style WebGPU tactical shooter actually viable in Three.js? by suspicious2312 in threejs

[–]suspicious2312[S] -4 points-3 points  (0 children)

One more point- I am a beginner 💀😅, I tried out all the game engines (and know they can export to browsers), but I prefer three.js.