Here is a complete 2D game written in React. Move with WASD. Renders in a browser. The whole thing is around 40 lines.

import { useRef, useEffect } from "react";
import { Game, World, Actor } from "@carverjs/core/components";
import { useGameLoop, useInput } from "@carverjs/core/hooks";
import { useGameStore } from "@carverjs/core/store";
import type { Group } from "@carverjs/core/types";

function Player() {
  const ref = useRef<Group>(null);
  const setPhase = useGameStore((s) => s.setPhase);
  const { getAxis } = useInput();

  useEffect(() => {
    setPhase("playing");
  }, [setPhase]);

  useGameLoop((dt) => {
    if (!ref.current) return;
    ref.current.position.x += getAxis("KeyA", "KeyD") * 5 * dt;
    ref.current.position.y += getAxis("KeyS", "KeyW") * 5 * dt;
  });

  return (
    <Actor
      ref={ref}
      type="primitive"
      shape="circle"
      color="royalblue"
      geometryArgs={[0.5, 24]}
    />
  );
}

export default function App() {
  return (
    <Game mode="2d">
      <World>
        <Player />
      </World>
    </Game>
  );
}

That is CarverJS. It is a React game engine I just published to npm in early beta. Free, MIT, version 0.0.1 at the time of this post, with two packages: @carverjs/core and @carverjs/multiplayer. The API will move before it hits 1.0.

This post is the long version of why I built it, what it actually does, and what is still half-finished. If you have ever closed a game-dev tutorial because step one was "install Unity," this one is for you.

Why I built it

The honest answer: I needed it for my own product.

I run a small edtech company. We are building game-based learning for K-12 students. Two products: a B2B platform for schools (admin dashboards, teacher tooling, student experience) and a B2C marketplace. Every product surface eventually renders a game. The games are short, social, browser-based, often multiplayer.

I am a React developer. The rest of my team are React developers. Our admin portal, teacher app, marketing site, internal tools — every product surface is React, all the way down. The natural question was: can the games also be React?

The non-React paths I evaluated:

• Unity WebGL. Exports run 10-50 MB on average, multi-second cold loads, doesn't compose with React UI. Great engine for the wrong runtime.
• Phaser. Mature, deep 2D feature set, but you are back to imperative game loops. State lives outside React.
• Godot HTML5. Smaller than Unity, same composition problem. GDScript or C#, neither of which is the language we ship in.
• Raw Three.js / R3F. Excellent for 3D scenes. No game abstractions. You build your own input system, collision system, audio manager, scene manager, asset loader, and multiplayer layer.

Each option meant either learning a separate engine or rebuilding a stack of plumbing. I started writing the plumbing once, then twice, then realized I was writing a game engine. So I made it deliberate, pulled it out of the company monorepo, and open-sourced it.

That engine is CarverJS.

The mental model

CarverJS is built on top of React Three Fiber and Three.js, but in normal use you do not import from either. Every component, hook, type, and store you need ships from @carverjs/core and @carverjs/multiplayer. If you already know R3F, the API shape will feel familiar. If you do not, you can ship a game without ever learning what an <Object3D> is.

Components describe the world:

<Game mode="3d">
  <World physics={{ gravity: [0, -9.81, 0] }}>
    <Actor type="primitive" shape="box" position={[0, 0, 0]} />
    <Actor type="model" src="/hero.glb" animationName="run" position={[1, 0, 0]} />
    <Actor type="sprite" src="/coin.png" billboard position={[3, 0, 0]} />
  </World>
</Game>

Hooks drive behavior:

import { useRef } from "react";
import { Actor } from "@carverjs/core/components";
import { useGameLoop, useInput, useAudio } from "@carverjs/core/hooks";
import type { Group } from "@carverjs/core/types";

function Player() {
  const ref = useRef<Group>(null);
  const { isPressed, getAxis } = useInput({
    actions: { jump: ["Space"], shoot: ["KeyJ"] },
  });
  const { play } = useAudio({
    sounds: {
      jump: { src: "/jump.wav", channel: "sfx" },
      hit:  { src: "/hit.wav",  channel: "sfx" },
    },
  });

  useGameLoop((dt) => {
    if (!ref.current) return;
    ref.current.position.x += getAxis("KeyA", "KeyD") * 5 * dt;
    if (isPressed("Space")) play("jump");
  });

  return <Actor ref={ref} type="primitive" shape="capsule" />;
}

The components are not thin wrappers. <Game> mounts the entire game stack on the way in: WebGL renderer, lighting presets, audio system, input manager, collision manager, and a game loop with phase tracking (loading, playing, paused, gameover). <World> groups actors, sets up a default camera per mode, and optionally enables Rapier physics as a lazy-loaded peer dependency. <Actor> is a discriminated union over three rendering modes — 3D models (.glb/.gltf), sprites (with optional grid- or atlas-based animation), and code-generated primitives — sharing a common base of transform, event, and physics props.

Hooks then read from the singleton systems <Game> set up. useGameLoop is useFrame with phase awareness, fixed-timestep mode, four staged update slots (earlyUpdate, fixedUpdate, update, lateUpdate), and a max-delta cap so a backgrounded tab doesn't spiral the simulation. useInput reads from a centralized InputManager with action mapping. useCollision registers AABB / sphere / circle colliders without dragging in a physics engine. useAudio registers sounds, supports spatial audio, music crossfades, six volume channels, and audio sprites.

The thing I was hunting for, that no lower-level library gave me cleanly, was this: a place to write game logic that looks and feels like React component logic. No imperative boot file. No animation loop wired by hand. No scene-graph state living outside React. Mount a component, the game starts. Unmount it, it cleans itself up.

2D and 3D in the same engine

You change one prop:

<Game mode="2d">  // OrthographicCamera, no shadows, no environment, brighter ambient
<Game mode="3d">  // PerspectiveCamera, shadows, sky, environment, OrbitControls

The same <Actor> components work in both. A sprite in 3D mode billboards at the camera by default; in 2D mode it sits flat. Primitives become <mesh>es with the appropriate material. Models work in either mode, though most 2D games will not need them. Physics is mode-aware: in 2D, Z translation and X/Y rotation are auto-locked per actor so things stay on the plane.

This matters because most game projects do not get to pick "2D or 3D" cleanly. You build a 2D game and then realize the menu wants a parallax background with depth. You build a 3D game and then realize the HUD needs 2D widgets in world space. CarverJS gives you both in the same scene, with a <Camera> component that can override the defaults if you want full control of FOV, near/far, follow targets, or controls (orbit, map, pointerlock, none).

Multiplayer without a game server

This was the part I expected to be the hardest, and it turned out to be the part I am most glad to have built.

Multiplayer in CarverJS is peer-to-peer. One player is the host, all others are clients, and game traffic flows over WebRTC data channels. There is no game server in the architectural sense. The host is the server.

import { MultiplayerProvider } from "@carverjs/multiplayer";

<MultiplayerProvider appId="my-game">
  <Game mode="2d">
    <World>
      <Actor type="primitive" shape="circle" networked />
    </World>
  </Game>
</MultiplayerProvider>

That networked prop is the entire opt-in. The actor's transform now syncs to every connected peer at 20 Hz, with delta compression. Only changed properties go on the wire.

Peer discovery is serverless too. You bring your own signaling network:

• MQTT — default, free, zero-config. Uses public MQTT brokers. Good enough for prototyping and small games.
• Firebase RTDB — bring your own Firebase project for production. More reliable, more isolated, easy rules.
• Cloudflare TURN (or any TURN provider) — optional, for NAT traversal when peers behind restrictive networks cannot connect directly.

After signaling, all data flows directly between peers. No room state lives on a server you have to operate.

Sync modes are layered. You pick the one that fits the actor:

Different actors in the same game can use different modes. The player character can use prediction; the chest they are walking towards can use events; the moving platform under their feet can use snapshots. You configure it inline:

<Actor
  type="model"
  src="/player.glb"
  networked={{ sync: "prediction", owner: myPeerId, priority: 2 }}
/>

Host migration is handled. If the host disconnects, peers sort by ID and the lowest ID becomes the new host. State is preserved through the migration — clients hit a brief migrating connection state and resume.

There is a working multiplayer demo in the repo — examples/multiplayer-2d, a small game called Coin Chase. Two players on different machines, collecting coins in real time, using Firebase RTDB for signaling and Cloudflare TURN for NAT traversal. Clone the repo and run it locally with two browser windows pointed at it.

I want to be clear about scope: this is not trying to be Photon or Colyseus. It is a peer-to-peer layer that fits inside React, designed for small to medium multiplayer games — roughly 2 to 16 players, browser-based. The trade-off is that the host has to stay online for the game to continue smoothly. Migration helps but is not a replacement for an authoritative server when you actually need one.

For MoneyTales — small classroom games, friends playing quick rounds — this is exactly the right shape. For your shooter MMO, it is not.

What is in the box right now

@carverjs/core ships:

• <Game>, <World>, <Actor>, <Camera>, <AudioListener>
• <SceneManager> and <Scene> for stack-based scene navigation with fade and custom-shader transitions, lazy-loaded scenes via Suspense, and per-scene error boundaries
• <AssetLoader> and <LoadingScreen> for declarative asset preloading with retry, priority, progress, and groups
• <ParticleEmitter> with presets (fire, smoke, explosion, sparks, rain, snow, magic, confetti)
• useGameLoop, useInput, useCamera, useAnimation, useScene, useAssets, useTween, useParticles
• useCollision (AABB / sphere / circle, layer-based filtering, sensors, no physics engine required)
• useGridCollision (tile-based, O(1) lookups — perfect for Snake, tile RPGs, puzzles)
• usePhysics (Rapier, lazy-loaded peer dependency)
• useAudio (Web Audio with HTML5 fallback, spatial 3D audio, six volume channels, music crossfade, audio sprites, automatic AudioContext unlock)

@carverjs/multiplayer ships:

• <MultiplayerProvider>, <MultiplayerBridge> (the R3F context bridge, since <Canvas> runs its own reconciler)
• useMultiplayer, useLobby, useRoom, usePlayers, useHost
• WebRTC transport with reconnection, host migration, interest management, and network simulation tools (latency, jitter, drop) for testing

The whole thing is TypeScript-first. Every hook and component has full type definitions. The core bundle is under 200KB before your assets, which is the whole point — a Unity WebGL export of an equivalently small game starts in the tens of megabytes.

Three demo games are open-source in the repo:

• basic-2d — a minimal 2D scene with input
• basic-3d — a minimal 3D scene with a model and orbit controls
• multiplayer-2d — Coin Chase, the multiplayer demo above

You can run any of them with pnpm install && pnpm --filter @carverjs/example-basic-2d dev.

What CarverJS is not

This is a beta. Things will move before 1.0, and I want to be specific about scope.

• It is not Unity. Do not bring AAA pipelines, baked global illumination, complex animation graphs, or 50-MB asset budgets here. The engine is designed for browser-shaped games.
• It is not Phaser. Phaser is older, more battle-tested, and has a deeper 2D feature set, particularly for tile-based platformers. If you want a pure 2D engine that does not care about React, use Phaser. CarverJS is for the case where the game lives in a React app.
• It is not a managed multiplayer backend. No matchmaking service, no analytics, no auth, no "studio plan." Bring your own Firebase or any signaling network. Bring your own TURN if you need NAT traversal.
• The API will break. Minor versions will break things until 1.0. Pin your version. Read the changelog.

What CarverJS actually competes with is the version of "I will write my own game stack on top of R3F" that lives in your head when you start a side project. If that was the alternative, CarverJS will save you a lot of glue code.

What is next

The 1.0 milestone is roughly six months out. Between now and then:

• Stabilize the core hooks and prop shapes (no big API churn after 1.0)
• More multiplayer transports and a proper interest-management profile
• A managed signaling service for teams who do not want to operate their own — paid, optional, the engine itself stays free and MIT
• An asset marketplace for sprites, models, and audio packs, with most of the revenue going to creators
• More examples — a multiplayer platformer, a tile-based puzzle, a 3D space shooter

The signaling service and the marketplace are how the project funds itself. The engine is free and stays free.

Try it

pnpm add @carverjs/core
# or
npm install @carverjs/core

Clone the repo and play with the demo games:

git clone https://github.com/moneytales/carverjs.git
cd carverjs
pnpm install
pnpm build
pnpm --filter @carverjs/example-basic-2d dev

• Docs: docs.carverjs.dev
• GitHub: github.com/moneytales/carverjs
• Discord: discord.gg/5ymwfD4hYE
• npm: @carverjs/core, @carverjs/multiplayer

If you build something with it, send it to me — I want to see what you make. If something is broken, GitHub Issues is the right place. If something is rough, Discord is where the rough things get tracked.

Most game engines were built by C++ programmers for C++ programmers, with a web export bolted on later. CarverJS was built backwards: web first, React first, game logic written the way component logic is written. It is an opinion as much as a tool. If the opinion fits, you will like the tool.