Estella: a WebAssembly 2D/3D game engine with an ECS TypeScript SDK

What Estella solves, and who it is actually for

Shipping one small game to a browser, a WeChat MiniGame, a playable ad and an app store normally means maintaining several renderers and build pipelines. Estella's pitch is that a single project covers all of them: the README lists web browsers, desktop, WeChat MiniGames, single-file playable ads, and native Android and iOS as outputs of one codebase. The audience is TypeScript developers who want engine-level rendering performance without leaving the language they already use, and who care about the Chinese mini-game market as much as the Western web.

The design choice that separates it from a typical JavaScript engine is where the work happens. The rendering pipeline is C++ compiled to WebAssembly rather than interpreted JavaScript, and on native platforms the same core is compiled ahead of time. The README states that the native mobile build is a real arm64 app rendering through an embedded Dawn with Metal or Vulkan, not a WebView wrapper. That is a meaningfully different performance envelope from wrapping a web build in a shell, and it is also the reason the toolchain is heavier than a pure npm package.

The ECS mechanism and the TypeScript SDK surface

Game logic is entity-component-system. You declare components with defineComponent, register systems with addSystem, and query the world with Query. Systems receive their dependencies as typed arguments: Res(Time) injects the frame time resource, and Query(Mut(LocalTransform), Speed) yields entities that have both a mutable transform and a Speed component. The README's example iterates that query and advances transform.position.x by speed.value * time.delta.

The Mut wrapper is the part worth noticing. It marks a component as written, which is the kind of annotation a data-oriented engine needs to schedule systems and keep storage cache-friendly. Commands is listed alongside defineSystem, defineComponent and Query as part of the SDK, which suggests deferred structural changes rather than mutating entity sets mid-iteration. The README does not spell out the scheduler's execution model or how systems are ordered, so if your game depends on precise system ordering you will need the documentation rather than the README.

Above the SDK sits a visual editor with a scene hierarchy, inspector and asset browser. The README frames this as an alternative to editing JSON by hand, and the editor is where entities and components are normally assembled before you write the systems that drive them.

Installing the editor and writing a first system

Estella does not install as an npm package for end users. The README says to download the editor for Windows or macOS from estellaengine.com, where it is served from the project's mirror and is always the newest release, and that every build is also on the GitHub releases page. Open the editor, click New Project, enter a name and a location, and create it. The result is a project with a default scene containing a Camera entity.

Game logic is TypeScript. The README's example imports from the esengine package and defines a Speed component plus one system that moves every entity carrying it:

import {
    defineComponent, defineSystem, addSystem,
    Query, Mut, Res, Time, LocalTransform
} from 'esengine';

const Speed = defineComponent('Speed', { value: 200 });

addSystem(defineSystem(
    [Res(Time), Query(Mut(LocalTransform), Speed)],
    (time, query) => {
        for (const [entity, transform, speed] of query) {
            transform.position.x += speed.value * time.delta;
        }
    }
));

After adding that file, press F5 in the editor to preview. The README does not describe a terminal command that runs the game outside the editor, so the editor is the entry point for preview and for export. If you prefer a command line, the repository's package.json defines build scripts such as `node build-tools/cli.js build -t web` and `node build-tools/cli.js build -t wechat`, but those live in the engine repository itself, not in a project the editor generates.

The editor as an MCP server, and what that changes

The editor exposes the Model Context Protocol with 65 tools, and the README says these are the same pipelines the UI itself calls. An external client such as Claude Code or Cursor can open projects, spawn entities through the same Create menu a human uses, edit component fields, enter play mode, take a screenshot and export the finished game. The editor also ships a built-in agent, so you can type a sentence without connecting anything external.

Two details matter more than the tool count. Both front doors drive one catalog, so the built-in agent and an external MCP client have the same capabilities. And both go through the editor's command surface, which means creates are undoable and you can take the mouse back mid-turn. That is a deliberate answer to the usual problem with letting an agent drive a GUI: if the agent bypasses the command layer, its edits become unreviewable and unrevertible. Whether the agent produces good scenes is a separate question the README does not address.

Where Estella is the wrong choice

The licence boundary is the first limit. The repository covers the engine runtime, the SDK, the asset pipeline, the CLI, the project templates and the editor plugin API under Apache-2.0. The visual editor is a separate product, free to download and built on the engine, but its source lives in a private repository. If your organisation requires that every tool in the pipeline be open source, Estella's editor fails that test even though the runtime passes it.

Spine is the second limit, and it is a licensing rather than a technical one. The bundled Spine runtimes under third_party are not open source, and the README states that shipping a game using Estella's Spine integration requires a valid Spine licence from Esoteric Software, independent of Estella's Apache-2.0 licence. A team that needs skeletal animation but has no Spine licence cannot simply use the built-in integration.

Version maturity is the third. The repository's package.json reads 0.66.0 while the most recent release listed is v0.59.0, and releases arrive days apart. A 0.x project with that cadence is a moving target: the README does not promise API stability, and VERSIONING.md is where the project's own policy would be. If you need an engine whose API you can freeze for a multi-year title, this is not that engine yet. The last push to the repository was on 2026-08-28.

How Estella differs from Godot and Cocos Creator

Godot is the closest comparison in scope: a general engine with a visual editor, 2D and 3D, and exports to desktop, web and mobile. The difference is the authoring language and the runtime. Godot's editor and engine are open source under the MIT licence, and gameplay code is typically GDScript, C# or C++. Estella keeps the editor closed and the gameplay language TypeScript, and runs its rendering core as WebAssembly on the web. If you want the whole stack under a permissive licence, Godot wins on that axis alone.

Cocos Creator is closer to Estella's actual market. It is also a TypeScript engine with a visual editor and first-class WeChat MiniGame export. Estella's stated differentiator is the C++ core compiled to WebAssembly rather than an interpreted JavaScript pipeline, plus the MCP integration that lets an agent drive the editor. Cocos Creator's editor is likewise not distributed as open source. The practical question between them is ecosystem and support rather than language, since both ask you to write TypeScript against an editor-centric workflow.

Licence terms and what upgrading costs you

The repository is Apache-2.0, and the README is explicit that you may use, modify and distribute it for any purpose including commercial use, free of charge, with no separate commercial licence and no noncommercial restriction. The project follows Semantic Versioning and keeps a CHANGELOG. Two carve-outs sit on top: the Estella and ESEngine names and logos are trademarks that Apache-2.0 does not grant, so a fork should not ship under the Estella name or imply endorsement, and the Spine runtimes carry their own terms as described above. This is a description of what the README says, not legal advice; your own counsel should read LICENSE and NOTICE.

The upgrade cost is the release cadence. With versions landing days apart, a project that pins an editor build and an engine version will drift from the documentation quickly. The repository's own package.json carries scripts such as `verify`, `gate` and `perf`, which suggests the maintainers run release gates internally, but nothing in the README promises that a project created in one editor version opens cleanly in the next. The CHANGELOG is the place to check before moving a shipped title forward.

Editorial conclusion

Estella fits teams that already write TypeScript, want one project exported to web, WeChat MiniGames, playable ads and native Android or iOS, and are comfortable with a 0.x version that ships releases weekly. It is a poor fit if you need a fully open source editor, a permissive Spine licence, or a stable API you can freeze for years. Before committing, verify three things on your own machine: that the editor download from estellaengine.com runs on your OS, that your Spine licence covers the third_party runtimes you would ship, and that the version in package.json matches the release you actually installed.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes