Deki Engine is a C++ 2D game engine for microcontrollers with a Unity-style visual editor, and on 24 October 2026 every one of its 37 repositories pushed on the same day.
The editor tour above was uploaded on 12 October 2026. The workflow it shows is the pitch: build scenes visually from sprites, text, particles, tilemaps, state machines and tweens; pick a board in the editor’s Build panel; flash it. The same project also runs on desktop through SDL3, or headless with no renderer at all.
Reported performance is 60 FPS on an ESP32-S3.
The licence check, because it is the whole question with a 37-repository project
A modular engine split across dozens of repositories is a licensing trap. “It’s Apache 2.0” is a claim about one repository, and the thing you ship depends on twenty. So we enumerated the entire dekiengine organisation through the GitHub API and read the SPDX identifier on every repo.
35 of 37 are Apache-2.0. The two that are not:
dekiengine/.github— the organisation profile. Nothing to license.dekiengine/deki-demo— no licence.
The second one is worth a sentence. An unlicensed repository is, by default, not grantable for reuse: public does not mean permissive. And of all 37, the demo is the one a newcomer opens, copies a scene out of, and builds their first project from. The engine is cleanly licensed; the on-ramp is not. It is a one-line fix, and almost certainly an oversight rather than a decision, but until it is fixed, treat anything you lift from deki-demo as off-limits.
That result is the opposite of the one we got from Gradium’s Phonon family, where “Apache-2.0” turned out to describe one model in seven. Enumerate the namespace; do not read the headline repo.
The architecture
The runtime repository, deki-engine, created 3 July 2025, describes itself as
a C++23 2D engine for ESP32-S3 devices and desktop: a software rasterizer (RGB565 by default), a component model driven by C++26 static-reflection codegen, an asset system, and the provider interfaces that packages implement (display, input, render system, memory, filesystem, time, power).
Everything else is a package. Rendering, 2D content, input and every hardware integration live in their own repositories, and there is a module registry (dekiengine/registry) to resolve them. The engine repository is “only the part every project shares”.
The spread of modules is the clearest signal that this is not a weekend project: deki-2d, deki-rendering, deki-input, deki-tween, deki-particles, deki-audio (MAX98357A I²S amplifier), deki-fsm (“PlayMaker-style state machines … authored as a node graph”), deki-nodegraph, deki-tiledmapeditor-integration (loads Tiled .tmj maps with chunk streaming), plus peripheral interfaces for I²C, I²S, SPI, UART, GPIO, SD card, RTC (DS3231), IMU (LSM6DS3), GPS (NMEA over UART), WiFi, BLE, HTTP, and deki-lora (an SX1262 driver “with a duty-cycle limit”). There is a deki-3d, flagged experimental: a software-rasterised tiled renderer with .obj import that runs as a render pass.
Two repositories created as recently as 23 October — deki-display and deki-spi — suggest the project is in the middle of replacing its display stack with its own, having previously leaned on LovyanGFX (deki-lovyangfx-integration is still there).
C++26 reflection on a microcontroller
The component model is the unusual engineering choice. A component is declared by deriving from one class, and fields are exposed with macros that read almost exactly like Unity’s attributes:
DEKI_CATEGORY("Game")
DEKI_DESCRIPTION("Moves the object along X at a constant speed.")
class Mover : public Deki::Component
{
public:
DEKI_EXPORT DEKI_RANGE(0, 10)
float speed = 1.0f;
void Update() override;
};
From that, a codegen step emits the deserialiser, the field table, a DeclaresUpdate() query and — under DEKI_EDITOR — the inspector metadata. The README names the toolchain required: GCC 16 with -freflection, using C++26 static reflection.
That is a bold dependency for an embedded project. It also produces a sharp gotcha the README states outright: reflected member names are the keys in scene files, so renaming a variable is a file-format change. There is a macro for it, DEKI_RENAMED_FROM, and a COMPATIBILITY.md documenting migrations.
Honest about its maturity
The status line is 0.x: “File formats and the reflection ABI are versioned and may still change before 1.0, with a migration path for every breaking change.”
And the traction is small. The runtime has 9 stars; most packages have one or zero. This is an obscure project, and we are not going to inflate it — but obscure is not the same as unserious. The runtime dates from July 2025, the editor from November 2025, the bulk of the modules from April 2026, and there are generated reference docs at dekiengine.github.io/docs/.
Boards
Currently optimised for ESP32 platforms, specifically the LilyGO T-Deck Plus and T-Display S3 AMOLED, with the Elecrow CrowPanel Advanced 7” ESP32-P4 listed as coming. The T-Deck Plus package covers display, touch, keyboard, trackball, SD card, GPS and LoRa (SX1262) — which is to say the T-Deck’s entire feature set, and a reasonable target for a handheld game.
The editor runs on Windows and Linux. The engine is built by the editor: it is the deki-engine/ submodule of deki-editor, so you clone the editor with --recurse-submodules and build firmware from the Build panel or with DekiEditor --build-firmware.
Sources
- dekiengine on GitHub
- deki-engine — the runtime
- Deki Engine documentation
- Deki Engine – ESP32 gets an open source Unity-style editor and C++ 2D game engine — CNX Software