So this port isn't a straight WASM port, you're saying they're running the Windows binary and translating the DirectX8 graphic commands over to WebGL..? Am I understanding correctly?
Unreal Engine 5 does support the web, albeit as a third party implementation (my company)
We spent the last several years building out a WebGPU RHI for UE5, along with tooling to make games load fast using asset streaming, while using less memory. We were recently featured by Gamesbeat.
You can read more about it below or check out our website:
Interesting. For your occlusion mapping variant, what engine is the game you're making with made with that you're implementing this for? Do you have Claude hooked up to Unity or Unreal?
Totally agreed. I'm building a Steam competitor, that's web-based (WebGPU/WASM) as well as cross-platform. Light on games atm, but the goal is to replicate over time virtually every feature Steam has to offer, as well as more. You can check out a preview of the portal here:
Thanks man, feel free me to DM me on X if you'd like to discuss further, I am planning to push the code to a repo seeing as Xonotic is an OSS game and requires any changes to also be open sourced. And a Playstation recomp implemented in WASM is interesting to think about!
Really exciting to see more games ported to WASM. For anyone interested, I just did a HN post detailing a port I spent the last 5 days on - Xonotic, an arena FPS. Includes a technical writeup too:
Hey HN! I've been using Claude Code a lot lately and got curious whether it could port a full open-source game to run in the browser. Xonotic (a fast open-source arena FPS, think Quake III / Unreal Tournament) seemed like a good candidate: it's built on the DarkPlaces engine (real C + OpenGL), ships gigabytes of assets, and has actual multiplayer.
It's fully playable in the browser, no install or plugins. Pick a map like g-23 to drop into a match against bots.
Some of the technical work I wanted to highlight that I/Claude focused on that went into making it actually fast:
- The engine runs off the main thread. DarkPlaces is compiled to WASM/WebGL2, but the whole engine runs on a worker via Emscripten's PROXY_TO_PTHREAD, with the WebGL context owned directly by the worker through an OffscreenCanvas (zero cross-thread GL dispatch). That let me remove Asyncify entirely — the payoff is a steady frame loop (~4 ms/frame, 99.8% of frames under 16 ms in a profiled match).
- GPU texture transcoding. Every texture is Basis Universal / KTX2, transcoded at load time to whatever compressed format your GPU supports (BC7 on desktop, etc). That took the texture set from ~5.3 GB of TGAs down to a few hundred MB on disk and cut GPU memory ~4×. Audio is re-encoded to Ogg Vorbis.
- Streamed on-demand filesystem. Nothing is bundled. The engine reads through a virtual filesystem backed by Cloudflare R2; only a tiny boot set loads upfront, then each map prefetches its working set in parallel and streams the rest as surfaces actually draw. A full map's assets dropped from ~2.3 GB to ~320 MB per session.
- SIMD. Built with -msimd128, so the math and skeletal-animation paths vectorize to wasm128.
- Hosting. Cloudflare R2 (zero egress) behind a Worker, with COOP/COEP headers for SharedArrayBuffer/threads. Assets are immutable-cached and the engine binary revalidates, so reloads are cheap.
Multiplayer is peer-to-peer. Click Host Game and you get a 6-character invite code; a friend enters it and you connect directly browser-to-browser over a WebRTC DataChannel (configured unreliable/unordered to match the engine's UDP netcode).
A tiny Cloudflare Worker only relays the one-time WebRTC handshake — once you're connected, no game traffic touches any server. I tested a real 1v1 between Edmonton and Bangkok and it held up across the Pacific.
Would love feedback, so please report any bugs or glitches here and I'll patch asap.
A playable 3D dungeon arena prototype built with Codex and GPT models. Codex handled the game architecture, TypeScript/Three.js implementation, combat systems, enemy encounters, HUD feedback, and GPT‑generated environment textures. Character models, character textures, and animations were created with third-party asset-generation tools
The game that this prompt generated looks pretty decent visually. A big part of this likely due to the fact the meshes were created using a seperate tool (probably meshy, tripo.ai, or similiar) and not generated by 5.5 itself.
It really seems like we could be at the dawn of a new era similiar to flash, where any gamer or hobbyist can generate game concepts quickly and instantly publish them to the web. Three.js in particular is really picking up as the primary way to design games with AI, in spite of the fact it's not even a game engine, just a web rendering library.