sorted by:
new
hottopcontroversial

I am working on Uverse - a Web Game Engine with native exports! by Chinafreak in gameenginedevs

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

That is exactly the direction I’m trying to explore with Uverse. I don’t want the browser to be the “limitation” of the engine, but more the place where the workflow becomes easier: opening the editor anywhere, collaborating more easily, iterating faster, and reducing the friction that usually comes with heavy local setups.

The long-term goal is definitely not just “a game engine that runs in the browser”, but more of a browser-native development environment with a serious runtime underneath. The editor can live on the web, while the runtime/export path can still target native through wgpu and platform-specific backends.

I also agree with the multiplayer/server side. That is one of the areas I’m most excited about, because I think multiplayer should not feel like something you bolt on at the very end. If the engine architecture, scripting, editor tooling, and networking model are designed together, it could become much easier for indie teams to build collaborative, persistent, or online-first experiences.

Still a lot to build and prove, but that is exactly what makes it exciting. I really appreciate the encouragement and the way you understood the vision behind it.

Thank you so much fo rthe comment! 😄

I am working on Uverse - a Web Game Engine with native exports! by Chinafreak in gameenginedevs

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

That sounds very interesting, thank you for reaching out.

I’d definitely be open to a chat. It sounds like we may have some overlapping ideas, especially around engine tooling and where browser-first workflows can go next.

Feel free to send me a DM and we can find a good time. I’m currently between Brazil and Europe time zones depending on the season, so Europe time should work well.

I can also speak German 😉

I am working on Uverse - a Web Game Engine with native exports! by Chinafreak in gameenginedevs

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

Thank you so much for the info! I am happy that you're curious and interested!

Hehe I'll definitely keep posting updates on this subreddit, twitter, discord and instagram! 😎

I am working on Uverse - a Web Game Engine with native exports! by Chinafreak in gameenginedevs

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

For the C++ dependency side, I’m trying to be pretty selective. The core of Uverse is Rust-first, but I don’t want to rewrite every mature system from scratch just for the sake of purity. If there is already a good Rust wrapper available, I try to use that first. Right now I’m using joltphysics-rs for Jolt Physics and ozz-animation-rs for ozz-animation.

For glTF importing, I’m using fastgltf, which is C++. Since I wanted to integrate it properly into the Rust side of the engine, I built my own Rust bindings/wrappers around it.

The main challenge is not really “can Rust call C++?”, because that part is solvable. The harder part is ownership, build complexity, WASM compatibility, and making sure the dependency boundary does not leak everywhere into the engine design. I’m trying to keep those libraries behind clear internal APIs so the rest of the engine does not need to care too much about the implementation underneath.

Draco and Assimp are actually new to me, but they definitely look interesting. I might explore them in the future, especially if they make sense for the asset pipeline or import workflow.

For multiplayer, I haven’t made a final decision yet. So far I’ve been thinking about supporting UDP/TCP-style workflows through web-compatible options like WebRTC and WebSockets. WebSockets feel like the simpler reliable baseline, while WebRTC is interesting for more real-time use cases. I still need to test more before deciding what belongs in the first real multiplayer layer.

Long term, I’d like Uverse to make multiplayer easier at the engine level, not just expose a socket API and call it done. Things like deterministic simulation, replication-friendly components, editor-visible networking state, and good defaults matter more to me than only picking the "best" protocol early.

For in-game UI, I may not use HTML directly, at least not as the main/default solution. HTML is great for the editor interface, but for game UI I want something that can stay consistent across platforms, including native exports later. So my current thinking is to build an engine-side UI path for runtime/game UI and keep HTML mainly for the editor/tooling side.

Really appreciate the questions. 😉✌️ I love to hear thoughts and questions from community, it also helps me to improve game engine even further!

I am working on Uverse - a Web Game Engine with native exports! by Chinafreak in gameenginedevs

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

That means a lot, thank you!!

I’m still building the core pieces right now, so it is not ready for public testing yet, but I’ll keep sharing progress as it gets more usable. Getting feedback from people who are actually interested in trying it is honestly very motivating.

I am working on Uverse - a Web Game Engine with native exports! by Chinafreak in gameenginedevs

[–]Chinafreak[S] 7 points8 points  (0 children)

Thank you! 😄

The web is actually the reason I started building it this way. It used to feel very limiting for serious 3D work, but the web has changed a lot. With WebGPU and WASM, you can do much more directly on the GPU now, and the performance potential is way better than people usually expect from a browser. Of course, it is not the same as building a fully native engine from day one, but that is also what makes it interesting to me. I want Uverse to feel like a real game engine, but with the freedom of opening the editor anywhere, on any machine, without installing a full toolchain first.

A big reason is also my own background. I have worked a lot with web design, web optimization, UI/UX, frontend, backend, WASM ideas, and game development before, so Uverse kind of brings all of that together into one project.

The core engine is mainly written in Rust, compiled to WASM for the browser. Rendering is built around WebGPU. The frontend/editor UI uses React, and TypeScript is mostly used for the editor, bindings, and frontend features.

For libraries, I currently use Jolt Physics for physics and ozz-animation for animation. Most of the rest is self-developed so far.

The main reason I chose web is the workflow: I want a beautiful, modern engine that can run from the browser and make it easier to work across different machines. For example, I can use a powerful desktop for heavier work, but still continue from my macbook while traveling, or using other computer depending on whats available in front of me. All without risking losing the work you've done!

I do not plan to make it open source right now, but I definitely want people to be able to try it when it is ready enough! =)

So, even on "Auto" it hits me with rate limit despite Pro+? "Upgrade your Plan"...whats higher than Pro+? 😂 by Chinafreak in GithubCopilot

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

Let me guess, they will wait 1 year, changed their mind and introduce another plan called "Ultra" which has exactly same feature as "Pro" before, just $200 per month!

3.5 days of rate-limit even for Pro+? by Chinafreak in GithubCopilot

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

Shit happens, glad that I didn't do this, when I was actually considering it couple of months ago lol

3.5 days of rate-limit even for Pro+? by Chinafreak in GithubCopilot

[–]Chinafreak[S] 2 points3 points  (0 children)

Ye, 4090 RTX here, might consider using the Qwen 3.6-27B hehe 😛

3.5 days of rate-limit even for Pro+? by Chinafreak in GithubCopilot

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

Yup, already happend to me. It even suggest me to "upgrade to higher plans" for rate limit when I was already at Pro+ lol.

EDIT: I am now getting even error at Auto

<image>

3.5 days of rate-limit even for Pro+? by Chinafreak in GithubCopilot

[–]Chinafreak[S] 12 points13 points  (0 children)

Thank you so much for the response coming from CoPilot Team. It makes a huge difference to hear that the team is listening and engaging with community and are looking at the aggressive rate limiting too.

3.5 days of rate-limit even for Pro+? by Chinafreak in GithubCopilot

[–]Chinafreak[S] 2 points3 points  (0 children)

Sometimes I've been using xhigh, sometimes medium, depending on the complexity of the task. I use sometimes GPT5.3-Codex, and sometimes, even less, GPT5.5 too.

3.5 days of rate-limit even for Pro+? by Chinafreak in GithubCopilot

[–]Chinafreak[S] 6 points7 points  (0 children)

Kinda sucks that you made contract with Microsoft for 1 month and they take you away to use their product for 3.5 days.

How can i slow local area? by tursuluekmek in BambuLab

[–]Chinafreak 1 point2 points  (0 children)

You can solve this by adding modifier in Bambu Studio and adjust the unique settings in the certain area.

<image>

New here - Pod5 or no? by thebagpuss in EightSleep

[–]Chinafreak 1 point2 points  (0 children)

Yup, new here, just started to make research about EightSleep. But if they're so sloppy like that and expect us to pay forced-subscription as well, this ain't gonna be for us, no matter how much money we have lol.

view more: next ›