In this article
- Start with your intended endpoint
- Stage 1: make the brief testable
- Stage 2: revise without losing the loop
- Stage 3: separate preview, build and editable source
- Stage 4: check publication and discovery separately
- What the current evidence supports
- Leave a result that someone can check again
- Record a budget without inventing a unit price
- The next useful comparison
A first playable screen is one milestone. A game that survives a revision, opens for a new visitor and can be maintained elsewhere has passed different checks. This guide connects our existing records into a reading path. It adds no new generation tests and makes no overall product ranking.
Start with your intended endpoint
| Your goal | Read first | Evidence to obtain |
|---|---|---|
| Test a small rule in a browser | Five coins, three workflows | Input, scoring, ending and restart in an operable preview |
| Keep editing a project | GDevelop profile | Understandable event logic, source files and resource dependencies |
| Publish on your own site | Export acceptance guide | An actual build loaded on an independent host in a new session |
| Reach players through a platform | Discovery is part of the tool | Publication conditions and an explanation of discovery metrics |
| Investigate current options | Questions before choosing | Account eligibility, plan conditions and dated capability evidence |
For example, a teacher demonstrating a collection rule may only need a preview that resets reliably. Someone handing a project to another developer needs editable source and dependency instructions. A creator publishing a public game also needs to check the visitor’s first session. These goals require different evidence.
Stage 1: make the brief testable
Begin with a single screen, a small number of objects and an observable ending. Our five-coin brief specified movement, single collection per coin, a counter, stopped movement at victory and two reset methods. Simple shapes kept asset generation outside the experiment.
Write the expected behavior before generation. “Make it fun” is difficult to accept consistently; “after five coins the counter reads 5/5 and movement stops” can be checked. Record the account plan and a stopping budget so later results retain their context.
Stage 2: revise without losing the loop
The Rosebud record describes an October 10 speed revision followed by repeated collection, victory and reset checks. The GDevelop record describes a restart repair. Those are different tasks, even though both concern iteration.
Keep a known working version before a change. After reducing movement speed, check collision and reset as well as speed. A successful modification response is evidence of the assistant’s report; operating the result establishes whether the requested behavior survived.
Stage 3: separate preview, build and editable source
In the historical GDevelop experiment, a real HTML5 build ran on an independent host, while a separate source copy retained remote references. In the Rosebud session, the tested account did not permit export. In the CraftBuddy attempt, no operable preview was obtained before manual termination.
These outcomes answer different questions. Use the export guide to check entry files, asset paths, external requests and a fresh visitor session. If another person must continue development, open the editable project in a clean environment too. A downloadable ZIP is a starting artifact, not proof that every service or license transfers.
Stage 4: check publication and discovery separately
A working public link establishes availability under the checked conditions. It does not establish recommendation traffic, sustained play or income. Our distribution analysis explains why the destination of a generated game matters.
TapTap Maker documents a public web and local MCP direction, while Google Playground records official sharing and export descriptions. Neither profile represents a completed generation or publication test by this site. Investigate eligibility and actual publication conditions before depending on either route.
What the current evidence supports
| Product | Dated basis | Boundary |
|---|---|---|
| Rosebud | October 10 small desktop generation and revision | No export package from tested account |
| GDevelop | October 10 generation, restart repair and independent web build | Separate editable source retained remote resources |
| CraftBuddy | October 12 interrupted creator session | No operable preview accepted |
| TapTap Maker | Public-source profile and workflow observation | No local MCP or publication acceptance |
| Google Playground | Official announcement and help-document research | No editor or actual ZIP acceptance |
Read the profiles for sources and account details. These records are historical observations, not promises about today’s plans. The dated timeline keeps product announcements apart from our own checks.
Leave a result that someone can check again
This is a proposed acceptance sheet, not another completed test. Reuse the five-coin rules, change one parameter at a time, and record a visible control separately from the behavior after activating it.
| Action | Expected result | If it fails |
|---|---|---|
| Move into the same coin repeatedly | Count increases once; coin disappears | Preserve the input sequence and screen; fix collision or duplicate scoring |
| Collect all five, then hold a direction | 5/5 and victory appear; movement stops | Fix the ending state before adding levels |
| Try button and R during play and after victory | Player, all coins and counter reset | Record all four combinations separately |
| Reduce only speed, then repeat the checks | Speed changes; collection and reset survive | Compare versions and undo unrelated changes |
| Open sharing or independent build in a new session | Loads and accepts input without creator login | Separate visibility, permissions, resource paths and service dependencies |
| Open source in another clean environment | Instructions allow editing and rebuilding | List missing assets, dependency versions and platform services |
The historical GDevelop example explains the reset split: its button worked initially, but R after victory did not restore play. Rosebud was collected through victory again after revision before we concluded that the loop survived. CraftBuddy had no operable preview before stopping, so assistant self-check text cannot fill those acceptance cells.
Record a budget without inventing a unit price
Keep one row per request: date, plan, model, task, balance before and after, wall-clock wait, editor-reported time, deliverable and failed checks. Mark unsettled balances pending rather than immediately calculating cost per successful game.
In the historical Rosebud session, 8,000 to 6,200 accounts for 1,800 credits, followed by 400 for the speed revision: 2,200 total. That covers only that generation and revision, excluding export, assets and ongoing production. GDevelop recorded an overall allowance change from 100% to 20%, without an intermediate balance, so generation and repair costs cannot be separated. CraftBuddy’s 113-point difference was the displayed balance after manual termination, not the price of a completed game; subsequent settlement was not confirmed.
The units, accounts and tasks differ and cannot establish comparative value. If independent hosting is essential, resolve the export gate before expanding a preview. If the goal is only a rule experiment, record the achieved stage before deciding on another attempt. Budget and deliverable need to be evaluated together.
The next useful comparison
A further comparison should use the same brief, one common revision, recorded account conditions and a fixed stopping budget. Log request balances and wall-clock time; keep editor-reported time separate. Accept the core loop after each change, then test sharing or export outside the creator session.
Until comparable sessions exist, the useful editorial conclusion is where each workflow stopped and what remains to be verified. We will extend this guide when new records establish another stage, preserving the original dates and limitations.