Choose a game maker by the game you can play, the change you can make, and the project you can keep—not by a screenshot alone. A fair comparison starts with one small brief and checks the same player-facing rules before judging appearance. It also records manual work, plan restrictions, and what an export actually contains. This proposed test covers SEELE AI, Rosebud AI, GDevelop, and Buildbox, the four tools named in the existing comparison. No controlled runs or export inspections were available for this draft. Results and recommendations therefore remain blocked: there are no scores, observed capability gaps, or winner. The sections below define what to run and preserve so a later comparison can answer the selection question honestly.
The shared brief and the controls
Use a desktop browser, a fixed viewport, and the same input device for every run. Declare the allowed plan, spending cap, intervention limit, and stopping condition before opening a tool. Record account tier, date, exposed tool version, and actual costs. Do not assume equal prompt counts mean equal effort when one workflow requires visual editing.
Create Lantern Delivery, a single-screen 2D top-down browser game. Use an original courier and simple original scenery. Move with WASD or arrow keys. Collect five lanterns while avoiding one moving hazard. Show the collected count and a 45-second timer. Contact with the hazard or timeout ends the attempt. Collecting all five wins. Include visible instructions and Restart. Keep the same courier and art direction throughout. Do not use licensed characters or downloaded copyrighted art.Treat this as a specification, not a generated result. For the test, start the timer on first movement, stop input at either ending, and restore all state on restart. If an interface cannot accept the brief directly, document how its native workflow implements it. Do not quietly grant one candidate extra setup or substitute a more complete template.
The four candidate records to complete
SEELE AI: verify the handoff after the prompt
SEELE describes natural-language creation of game scenes, assets, and gameplay code. For this comparison, the relevant question is whether that workflow produces the specified Lantern Delivery loop and supports the controlled change in the same project. Supply the unchanged brief through the available creation workflow, then retain the original request, response history, first accessible build, and account conditions.
Do not infer source access, engine compatibility, or a successful local launch from the product’s positioning. Inspect the actual handoff and record its format. If extra clarification or repair is needed, count and preserve it before proceeding to the shield edit. A useful eventual recommendation would connect observed playability, revision effort, and reproducibility to a reader’s needs. At present, those observations do not exist, so this candidate has no score or assigned advantage.
Rosebud AI: capture the actual creation and revision path
Run the shared brief using the workflow available in the tested Rosebud AI account. Record the initial input format, any required setup, and every intervention needed to obtain an accessible build. Consult current official documentation for plan conditions, but keep documented claims separate from what the evaluator observes. This draft does not establish which current features or export formats are available.
Once a baseline can be played, preserve it before issuing the identical shield request. Record whether the revision changes the existing project and whether the courier, rules, and map survive. For handoff, inspect whatever artifact the tested workflow actually provides; do not rename a hosted link “source code.” Missing access on one account is a plan-specific observation, not evidence that a product never offers a capability. No Rosebud generation, revision, or export has been run for this article.
GDevelop: make editor work visible rather than invisible
Evaluate the current GDevelop workflow as it is presented to the tester, not as an assumed copy of a conversational generator. Record any scene construction, event editing, asset preparation, or template selection needed to implement the brief. If the workflow offers assisted creation, preserve its inputs and outputs alongside manual actions. This article has not verified those current options or their plan conditions.
An editable event structure may be the relevant handoff for a visual-editor user; it should not be dismissed merely because it differs from a directory of handwritten scripts. Conversely, an editor project alone does not prove that a shared browser build works. Capture the baseline, controlled event or project change, playable checks, and actual export contents separately. The eventual comparison should show the effort and result of this workflow, not penalize or reward it based on the label “no-code.” No GDevelop test result is available here.
Buildbox: distinguish project editing from published output
Use the tested Buildbox account’s actual workflow to implement Lantern Delivery, documenting required setup and any template-derived behavior. Verify current documentation and account conditions before describing publishing or export options. Do not assume that another tool’s prompt interface, file organization, or local-run instructions apply here. Preserve the first project revision that can be evaluated, including any manual preparation.
For the shield change, record the editable logic or project differences that implement protection, plus evidence that the baseline rules remain intact. Identify the resulting handoff precisely: an editor project, hosted build, compiled artifact, or source files, depending on what is actually supplied. If a target or export is inaccessible, state the tested plan and the exact restriction observed. A later reader can then judge the workflow against their own needs. At present, no Buildbox build, revision, or handoff has been inspected, and no capability verdict is justified.
Run the same play, edit, and handoff checks
First, test instructions, both movement schemes, one-time collection, hazard contact, five-lantern victory, timeout, and restart after each ending. Repeat after a fresh load. Mark each check pass, fail, or not tested and attach the build revision. Keep an uninterrupted recording that includes failures. A page response or attractive scene is not a completed game-loop check.
Then apply one controlled edit: add a shield pickup that absorbs exactly one hazard contact and disappears when collected. Show whether protection is active. Preserve courier art, map, controls, lantern count, timer, and restart. State that no second shield appears before restart. Test pickup, the first protected contact, the next unprotected contact, timeout while protected, and restart restoration. Rerun all baseline checks. Save the native revision difference, whether that is code, events, or another inspectable project artifact.
Finally, distinguish a playable link, compiled build, editable project, and human-readable source. Save the supplied export and inspect it. Open or run it using the documented tools in a clean directory, recording actual commands, versions, missing assets, and manual fixes. Download success alone does not establish a reproducible project. Keep current documentation beside the observation without substituting it for the test.
Compare like with like: first accessible result against first accessible result, and repaired result against repaired result with interventions disclosed. A beginner may prioritize understandable iteration and a working loop; a developer may prioritize reproducible source; an editor user may prefer inspectable events. Report those tradeoffs only after the artifacts exist. Time and credit figures need recorded start and stop rules, not estimates made after seeing the outcome. A single run can support a bounded case comparison, not a general reliability claim.
Evidence checklist: no result cells are complete
- Per candidate: account tier, test date, exposed version, browser, budget, and actual intervention history.
- Original brief, baseline project or build, and complete acceptance-check recording.
- Exact shield request, before-and-after revisions, inspectable change, and regression observations.
- Actual export or handoff artifact, clean-environment setup record, and observed launch outcome.
- Current official documentation supporting any plan or format statements.
- Per-tool findings and conditional recommendations written only after these checks.
All four candidate runs remain unperformed for this article. The checklist is a collection plan, not a results table. There is no tested ranking, fastest tool, cheapest completed game, or verified export winner to report.
Conclusion: Delay the recommendation until the evidence exists
The useful comparison is not which tool sounds most complete, but which tested workflow fits the project you want to continue. Preserve the shared brief, disclose assistance, and separate playable behavior from the handoff you can inspect. This draft cannot select a winner: the four controlled runs, revisions, and exports are still missing. After access and any budget are authorized, use the shared Lantern Delivery brief in SEELE and repeat it unchanged in the other candidates. Keep failures and restrictions in the record. Only then narrow the choice using observed playability, editing effort, and project access rather than an assumed ranking.
Comparison scorecard: record your own evidence
This matrix organizes the article’s proposed checks. It is not a report of a completed test.
| Evaluation | Apply the same check to each candidate | Record |
|---|---|---|
| Playable result | Run the shared brief and check its player-facing rules. | What worked, what failed, and the evidence of each run. |
| Effort and cost | Record the plan, actual spending, prompts, and manual edits. | Account tier, date, cost, interventions, and elapsed effort. |
| Revision | Request the same bounded change and repeat the baseline. | Change instructions and before/after test results. |
| Handoff | Inspect what is actually available after export or handoff. | Files, editability, dependencies, and applicable terms. |
| Decision | Compare the recorded evidence against your priorities. | State unresolved checks rather than assigning an unsupported winner. |
Frequently asked questions
Does an export button mean I will receive editable source?
No. The export may be a compiled build or a project intended for a particular editor. Download and inspect the actual artifact, then open or run it with the documented tools. Record the tested plan and format so a narrow account-level observation is not mistaken for a universal product capability.
Can official documentation replace a hands-on comparison?
No. Documentation can support a current feature or plan statement, but it cannot show that this particular game played correctly or survived the shield change. Keep documentation and observed results in separate notes. Mark an unrun scenario as not tested rather than borrowing confidence from a promotional example or feature list.
Should every candidate receive exactly the same number of prompts?
Use the same initial brief and change specification, but disclose all additional assistance and manual work. Different interfaces may require different actions, so prompt count alone is not a fair effort measure. Set the intervention and budget limits in advance, then preserve the history instead of adjusting the rules after seeing results.
