Dora SSR: a game engine whose IDE runs on the target device

The architecture: the engine on the device, the IDE in the browser

Dora SSR is a cross-platform game engine that lives on the device your game runs on, a phone, a handheld or a desktop. Its built-in Web IDE opens in any browser on the same network, so you code, inspect and iterate against the real runtime instead of a detached preview, with an AI coding agent built in.

That first sentence is the whole design, and every other decision follows from it. The engine runs natively on Android, iOS, Windows, macOS, Linux and HarmonyOS. The IDE is not a separate application and not a desktop IDE connecting to a build server. It is a browser page talking to the engine that is already running on the device over the local network.

The three reasons the project gives for this arrangement are worth separating, because they are different in kind.

Develop against the real runtime. The engine runs on the target device and the browser is just a window onto it. What you edit is what runs, with no emulator, no export step and no detached preview. That eliminates the whole class of problem where a preview behaves differently from the device, which in game development is the problem that eats the most time.

A complete toolchain in the browser. The Web IDE covers project files, typed editing, completion, diagnostics and jump-to-definition, plus the built-in editors for animation, particles, physics, story scripts, Git and more. So the tooling that normally means installing a desktop IDE chain is in a browser tab.

An AI agent built into the engine. The Coding Agent brings LLM-assisted development into the Web IDE, with project skills, persistent memory, API lookup, safe edits, build checks, runtime validation and sub-agent delegation. The agent runs inside the engine rather than as an external tool, which is what makes runtime validation possible: the agent can change something and then check the result on the running game.

The second point about the agent is worth expanding, because it is unusual. The agent has persistent memory and project skills, which means it accumulates knowledge of your project across sessions rather than starting fresh. It can look up APIs, so it does not have to guess at the engine's surface. And it does sub-agent delegation, so a large task can be split into parallel pieces.

The project is by IppClub, the primary language is C++, and the topic tags name the languages involved: 2d-game-engine, cpp20, lua, rust, teal-lang, typescript and yuescript. The homepage is dora-ssr.net, the last push was on 2026-10-20, and the releases are v1.9.4 from that day, v1.9.3 from 2026-09-18 and v1.9.2 from 2026-08-07. There is an Open Atom Foundation incubation badge and a DeepWiki badge, and the community is on Discord and a QQ group.

The editors that come with it

The built-in editors are the part of the project that distinguishes it from a game engine with an IDE bolted on, and the range of them is the argument.

There is an animation editor for skeletal animation timelines and a particle editor for effects with live preview. A physics editor for shaping bodies and fixtures. A Yarn editor for story scripts and node graphs. A visual script editor where logic is written as connected nodes. A Spine preview for inspecting skeletal animation data. A Git client covering history, remotes and changes. And a runtime profiler with a debug console for performance and debugging.

The live preview in the particle editor and the runtime profiler are the two that matter most for the architecture. A particle editor that previews on the device means you can see the effect against the real scene, at the real frame rate, on the real device. And a profiler attached to the running game gives you the numbers for the device you are shipping to, which is not the same as the numbers from a desktop preview.

The visual script editor is the one that determines what kind of team the engine fits. Logic as connected nodes is accessible to people who do not write code, which widens who can work on a project considerably. It is also the component most likely to be contentious in a professional team, because visual scripting has a reputation for producing code that is hard to maintain, and the connected-node model is where that reputation comes from.

Also built in, beyond the eight above, is a TIC-80 editor, tile-map support, an Excel-to-database workflow, and Blockly for Scratch-style visual scripting. The TIC-80 and Blockly pieces suggest the project wants to be a place where people arrive from different backgrounds: retro Lua enthusiasts, spreadsheet-driven designers, and classroom learners.

The Excel-to-database workflow is the one that is quietly the most useful for production. Game data in a spreadsheet is how a lot of teams actually work, designers maintaining balance tables in Excel and the engine reading them at build time. Automating that import rather than asking designers to learn a new tool is a real saving.

The editors are all reachable from the same Web IDE, which means the common case of a game project, where one person tunes a particle effect while another adjusts a physics fixture while a third writes a story script, has all three happening in one place against one running instance of the game.

What the runtime actually does

The runtime capabilities list is long, and the organising principle is that the engine covers the whole pipeline rather than a subset of it.

Scenes and 3D cover tree-based 2D and 3D scenes, an approachable ECS module, cameras, materials, lighting, models, animation and 3D physics. The ECS is called approachable rather than fast, which is the interesting word choice, since an ECS in a game engine is usually sold on performance and here it is sold on being understandable.

2D production covers Spine2D, DragonBones, built-in skeletal animation, PlayRho physics, tile maps, particles and retro TIC-80 content. Two separate third-party skeletal animation formats supported alongside the built-in one is a compatibility decision worth noting, since studios that already have Spine assets are the ones who will care.

Graphics and media cover asynchronous asset loading, Ogg and Theora video, multi-format spatial audio, runtime shader compilation, Effekseer, NanoVG, ImGui and TrueType rendering. Runtime shader compilation is the item that separates an engine aimed at iteration from one aimed at shipping, because it means a shader change takes effect immediately rather than at build time.

UI and narrative cover CSS Flex layout, responsive TSX interfaces and Yarn Spinner story scripting. The CSS Flex layout is a real choice rather than a limitation, and it means designers who know web layout get a familiar model, and a responsive interface means the same TSX can describe a UI for a phone and for a handheld.

Data covers asynchronous SQLite access plus the Excel-to-database workflows. Asynchronous database access in a game engine is not trivial and is usually a sign the engine is prepared for the case where you want to query a large asset table without stalling the frame.

Game patterns cover reusable logic and AI support for 2D platformers, and a machine-learning gameplay framework. The platformer support is a template rather than a framework, but a template that is maintained by the engine is a template that stays working as the engine changes.

The screenshot in the README shows a 3D helmet model and asynchronous loading diagnostics, which is a useful pairing. The diagnostics view is the visible face of the asynchronous asset loading, and seeing the load progress rather than a frozen frame is exactly what you want when you are debugging why something did not appear.

Languages, and exporting to the web

The Languages section states the position clearly: write game code in the language your team already knows, they all drive the same engine APIs.

The language badges name Lua, TypeScript and more, and the topic tags add Teal and YueScript to the list, with Rust appearing in the tags as well. The primary language of the engine itself is C++, with the project targeting C++20. So the engine is a modern C++ codebase and the scripting layer is deliberately plural.

That plurality is the interesting design decision, and it works because the languages sit above a shared API surface rather than each getting its own binding. The README is emphatic that they all drive the same engine APIs, which means a Lua script and a TypeScript script can call the same engine functions in the same way, and moving a system from one to another is not a rewrite.

The corollary is that you have to choose a language, and the choice is not costless. A project that mixes Lua and TypeScript has two type systems, two sets of idioms and two sets of debugging experience, and the teams that write Lua and the teams that write TypeScript are often not the same people. The claim that they all drive the same APIs is true at the engine boundary and does not remove the differences above it.

The export path is the other half of the platform story. Finished games can also be exported to the web as WebAssembly builds that run in any browser from plain static hosting, like the games in the web gallery.

That is a significant capability, because it changes the deployment story for a mobile-first game. A game built for a phone can also be put on the web as a static site with no server, no runtime platform and no app store review. The gallery games are the proof that it works, and the fact that they are hosted as static builds rather than requiring a server is the point.

The combination of the two, a device-native engine with a browser IDE and a WebAssembly export, is what makes Dora SSR a coherent product rather than a collection of features. The same project file is edited on a laptop, runs on a phone, and ships to a browser.

The repository, and what the licence arrangement means

The repository layout is the usual shape for a game engine, and it maps onto the feature list.

There is `Source/` for the engine itself, `Assets/` for the shipped content, `Projects/` for the sample and template projects, `Studio/` which is the Web IDE, `Tools/` for the supporting tools, `Docs/` holding the documentation site and the images used in the README, and `skills/` which is presumably where the agent's project skills live. The build is driven by `xmake.lua`, so the engine builds with xmake rather than CMake.

The licence situation is worth reading carefully, and it is a two-part arrangement. The repository root carries a `LICENSE.txt`, a `NOTICE.txt`, and separately `LICENSES.3rdparty.md`. The third-party file is the notable one, because an engine that supports Spine2D, DragonBones, PlayRho, Effekseer, NanoVG, ImGui, Yarn Spinner and TIC-80 content is bundling a lot of other people's work, and a project that lists them separately is telling you it has thought about which licence applies to which.

The repository records the licence as one GitHub cannot classify, which is consistent with an engine that combines a project licence with per-dependency terms rather than a single standard one. The practical consequence for anyone shipping a game built on it is that they need to read those files rather than assume.

The contribution setup is also worth noting. There are two contributing documents, CONTRIBUTING.md and CONTRIBUTING.zh-CN.md, so the project expects contributions in both languages, and there is a DCO.txt, a Developer Certificate of Origin. A DCO means each commit carries a sign-off line asserting the right to contribute the code, which is the mechanism the Open Atom Foundation projects use and a lower bar than a full CLA.

The README itself is bilingual too, with an English version and a Chinese one at README.zh-CN.md, and the community channels include a QQ group alongside the Discord, which is a reasonable reflection of where the project's users are.

The documentation lives at dora-ssr.net with tutorial and example pages linked from the README, including an ECS tutorial, a platformer tutorial and a Yarn editor reference, and there is a DeepWiki badge for the AI-generated repository wiki, which is a convenience for reading a codebase of this size but not a substitute for the project's own docs.

Editorial conclusion

Adopt Dora SSR if you are building for phones or handhelds and want to edit the running game rather than a preview of it, since that is the architectural decision the engine is built around. Do not adopt it if you need a mature ecosystem of plugins, because the project is young and the language surface is still expanding, and check first which language you want to write in, because the engine drives the same APIs from several and picking the wrong one means working around the runtime you actually have.

Frequently asked questions

Official sources

1. IppClub/Dora-SSR on GitHub
2. Issues
3. Project website
4. README
5. Releases