Crash Reporting for GDevelop Games

GDevelop lets you build games with no-code event logic, and underneath, that logic runs as HTML5 and JavaScript, exported to the web, mobile through a wrapper, or desktop. Like other HTML5-based engines, a GDevelop game fails as a JavaScript error, but the logic that failed lives in your visual events, not code, and the game runs across several targets. Setting up crash reporting for a GDevelop game means capturing the JavaScript errors with the scene and platform context that maps a crash back to your event logic and the target it ran on.

GDevelop is no-code events on HTML5

A GDevelop game is built with visual, no-code events, the conditions and actions you assemble to create your game logic, and GDevelop compiles this to HTML5 and JavaScript that runs in a browser engine, exported to the web directly, to mobile through a wrapper, or to desktop through a runtime. This means a GDevelop game is fundamentally an HTML5 application, and it fails as one, with JavaScript errors.

But the logic that fails lives in your events, not in code you wrote, so a JavaScript error in a GDevelop game maps back to an event, an extension, or the engine, rather than a code line. Like Blueprint games, the visual-logic nature means the crash needs to be connected back to the visual events where the problem lives. Understanding that GDevelop is no-code events running as HTML5 frames the crash reporting: capture the JavaScript errors that the HTML5 runtime produces, and connect them back to the events and the target.

Capture the JavaScript errors

Capture GDevelop crashes by hooking the JavaScript error handling, the global error and unhandled rejection handlers, so a JavaScript error that would crash or freeze the game and land silently in the console is captured with its message, stack trace, and source. This is the standard web error capture, since a GDevelop game runs as HTML5, whether on the web, in a mobile wrapper, or in a desktop runtime.

The stack trace points into the GDevelop runtime, your compiled events, or an extension, and capturing it gives you the starting point for diagnosis. For minified production builds, source maps help make the trace readable. Because the game logic is compiled from your events, mapping the trace back to a specific event takes some familiarity, but the trace plus your own context narrows it. Capturing the JavaScript errors is the foundation, providing the stack trace that, combined with the scene context, points at the event logic where the crash originated.

Capture the scene and game state

GDevelop organizes games into scenes, and a crash almost always occurs in the context of a specific scene, so capture the active scene with every error. Knowing which scene the crash occurred in immediately localizes it to that part of your game and its events, which is far more useful than the stack trace alone for connecting the crash to your visual logic.

Capture relevant game state too, the level, progress, key variables, so the crash arrives with the situation context. The scene plus the game state give you the gameplay context that the JavaScript stack trace lacks, telling you what the player was doing and where, which points you at the events involved. Capturing the scene and game state is what bridges the gap between the JavaScript trace and your no-code events, letting you find the event logic that failed in the situation the crash occurred in, which is essential for a visual-logic engine where the crash does not map to a code line.

Capture the platform and watch extensions

GDevelop exports to web, mobile, and desktop, and a crash can be platform-specific, so capture the platform with every error. The web export runs in a browser with its constraints, the mobile export in a wrapper with mobile limits, the desktop export in a runtime, and a crash that appears only on one target points at a platform-specific issue, which the platform context reveals.

Watch GDevelop extensions too, the behaviors and extensions that add functionality, since like plugins in other engines, an extension can have bugs or interact badly with your game, and a crash whose trace involves an extension points there. Capture which extensions are in use so extension-related crashes are identifiable. Capturing the platform, to interpret target-specific crashes, and the extension context, to identify extension-related ones, covers the remaining dimensions of GDevelop crash reporting beyond your own event logic, completing the picture for a multi-target, extension-using engine.

Setting it up with Bugnet

Bugnet captures JavaScript errors from your GDevelop game by hooking the error handlers, with the scene, game state, platform, and extension context attached as custom fields, and source maps to make traces readable. Reports flow into one dashboard tagged by platform, so you can see your GDevelop game crashes across its web, mobile, and desktop targets with the context that connects them to your events.

Group identical errors into occurrence counts, and use the scene and platform context to localize crashes to your event logic and the target they occurred on. Because GDevelop crashes map to visual events rather than code lines and the game runs across targets, the captured scene-and-platform context is what makes them diagnosable, telling you which scene and target to investigate, which is exactly what you need to fix the event-logic and platform issues that a no-code HTML5 game produces.

Test each export you ship

Because GDevelop exports to several targets that behave differently, test each export you ship, since target-specific issues, a web memory limit, a mobile wrapper quirk, a desktop runtime problem, show up when you run the actual export. A GDevelop game that runs fine in the editor preview can hit issues on a specific export that only testing that export reveals.

Test your event logic across the scenes and situations players will encounter, since a logic error in an event only appears when that event runs in that situation, and your no-code logic is as prone to bugs as code. Pair the testing with your captured crash data, which surfaces the event-logic and platform crashes across the targets and situations you cannot fully test. Together they keep a GDevelop game stable across its exports, with the event logic and the platform-specific behaviors, where its crashes occur, kept solid for the players on each target.

GDevelop is no-code events on HTML5. Capture the error, the scene, and the platform to map crashes back to your events.