Echo: a game engine that drops GameObjects for a NodeTree

The scene graph has no Entity, GameObject, Component or Prefab

Echo is a new game engine written in C++ that takes a deliberate position on scene structure. There is no Entity, no GameObject, no Component and no Prefab. The scene manager is built from Node and NodeTree and nothing else.

That is a bigger departure than it sounds, because most engine conventions hide inside those four words. A GameObject is a container, a Component is behaviour attached to it, and a Prefab is a serialised template of the pair. Remove them and you are left with a plain node that holds properties, and a tree that holds nodes. Everything else in the engine has to be rebuilt on top of that, which is the cost of the design, and also the reason the author describes the concept as simple and the workflow as efficient.

The audience is a developer who wants control over the scene representation rather than a template to fill in. It is a research-shaped engine in the sense that the whole scene model is the experiment.

The project is MIT licensed, the primary language is C++, and the repository is laid out like a game engine rather than a library, with an engine directory, an editor directory, an app directory, a tool directory, a tests directory, a thirdparty directory and a CMakeLists.txt at the root.

2D and 3D differ by camera and unit, not by node type

The claim about mixing 2D and 3D is specific enough to be checkable. Every node can be 2D or 3D, and the difference between the two is the camera and the unit the node uses. Switching a node from one to the other is therefore a change of two things rather than a migration to a different node type.

In an engine where the node type carries the dimensionality, a project that starts as 2D and later wants a 3D element has to bridge two systems, and the bridge usually ends up being a second scene. Echo avoids that by keeping one node type and moving the dimensional distinction into how the node is viewed and measured.

The consequences for a user are practical. A 2D sprite node and a 3D mesh node live in the same tree, can be parented to each other, and are affected by the same scene operations. A camera that renders in 3D can see a 2D node, and the unit system determines whether a distance means pixels or world units.

The engine also lists gltf 2.0, Vulkan, Metal, PBR and real time ray tracing among the industry standards it supports, and the example set includes a PBR test described as a gltf and light probe test, plus a force field effect built from a shader graph and a procedural sphere. Those examples are the best evidence of what the renderer actually does, and they live in a separate echo-examples repository.

Lua is the main language, and Scratch compiles down to it

Most work in Echo is done in Lua, and C++ is available when you need it. The node tree design is presented as the reason Lua logic is easier to write here, and the editor ships an embedded Lua editor and embedded documentation so code can be written inside the Echo editor rather than in an external IDE.

The more interesting choice is the second scripting path. Alongside Lua, the engine offers an embedded Scratch language as a main development tool, a visual script inspired by the Scratch project from MIT. The important detail is how it executes: in Echo, Scratch is based on Lua, and when the app runs it converts to Lua, with the stated goal that it merges well with the rest of the code and runs efficiently.

So the visual scripting is not a separate runtime and not an interpreter bolted on the side. It is a front end that produces Lua, which then runs on the same engine as your hand-written scripts. For a team with mixed skill levels that is a real design win, since both kinds of logic end up in one language and one runtime.

If you want a different scripting language, the README's answer is blunt: you can ask, or you can support it by modifying the C++ code directly. There is no documented plugin interface for adding a language, which is the boundary to keep in mind before planning around one.

Shaders as data flow graphs, and a frame pipeline you can configure

The editor treats visualisation as a first-class way to work. The shader editor is built as a data flow programming graph on top of the nodeeditor framework, and the stated rationale is that programming visualisation matters for non-programmers, making shader programming easier to understand rather than merely more convenient.

The examples show what that produces. A force field effect is a shader graph combined with a procedural sphere, and the Gaussian blur and zoom blur examples are shader graph plus procedural plane. So the graph is not decoration around a slider panel, it is how the effect is described.

The frame pipeline editor goes further and is explicitly marked as still developing. It is inspired by CI/CD pipelines, and the idea is that not only programmers but everyone can configure the engine's frame render process. The three options it offers are forward rendering, deferred shading, and Forward+ with tiled forward rendering, and the user picks according to their needs.

Borrowing the pipeline metaphor is a nice fit for a renderer, since a frame really is a sequence of passes. The risk is the one that comes with the metaphor, which is that a pipeline editor gives you the illusion of a stable contract for the frame graph while the underlying renderer is still moving. The developing label on that section is the honest signal to weigh.

Modules you can switch off, timelines, and property channels

Most of the engine's functionality is implemented as configurable modules, and the reasoning is about the shipped artifact rather than the editor. When you release your app, you choose the modules you actually need, which makes the app smaller and, in the project's wording, more efficiently running.

That is a sensible answer to the usual engine bloat problem, where a template project carries a physics module, an audio module and a particle system whether or not the game uses them. Turning them off is a release step, and it depends on the engine having implemented each feature as a separable module, which is a structural decision made early rather than a setting added later.

Two content features complete the picture. With Timeline you can animate anything: not only any object property such as a node, a setting or a resource, but also any object function, so a timeline entry can trigger behaviour rather than just move a value. Channel references let one property be computed from another, possibly on a different node, which duplicates values, makes values relative to each other, and has the engine update them automatically whenever they change.

The channel reference idea is the quietly powerful one. It replaces a lot of copy-and-paste tuning with a graph of dependencies, and it explains how a node tree with no components can still produce behaviour that used to require them.

Building from source, with the instructions in the wiki

There is no package manager step in the visible documentation, and no install command to copy. The README points to a wiki page titled how to compile Echo Engine from source code, and to a releases page for downloads and a separate echo-examples repository for sample projects.

The repository layout is the best available map of the build. CMakeLists.txt sits at the root, with the engine, editor, app, tool, tests and thirdparty directories as siblings. A thirdparty directory of that kind means some dependencies are vendored in the tree rather than fetched by a package manager, which affects how long a first build takes and whether a network connection is needed.

The app and editor directories are separate, and the editor ships an icon in a Resource/App.ico path, which suggests a desktop editor application rather than a command line tool. The build guide in the wiki is where the actual toolchain requirements, generator settings and build targets will be, so that page is the first thing to read before touching the code.

For a first look without building anything, the examples are the cheaper path. The listed set covers a build house game that uses the sprite node, Spine 2D animation, Live2D animation, the PBR gltf and light probe test, the force field effect, and the Gaussian and zoom blur shader graph examples.

A 2026 codebase with a 2020 release tag

The maintenance picture has an odd shape and it is worth stating plainly. The only release listed is 0.0.6-preview, published on 2020-10-14. The last push to the default branch, master, was on 2026-09-16. The repository is not archived.

So the code has moved a great deal since the last tagged build, and the download link in the README, which points at the releases page, leads to a preview from six years ago. For an engine, the binary is where most of the friction lies, since a new user normally wants a working editor to open rather than a source tree to compile, and the tagged artifact may not reflect years of later work.

The project also has no homepage of its own, and the documentation is a wiki plus the examples repository, so the quality of what you can learn about the engine depends on those pages rather than on a maintained site.

On the licence, Echo is MIT, which is permissive and lets you use, modify and redistribute the code with the notice retained. Nothing in the visible text adds conditions. If you pick the engine up, treat master as the source of truth and the 2020 tag as a historical artifact rather than as a distribution channel.

Editorial conclusion

Adopt Echo if you are a C++ developer who wants a scene graph without the entity, component and prefab machinery, and who is prepared to build from source with CMake and to live without tagged releases. Do not adopt it if you need a packaged engine with versioned downloads, an asset store, or a shader and pipeline toolchain that is finished rather than announced, since the frame pipeline editor is still marked as developing. Verify three things first: that the compile guide in the project wiki matches your toolchain, that the modules you need are actually implemented in the engine and thirdparty directories, and how you will consume binaries, given that the only release tag is 0.0.6-preview from 2020-10-14 while the last push was on 2026-09-16.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. timi-liuliang/echo on GitHub