# GDevelop: a no-code game engine where the editor and the runtime live in one repository > GDevelop builds 2D, 3D and multiplayer games through an event-based system rather than a scripting language. The repository holds the editor, the TypeScript engine and the extension ecosystem, and the last push was on 2026-09-19. **4ian/GDevelop** — 🎮 Open-source, cross-platform 2D/3D/multiplayer game engine designed for everyone. - Repository: https://github.com/4ian/GDevelop - Website: https://gdevelop.io - Stars: 26,951 · Forks: 1,561 - Language: JavaScript - License: NOASSERTION - Published: 2026-09-21 · Updated: 2026-09-21 · Language: en - Canonical page: https://hysenlabs.com/projects/4ian-gdevelop ## What GDevelop solves, and for whom Most engines assume the person building the game writes code. GDevelop inverts that assumption. The README describes it as a "full-featured, no-code, open-source" game development software, and the primary interface is an event-based system with modular behaviors rather than a text editor for game logic. An event is a condition paired with actions: if the player collides with a coin, then play a sound and increment a variable. That structure is readable by someone who has never written a loop. The audience follows from that. The repository lists topics including no-code and game-maker, and the README's getting-started table points people who want to make games at the homepage download rather than at a build command. The same table separates four other audiences: extension authors, people contributing to the editor or engine, template and asset sellers, and translators working through Crowdin. Those are different products sharing one repository, and it is worth knowing which one you are in before you clone anything. Targets are mobile (iOS, Android), desktop and the web, in 2D, 3D and multiplayer. That breadth is a claim about output formats, not about the depth of any single one. ## Editor, engine and the GDevelop.js boundary The architecture table in the README splits the project into directories that map cleanly onto responsibilities. Core holds the classes that describe a game's structure and the tools that implement the IDE. GDJS is the game engine itself, written in TypeScript, using PixiJS and Three.js for 2D and 3D rendering over WebGL. newIDE is the editor, written in JavaScript with React, Electron, PixiJS and Three.js. Extensions holds built-in objects and behaviors, including physics engines running in WebAssembly (Box2D, or Jolt Physics for 3D). The interesting piece is GDevelop.js, described as bindings of Core, GDJS and Extensions to JavaScript with WebAssembly, used by the IDE. That is the seam that lets a React editor manipulate the same game model the runtime executes. Because the game description is data rather than generated code, the editor can round-trip a project without a compile step in between. It also means the editor is not a thin wrapper around a separate native toolchain; the same Core classes back both sides. The README points to Core/GDevelop-Architecture-Overview.md for more detail and to docs.gdevelop.io for pre-generated engine documentation. If you plan to touch engine internals rather than write extensions, read those two sources before the source tree. ## Installing GDevelop and opening a first project The README does not give install commands. Its getting-started table says plainly: to use GDevelop to make games, go to the GDevelop homepage to download the app. There is no package manager instruction, no build step, and no version number in the README, so treat the homepage as the only documented distribution channel for the editor. The one documented route into the code is for contributors. The table's entry for contributing to the editor or game engine points at newIDE/README.md, and the repository carries a .devcontainer directory and a .gitpod.yml, which is where a container-based setup would be described. That README is the file to open, not this one. If you are evaluating rather than contributing, the useful first step is a single event. Create an object, add an event with a condition and an action, and run the preview. The point of the exercise is to confirm the editor starts on your machine and that the preview renders, because every later decision depends on that loop working. ## Where GDevelop is the wrong tool The event system is the product, and it is also the ceiling. Logic that a programmer would express as a recursive algorithm, a custom spatial index or a bespoke network protocol does not map naturally onto condition-and-action pairs. The README's answer to that gap is extensions: it links a page on creating an extension, "with no-code or code". Extensions are the supported extension point. Rewriting the engine's rendering path is not. There is a second constraint in the language of the repository itself. The engine is TypeScript, the editor is JavaScript, and the physics libraries arrive compiled to WebAssembly. A team whose existing codebase, tooling and hiring are built around C# or C++ gains nothing from that stack; they would be adopting a runtime they cannot reuse. Finally, the repository is not only an engine. It is also an ecosystem and, per the README, online services and commercial support, with a pricing page for professionals, teams and individual creators. A team that needs a guaranteed support contract should read that page rather than infer support terms from the source licence. ## GDevelop against Godot and Unity The comparison people search for is GDevelop against Godot. The difference is where the logic lives. Godot expects a scripting language for game behaviour and a node tree as the scene model. GDevelop expects events and behaviors, with the game described as data that the editor and the runtime both understand through the GDevelop.js bindings. If your team already writes GDScript or C#, Godot gives you a text-based workflow that GDevelop deliberately does not. Against Unity the split is different again. Unity is a general-purpose engine with a large asset and package ecosystem and a C# scripting surface. GDevelop's pitch is the absence of that surface: the README frames it as "designed to be fast and incredibly intuitive" with an "easy-to-understand yet powerful event-based system". That is a real trade. You give up direct control over engine internals in exchange for a shallower learning curve and a browser-and-desktop editor that non-programmers can operate. Neither comparison is settled by feature counts. It is settled by who on your team will be editing the game next month. ## Release cadence, licence and the cost of staying current The release history is dense: v5.6.280 on 2026-08-20, v5.6.281 on 2026-08-28, v5.6.282 on 2026-09-11, with the last push to master on 2026-09-19. A patch-level cadence of roughly two weeks means the editor you download today will be superseded within a month. For a team shipping a game, that is a maintenance decision: pin the version you build against, and treat upgrades as a deliberate step rather than an automatic one. Contributors pay a different cost. The repository is a multi-language workspace: a CMakeLists.txt at the top level, a tsconfig.json, clang configuration files, and CI split across CircleCI, Semaphore, AppVeyor and a Travis file, plus a Husky directory for git hooks. Building the full toolchain is not a single command, and the README routes you to newIDE/README.md rather than summarising the steps. The licence needs care. The repository metadata reports NOASSERTION, which means GitHub could not map the file to a recognised identifier, and the README does not state licence terms in prose. LICENSE.md is the authoritative file. Read it before you ship a commercial game or fork the engine; this is a factual gap in the metadata, not a legal conclusion. ## Verifying GDevelop before you commit a project to it The repository gives you several cheap checks. The README links a showcase of games published on Steam, the App Store, Google Play, Itch.io, Newgrounds, CrazyGames and Poki, and gd.games is described as the platform for games powered by GDevelop. Those are shipping targets, not demos, and they tell you which platforms the project actually reaches. For extension work, the README separates official and experimental extensions from community extensions, hosted in two different repositories. If the feature you need is not in the built-in Extensions directory, check both before assuming it does not exist. For the engine itself, docs.gdevelop.io carries pre-generated documentation. That is the reference to read when an event does not behave as you expect, and it is more current than any summary of the architecture. The remaining unknown is performance on your target hardware; the README makes no benchmark claims, so measure on the device you intend to ship to. ## Conclusion Adopt GDevelop when the people making the game are designers or artists rather than programmers, and when the target is web, mobile or desktop 2D and light 3D. Do not adopt it expecting to drop into C++ or C# source and rewrite engine internals; the repository is a JavaScript and TypeScript workspace, and the extension system is the supported extension point. Before committing, verify on the machine you actually ship from that the editor downloads and starts, and check the licence text in LICENSE.md because the repository metadata reports NOASSERTION rather than a named licence. ## FAQ ### Is GDevelop free or paid? The README describes GDevelop as open-source software, and the source is in this repository. The same README links a pricing page for professionals, teams and individual creators covering online game services and commercial support, so the editor and the paid services are separate things. The repository metadata reports NOASSERTION for the licence, so read LICENSE.md for the actual terms. ### Which is better, GDevelop or Godot? The README does not compare them, and the difference it does describe is the interface: GDevelop uses an event-based system with modular behaviors rather than a scripting language for game logic. Godot is not mentioned anywhere in the repository material. The choice comes down to whether your team wants to write game logic as text or assemble it from events. ### Is GDevelop using AI? The README states that you can "Create with AI that assists or builds alongside you", and the repository carries an ai topic. The README does not describe which models or services back that assistance, so the specifics are not documented here. ### How do I install GDevelop? The README's getting-started table says to go to the GDevelop homepage to download the app. It gives no package manager command and no build instructions for end users. The separate build path in newIDE/README.md is aimed at people contributing to the editor or engine. ### How do I use GDevelop to make a game? The README points people who want to make games at the homepage download, and describes the workflow as building games with an event-based system and modular behaviors. It does not include a step-by-step tutorial. The wiki page on creating an extension is the closest linked guide, and it is aimed at extensions rather than whole games. ### Does GDevelop support 3D games? Yes. The README states that you can build 2D, 3D and multiplayer games, and the GDJS engine uses PixiJS and Three.js for 2D and 3D rendering over WebGL. The built-in extensions include Jolt Physics for 3D alongside Box2D. ## Sources - [4ian/GDevelop on GitHub](https://github.com/4ian/GDevelop) - [Issues](https://github.com/4ian/GDevelop/issues) - [Project website](https://gdevelop.io) - [README](https://github.com/4ian/GDevelop/blob/master/README.md) - [Releases](https://github.com/4ian/GDevelop/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/4ian-gdevelop