hex-engine models 2D game objects as React-style components

Every game object is a function that calls hooks

hex-engine is a 2D game engine for the browser written in TypeScript, and the design goal is stated in the first line of the description: it is designed to feel similar to React. The example in the README shows what that means in practice. A component is a plain function, `MyComponent`, which pulls in behaviour through imported hooks:

import {
  useDraw,
  useUpdate,
  useNewComponent,
  SystemFont,
  Label,
} from "@hex-engine/2d";

export default function MyComponent() {
  const font = useNewComponent(() => SystemFont({ name: "Arial", size: 12 }));
  const label = useNewComponent(() => Label({ font }));

`useNewComponent` creates another component, in this case a font and a label, `useUpdate` registers a per frame callback that receives the frame delta, and `useDraw` registers a callback that receives the drawing context. The two are separate, so a component can update state without drawing, and draw without updating. The imports come from the `@hex-engine/2d` package, which is one of several published packages in the repository's workspace.

An ECS variant where components are composable functions

hex-engine implements a variant of the Entity-Component-System model, and the variant is the interesting part. The project describes the adaptation as making components radically composable, and the mechanism is that every component is a function, with components able to call special hook functions to define their behaviour in the engine. In a conventional ECS the data of an entity is a bag of components and the systems that read it are separate, which makes combining behaviour a matter of agreeing on a data layout. Here the behaviour and the data are the same object, so a component is composed by calling hooks in it. The inspiration list names React, Impact, Unity and LÖVE, which is a good description of the mixture: React's component model, Impact's browser-first 2D heritage, and the entity ideas from the wider game world. The trade-off is that you give up the ability to inspect an entity's raw data in a debugger, since the state lives in closures.

Canvas rendering, matter.js physics and indie tool support

The out of the box list is long enough to judge the scope. Rendering is 2D via the HTML5 Canvas API, with support for sprite sheets and animations. There are helpers for sound playback and synthesis, so audio can be generated rather than only played. Physics comes from matter.js rather than a bespoke implementation. Input covers mouse, keyboard and gamepad. And there is first class support for three tools that 2D indie developers already use: Aseprite for sprite art, Tiled for tile maps, and BMFont for bitmap fonts. On top of that the project ships a development inspector and a modern frontend code compilation pipeline, with a Babel based build in the repository to match. For a browser game, that combination removes the usual excuse for not shipping in a web page: the art pipeline is the one most 2D engines are weak on, and here it is a named feature.

A monorepo of eight workspaces, built with a shell script

The repository root is a private npm workspace with eight packages, and the layout tells you how the engine is decomposed: `packages/2d` for the canvas game parts, `packages/core` for the engine core, `packages/create` for project scaffolding, `packages/game` for the runtime, `packages/inspector` for the development inspector, plus `packages/integration-tests`, `packages/scripts` and `packages/website`. The root package.json is marked private, which is how a workspace root is normally set up, and the scripts show how the pieces move:

  "scripts": {
    "build": "./dev-scripts/build.sh",
    "watch": "./dev-scripts/watch.sh",
    "start": "npm run watch",
    "typecheck": "tsc --noEmit",
    "test": "npm run typecheck && npm run test-it",
  }

The build and watch modes are shell scripts under `dev-scripts/`, and there is an `in-docker.sh` at the root for running the toolchain in a container. The test command runs a type check first and then a custom runner that globs test files under `packages/*/src`, so a test lives next to the code it covers rather than in a separate directory.

Installation instructions live on the website, not in the README

The project documentation contains no install commands, and says so plainly: interested readers are pointed to the Hex Engine homepage at hex-engine.dev for installation and usage instructions. The repository itself carries the source of that website as `packages/website`, and the root package.json has scripts for building and deploying it, including a `build-website` script that changes into that package and builds it, and a separate `netlify` script that uses a `build-no-docker` variant. There is also a `packages/create` workspace, which is the conventional place for a project scaffolding tool in a monorepo of this shape. If you are evaluating the project, the practical sequence is to read the README for the design, then follow the website for how to start a project, since the README's only instruction for a new user is that link.

Work in progress, no releases, no licence file

Two facts in the repository metadata should shape any adoption decision. First, the README opens with a work in progress warning, and the author says plainly that it is far from done and hopes a community forms around it. That candour is welcome, but it also means the API surface described here is a moving target. There are no GitHub releases, so there is no versioned artefact to pin, and the last push to the repository was on 2026-09-13, with the repository not archived. Second, the repository root contains no LICENSE file and the project metadata records the licence as unknown, which means there is currently no stated permission set for using, modifying or redistributing the code. For a hobby project that is a matter of etiquette, and for anything commercial it is a blocker until the author picks a licence.

Editorial conclusion

Web developers who already write React and want to build a 2D game in the browser will find hex-engine's component and hook model the fastest way in, and the inspector plus Aseprite and Tiled support are the parts that will save the most time. It is the wrong tool for a commercial release today, because the repository is labelled work in progress, ships no tagged releases and has no licence file at all. Before you build on it, read the installation and usage instructions on hex-engine.dev, check that the component model covers the game you have in mind, and settle the licensing question with the author, since nothing in the repository grants permission to use the code.

Frequently asked questions

Official sources

1. Issues
2. README
3. suchipi/hex-engine on GitHub