In this article
A runnable export and an editable handoff answer different questions. Our October five-coin experiment produced both a GDevelop source ZIP and an HTML5 build, with the latter subsequently running on an independent host. On October 20, we reopened that source and added one coin.
The original opened in a fresh signed-out web editor. A revised copy produced a preview that passed six-coin collection, stopped movement after victory and reset checks. That establishes a connected editing path, not a complete offline handoff or an independently measured second person’s experience.
Start with the actual export
The original ZIP contains a single game.json. Keeping both unchanged, we served the file through a read-only loopback JSON endpoint and loaded it using the editor’s project URL entry. The new session displayed Five Coin Test and generated a preview.
The core is small: one scene, five object types and four top-level events. Player and coins use text shapes. The resource list also retains six remote image references and some starting-template extensions. Opening the project does not package those dependencies or establish that every listed image is needed by the current rules.
No credits were purchased, original account login reused or built-in GDevelop Agent request submitted. Our AI coding assistant edited the structured project file directly. The outcome cannot measure the built-in Agent’s speed, success rate or price.
One extra instance affects several paths
We placed a sixth coin at scene coordinates (1000, 300), keeping the original five positions. The edit involved more than duplicating an object:
| Location | Change | Risk if left unchanged |
|---|---|---|
| Scene instances | Add the sixth coin | Target count remains unchanged |
| Initial and live counter | Change denominator to 6 | Display disagrees with the objective |
| Victory condition | Require at least 6 | Movement may stop early |
| R reset | Recreate six coins | Next attempt loses one coin |
| Button reset | Recreate the same six | Reset methods disagree |
These are risks identified in the source before editing, not bugs we deliberately introduced and reproduced. We completed the connected changes, then opened the copy as Six Coin Handoff Test in another new session.
Editable source is useful when related rules can be found and paths leading to the same state can be kept consistent. Duplicating an instance on the canvas would not by itself complete this request.
Check the loop through actual inputs
Direction-key input collected the coins. A runtime observer read positions, counts and visibility only; it did not move objects, change variables or invoke resets.
The visible counter advanced from 0/6 through 6/6. At 5/6, one coin remained and victory was hidden. After the sixth, no coins remained and the victory message appeared. Another approximately 400 milliseconds of Right input left the player’s coordinates unchanged.
A very short R press did not reset the win state. Holding R for approximately 350 milliseconds did: the player returned to (400, 300), six coins reappeared, the counter read 0/6 and victory was hidden. We did not establish the cause of this input-duration difference or repair it.
In a separate ongoing attempt, moving the player and then pressing and releasing Restart also restored the start, six coins and 0/6. That button check happened during play; a post-victory button reset was not separately checked in this revisit.
Where the handoff stops
This supports a limited conclusion: the previously generated source can leave its original authenticated session, reopen in a connected editor, accept a structured change and retain the checked rules and recovery paths.
We did not independently export the revised HTML5 build, edit offline, check desktop-editor compatibility, measure a different recipient’s effort or migrate every resource. The old five-coin build’s independent-host evidence belongs to that version. The six-coin copy remains an editing preview, not a newly published platform game.
A collaborator’s acceptance should start with the files they actually receive: editor version, resource and service inventory, starting capture, a collection-and-reset procedure and input timing requirements. Instructions are part of a maintainable handoff too.