u/Ok_Project_477

Hi everyone,

Not trying to promote anything, I just want the honest read from people who have actually built engine internals, because that is not really my background and I am not confident I got the structure right.

The engine is CarverJS, it runs on top of Three.js, and the whole thing is free and MIT licensed with nothing gated, so I have nothing to sell you here, I am only after the criticism.

Right now it is set up so that every system has its own manager, one for input, one for physics, one for audio, collisions, scenes, and so on, and each manager is a singleton that gets mounted once and runs inside the per frame update. Then on top of each manager sits a hook, and the idea is that your actual game code only ever touches the hook, so you call useInput or usePhysics and never poke at the manager underneath. So the manager does the real work and the hook is just a thin layer sitting over it.

The part I keep flip flopping on is input. The browser events get queued up as they arrive, and then the manager runs through all of them at one fixed point before any game logic happens, so during a single frame your input never shifts halfway through no matter when the event actually fired. That made the per frame code way easier to reason about, but it also means every input is basically one frame late, and I honestly cannot tell if that is a fair price to pay, or if most engine people would just read the events as they come in and handle the ordering themselves.

The bigger thing I am unsure about is whether having a manager layer and a hook layer at all is a good call, or if I have just turned one thing into two. If you have built your own engine and kept the systems more together than this, or gone the other way and split them up even more, I would genuinely rather hear why that worked for you than hear anything good about mine. It is all still really early, this is v0.0.3, so now is the time for someone to tell me the whole structure is wrong.

Hi everyone,

Not trying to promote anything here, just want honest feedback from people who understand render loops and WebGL far better than I do.

I have been building a free, open source, MIT licensed React game engine called CarverJS. It sits on top of Three.js and react three fiber, and my main hook for per frame logic runs in stages with priority ordering, something like an early update for input, a fixed update for physics, a general update stage, and a late update stage for camera and UI syncing. After all of that runs, react three fiber renders the scene automatically.

For anything that needs to be deterministic, like physics, I run it on a fixed timestep accumulator at a fixed rate instead of tying it to the raw frame delta. I also cap the maximum delta value so that if someone switches tabs and comes back, the simulation does not try to catch up all at once and spiral out of control.

What I am unsure about is whether staging updates by priority like this is actually the right mental model, or if I am overcomplicating something that could be simpler. I am also not sure if leaning on the renderer to auto render after my update stages is the right call, versus controlling the render step myself.

Everything here is completely free, open source, and MIT licensed, there is no paid version or hidden catch, I am just trying to figure out if the underlying approach holds up. If any of you have built your own game loops on top of WebGL or Three.js, I would like to know if this priority staged, fixed timestep approach is reasonable, or if there is an obvious mistake I am not seeing. Genuinely looking for criticism, not reassurance.

Hi everyone,

Not trying to promote anything here, just want opinions from people who actually work with WebRTC regularly, since most of what I learned putting this together came from reading old threads in this sub.

I built a multiplayer package for a React game engine called CarverJS. It uses a peer to peer mesh over WebRTC instead of a relay or dedicated game server. One peer acts as host, the rest sync to them, and signaling is free by default through public MQTT brokers, or your own Firebase project if you want more control. Everything is open source and MIT licensed, completely free, no paid signaling tier or anything like that.

The part I am least confident about is host migration. Right now, if the host disconnects, a new host gets elected and the room reloads from a snapshot in under 2 seconds. I have only tested this on small local networks with friends. I have no real data on how this behaves with a mesh of more than four or five peers, or what happens to migration time once you are dealing with asymmetric connection quality across peers.

STUN alone has not been enough for every network I tested on, so I ended up needing a TURN server for anything outside a friendly NAT. If any of you have run mesh topologies at a larger peer count, I would like to know whether you would have gone with a different topology entirely, like a selective forwarding approach, once the peer count grows.

Genuinely looking for the parts I got wrong here, not compliments. If mesh topology is a bad choice past a certain peer count, I would rather hear that now.

Hi r/react,

This is not meant to be a promotional post, I am mainly looking for opinions from people who spend all day writing React about whether this API actually makes sense outside my own head.

The project is CarverJS. It is free, open source, and MIT licensed, so there is nothing to buy and nothing to sign up for to try it. The core idea is that a game scene is just a tree of components, and the actual behavior, movement, physics, audio, camera, comes from hooks you call inside your own components, similar to how you would build any other React app.

I went this route because most game engines that try to work with React just wrap an existing engine loosely, and you end up dropping back into an imperative escape hatch constantly. I wanted the escape hatch to not be needed for common things, at the cost of maybe making unusual things harder. I am honestly not sure that trade was worth it.

There is also a multiplayer package that runs peer to peer instead of needing a server, but I do not want to make this post about a feature list. What I actually want to know is whether describing a game as components and hooks feels natural to you as a React developer, or whether it feels forced, like I bent React into a shape it was not meant to hold.

If you have tried other React game libraries before and switched away from them, I would really like to know why, that is more useful to me than anything positive anyone could say about mine. Whatever the answer is, the project stays free and MIT licensed either way, I am not trying to upsell anyone into anything, I just want to know if the core idea holds up.

Hey r/threejs,

I have been building CarverJS, a React engine that sits on top of Three.js, components describe the scene, hooks handle the logic. Everything, the engine and the multiplayer package, is completely free and MIT licensed, no paid tier, nothing gated. The part I want feedback on today is the multiplayer layer, since that is the piece with the least prior art to copy from, and honestly the part I am least sure I got right.

It is peer to peer over WebRTC, not client-server, so there is no server for you to host or pay for either. One peer becomes host, everyone else syncs to them. Signaling is free by default too, public MQTT brokers, or your own Firebase project if you would rather run it yourself. Sync is not one size fits all, you pick it per actor: events for turn based games, snapshots at around 20hz for RPGs, or prediction with rollback at around 60hz for fast action, and you can mix all three in one game. If you have built multiplayer before and think this is the wrong mental model, I would genuinely like to hear it.

The part I am proud of: if the host drops, a new host gets elected and the room reloads from a full snapshot in under 2 seconds, no restart, no data loss. I have only tested this with small groups of friends on the same network. I genuinely do not know what happens with a bigger room, bad connections, or someone yanking their wifi mid session, so if that is your area, please tell me where you think this breaks, that kind of pushback is worth more to me than any star or upvote.

What it is not: proven at scale, this is v0.0.3 with a small team behind it. Not a replacement for a dedicated server if you need authoritative anti-cheat. Not tested across CGNAT or corporate firewalls without a TURN server, STUN alone will not always get you there. If you can see a failure case I have not thought of, I would rather hear it now.

Again, the whole thing is free and open source under MIT, fork it, use it commercially, take it apart, whatever you want, no strings attached. What I am actually looking for from this post is not stars, it is honest opinions. Where do you think peer-to-peer breaks down for browser games, and what would make you trust something like this enough to use it yourself?

Everyone’s been one-shotting single-player Minecraft clones with Claude lately. I wanted to know what happens if you raise the bar: multiplayer, real P2P networking, infinite terrain, running in a browser.

Background: I’m the developer of CarverJS, an open-source game engine that sits on top of Three.js/React (so yes, this is my engine. Happy to answer anything about it). The bet was that AI one-shots fail at multiplayer because netcode is the hard part, but if the engine provides lobbies, host election, and WebRTC data channels out of the box, the AI only has to write the game.

So I gave Claude one prompt. ~2 hours later:
- 3,400 lines, 24 files, zero written by me (I was in fact sleeping)
- Infinite voxel terrain streaming in chunks as you walk, generated from a shared seed
- Real P2P multiplayer over WebRTC. No game server, world syncs as seed + edit log, host migration included
- Procedural textures and synthesized audio, zero asset files
- It verified itself by launching two headless browsers and asserting block edits replicated between them

The part I didn’t expect: while testing, it found a couple of bugs in my engine’s networking layer as well. So, I just had to update and fix those changes in my library and update the game code ever so slightly to take into account the fixes.

Total: 1.1M generated tokens.

Demo is playable in the browser, two tabs or two devices. Links in the first comment. Brutal feedback welcome, especially from anyone who tries it with a friend.

We are a team of two 22M Software Engineers with CS degrees from IITJ, working on a couple of products. We are based in Ahmedabad. Both of us are technically solid but not so much on the sales side. We have one product launched already with around 10-15 customers and 2 paid customers. The only marketing technique that we are focusing on right now is SEO. We have no Sales pipeline, no social media presence except from occasional posts that we do and no blog content published (only 3 as of now). The product is an API/MCP server as a service. We are looking for someone to take over the marketing, sales and cold outreach as well as social media for this product mainly, and help us with the GTM strategy as well. The problem with us is that while we are working full time on our products, we do not have jobs and not enough revenue that we can hire someone. So we are looking for a co-founder who would be willing to work with us in exchange of equity (sadly we cannot offer cash component to anyone at this point)

Please know that we are looking for full time co-founder who can preferably come to the office and work with us. We have had issues earlier with a co-founder who left because of commitment issues and so we prefer to work full time in person atleast at this stage for the co-founders.

P.S We are in the process of also launching one other product, which is a marketplace and we would need to figure out the GTM and Marketing part for that product soon as well.