In this article
The brief was small: move around one screen, collect five coins, advance a counter from 0/5 to 5/5, stop on winning, then restart with a button or R. Simple shapes, without generated art or music. That scope makes the questions after generation easier to see. Do the rules work? Does a repair preserve them? Do you receive a preview or a game you can put on your own website?
We checked Rosebud and GDevelop on October 10 and attempted the same core brief in CraftBuddy on October 12. Each workflow reached a different endpoint. This article synthesizes those existing desktop browser-automation sessions. It is not a same-day speed benchmark with equivalent plans, or a full assessment of game enjoyment.
Three meanings of “made a game”
| Tool and check date | Endpoint observed | Remaining boundary |
|---|---|---|
| Rosebud, October 10 | Collection, winning and restart passed in preview; passed again after a speed change | Export unavailable on the tested Newbie account; no package obtained |
| GDevelop, October 10 | Passed after a restart repair; HTML5 build passed in a fresh session on an independent host | Source copy retained remote resource references; not a self-contained editable asset bundle |
| CraftBuddy, October 12 | Type selection, design confirmation and generation started; manually stopped after about 22 minutes | No operable preview before stopping; gameplay and revisions could not be accepted |
The table identifies the next question to investigate. A preview can establish running rules without resolving handoff. A build running elsewhere does not establish that editable source, assets and every online service have been packaged together.
Follow the handoff, stage by stage
| Stage | Rosebud · October 10 | GDevelop · October 10 | CraftBuddy · October 12 |
|---|---|---|---|
| Brief and generation | Five-coin preview obtained | Five-coin preview obtained | Design confirmed; generation started |
| Core loop | Collection, win and stopped movement passed | Collection, win and button reset passed; R initially failed | No operable preview before stopping |
| Revision and regression | Speed changed from 300 to 240; loop and resets passed again | Restart repair passed; not the same speed-change task | Not checked |
| Independent delivery | Export unavailable on tested account | HTML5 ZIP ran on independent host in fresh session | Not checked |
| Editable handoff | No source downloaded | Separate source had six remote resource references | Not checked |
| Discovery and income | Not measured | Not measured | Not measured |
“Not checked” describes our sessions, not a missing product feature. Results come from the dated Rosebud, GDevelop and CraftBuddy records. Accounts differed: Rosebud showed Newbie; GDevelop used an existing signed-in AI allowance; CraftBuddy had creator access. No purchase was made. CraftBuddy received a differently worded brief with additional WASD support, not a verbatim copy of the other prompt. Revision tasks differed too, so this table cannot rank speed or overall quality.
For a repeatable next trial, fix the brief, account plan, one revision and a stopping budget beforehand. Record wall-clock time separately from editor-reported time, with balances before and after every request. Check input, collection, victory and reset after generation and revision. Finally, open a shared result outside the creator session or run an export on an independent host. Record source and service dependencies separately. The delivery field guide connects these checks to profiles and practical guides.
Rosebud: the loop worked; export was the next gate
The Newbie plan page showed 8,000 weekly credits. For the initial build, the editor reported 29 seconds, one turn and 1,800 credits; the balance moved from 8,000 to 6,200. Actual inputs collected five coins, reached a win state that stopped movement and restarted using the button and R. These are different kinds of records: time came from the editor’s report, while behavior came from operating the preview.
We then changed one thing: movement speed from 300 to 240 pixels per second, retaining collection and restart. The editor reported 16 seconds, three turns and 400 credits. Actual input moved the player approximately 121 pixels in half a second. Collection, victory, stopped movement and both resets passed again. This small revision establishes more than an initial appearance: the core loop survived a change.
On that account, code access required an upgrade and Export was unavailable. We bought no plan and downloaded no project. For testing an idea inside the editor, the session answered part of the brief. For delivering a game elsewhere, it had not reached the endpoint. Higher-plan documentation is discussed in the tool profile; it is not an export completed in this session.
GDevelop: restart exposed the need for acceptance checks
The first result collected coins and reached victory, and the button reset worked. R did not start a fresh game after winning. This is the observed failure; the assistant’s explanation of its cause was not independently confirmed. A focused correction was followed by passing collection, victory and restart checks. One working reset method did not establish that the other worked.
The exported HTML5 ZIP contained 114 files, about 1.30 MB uncompressed. We put that actual build on a separate Cloudflare Pages preview. A fresh browser context, without a GDevelop login, completed collection, victory and R-key reset again. During a three-second startup observation, all 106 requests stayed on the preview origin, with no failed requests or page errors. That bounded window supports startup, not offline operation of every later feature.
The separate source download contained only game.json, with six remote resource references, some from the starter project. Here the browser build and editable project diverged: one had run independently; the other still required resource dependency work. Handoff to another editor needs an additional check.
After generation and repair, the account showed 20% AI allowance remaining and no purchased credits. We did not record the balance between requests, so the 80 percentage-point reduction cannot be assigned to individual requests or compared directly with Rosebud credits or CraftBuddy points.
CraftBuddy: design confirmation preceded a missing preview
The signed-in October 12 session began with 7,894 points. After receiving the brief, the platform asked for a type. We chose casual collection, confirmed the design and separately clicked Generate Game. Design in a conversation and actual generation were distinct stages.
The assistant subsequently reported an invisible player and inconsistent inputs, then attempted repairs. We had no operable preview before stopping, so those remain assistant reports rather than independently reproduced faults. About 22 minutes elapsed between generation confirmation and manual termination, including observation intervals. This interruption does not establish typical generation time or prove that the tool cannot complete the brief.
The displayed balance was briefly 7,887 during processing, then 7,781 after stopping and refreshing: 113 below the starting balance. No points or subscription were purchased. That number describes an interrupted attempt, not a price per game. A useful next check must first obtain a playable preview before assessing revision and export.
What should change in your next tool trial?
For a quick rule prototype, inspect behavior in the preview, particularly starting again after an ending. Stopping when the first screen appears would miss the state problem in this GDevelop session.
For a game on your own site, perform a real export before adding levels. Rosebud’s account gate and GDevelop’s running build answer delivery questions under specific access conditions, rather than establishing overall product superiority.
For a maintainable handoff, open source from a clean environment and identify asset and service dependencies. An independently running build and a transferable editing project need separate acceptance checks.
A fairer next comparison needs the same brief, revision task, account conditions and stopping budget, plus balances before and after every request. For now, these sessions show why the important milestones extend past generation: the next round, the next revision, and what happens after leaving the editor.