GDevelop v5.6.281 builds games through events and behaviors
Version 5.6.281 centers the editor on scenes, objects, variables, and reusable behaviors, with game logic defined as events. The runtime covers 2D through PixiJS and 3D through Three.js, with WebGL underneath. Exports target browsers, desktop systems, iOS, and Android. JavaScript remains available when the event model runs out of room, and extensions can add new objects or behavior. That mix is useful for artists, educators, and small teams that want visible logic without surrendering every route into code.
The size of the checkout changes the contributor story. Our measured commit contained 6,533 files, roughly 942,292 lines of source, and occupied 217.6 MB before dependencies. This is an editor, game runtime, extension collection, code generator, and native core in one repository. A designer can download the finished application and avoid that machinery. Someone changing the engine or editor has to identify which layer owns the behavior before choosing a build and test command.
The 6,533-file tree contains several development environments
At roughly 942,292 source lines, the root architecture separates Core, GDJS, GDevelop.js, newIDE, and Extensions. Core describes games and editor operations. GDJS contains the TypeScript and JavaScript runtime plus exporters. GDevelop.js exposes native C++ pieces to JavaScript through compiled bindings. The editor itself uses React and Electron. Official, experimental, and community extensions also span related repositories, so a visible feature may cross generated code, runtime code, editor controls, or an external extension source.
Our lab worked only inside GDJS, where npm installed 202 packages in 176 seconds and used 143 MB. That scoped path is the right place for runtime work and TypeScript checks. It does not prepare the React editor under newIDE/app or the Electron wrapper under newIDE/electron-app. The editor guide has separate installs and keeps its web development server running while Electron starts from another terminal. Contributors should decide which product surface they are changing before installing from the repository root.
What happened when we ran it
Our measurement setup used commit 23422df in a fresh unprivileged Debian container with 3 CPUs and 8 GB of RAM. The GDJS install succeeded in 176 seconds, adding 202 packages and taking 143 MB on disk. The production build then completed in 6 seconds. Npm audit reported 0 known vulnerabilities across the installed dependency tree, including 0 critical, high, moderate, or low findings.
The test step failed with exit code 127 after 6 seconds. The root package changed into tests, invoked npm run test-benchmark, and tried to start ChromeHeadless through Karma. The shell then printed karma: not found. The log does not say whether the missing executable came from an omitted install, a package declaration, or another setup assumption, so we will not choose a cause. The useful finding is that the documented project path did not produce a runnable test command after the install we measured.
The 217.6 MB checkout is only part of a full editor build
Beyond our 217.6 MB engine checkout, starting the React editor copies images, the GDJS runtime, and extensions into its resources, then downloads libGD.js automatically. Building that native bridge yourself is a separate route for changes to the C++ core or native extensions. Cloud storage development also uses a special local hostname mapped through the hosts file. None of those steps were exercised by our engine-only run, and none should be inferred from the successful GDJS build.
A portable Electron bundle adds another installation and platform libraries. On Linux, the documented headless example names NSS and audio packages and runs the binary with a sandbox-disabling flag. The installed command-line behavior also differs according to editor state: with the same project already open, a command is handed to that window and the CLI exits without the final result. The 6-second GDJS build says little about that packaging route, code signing, mobile export, or cloud integration.
GDevelop 5.6.0 has an open report of a stuck multiplayer join
Issue 8968 describes an intermittent multiplayer path where a player waits for a peer identifier with no timeout. According to the report, the full-screen loader remains visible and a state flag blocks later join attempts until the page reloads. The reporter reproduced it on gd.games with GDevelop 5.6.0 build 277 and linked the relevant extension code. There were no comments when fetched, so teams shipping multiplayer should reproduce the condition and test recovery rather than treating the issue text as a confirmed universal failure.
The lab's 6-second test failure does not demonstrate that lobby defect. It shows a separate contributor problem: the available command never reached its ChromeHeadless benchmark suite because Karma was unavailable. Our scan found 6 CI workflow files and a tests directory, while the README also links CircleCI, Semaphore, and AppVeyor status pages. That is evidence of substantial automation, but a new contributor still needs a locally repeatable command for the exact GDJS checkout.
A September push and August release show current maintenance
GitHub recorded a push on September 5, 2026, and 26,217 stars when fetched. The repository listed 630 combined issues and pull requests, with open issue activity continuing through late August. Release v5.6.281 arrived on August 28 with object-list multi-selection, variable editor changes, profiler work, rendering changes, and fixes across tile maps, compressed GLB loading, and extension imports. That mix points to an actively changed editor and runtime rather than a project surviving on old tags.
The maintenance pace does not make the source tree small. Our 217.6 MB checkout approached 1 million lines, and the 176-second install ended in a test command that could not find Karma. GDevelop is easiest to recommend as a finished visual editor, where its event system and export rights solve a clear problem. For engine contributors, budget time to map the repository layers, run each affected package's checks, and prove that a clean environment can reach the browser test runner.