A game that opens in a browser is not necessarily a project you can keep developing. The next useful question is whether someone can reproduce it, explain its rules, and add one feature without breaking the original round. Test that with a preserved baseline and a narrowly specified extension, not a screenshot or an assurance that the code is editable. This article defines a reproducible continuation test for a small star-collection game. It is not a completed hands-on report: no source project, baseline run, or extension patch was available for this draft. The real-results requirement remains blocked. Use the protocol to gather the missing evidence; do not read its acceptance criteria as findings about SEELE or any generated project.
1. Establish the project and its original rules
Use one bounded fixture: a desktop browser game with arrow-key movement, five collectible stars, a 30-second round, a win after collecting all five, a timeout loss, and a clean restart. This is the intended test fixture, not an existing build. Obtain the actual editable project, its assets, dependency declarations, and startup instructions. Record the generator or tool version when exposed, the project revision, runtime, browser, and operating system.
Distinguish source files from a hosted preview or compiled bundle. Missing assets, undocumented dependencies, or an unavailable source handoff are findings to record, not gaps to fill silently. If the supplied project differs from the fixture, document its existing rules before choosing an equivalent bounded extension. Preserve an untouched copy and a separate working copy so later changes cannot erase the original evidence.
2. Reproduce the baseline before repairing anything
Follow the supplied setup instructions in a clean directory. Save the exact commands, installation output, startup log, and browser console. Do not invent a command because the project resembles a familiar framework. When setup fails, retain the error and record any intervention separately. A baseline repaired by the evaluator is a repaired baseline, not an unqualified success for the supplied project.
Run four scenarios: collect one star and stay at its location; collect all five; allow the timer to expire; restart after each ending. Check one count per star, frozen movement after an ending, and restoration of every round state. Write the action, expected result, observed result, and revision for each scenario. Preserve failures as carefully as successful runs.
3. Trace the rule you will change
Locate the real code or editable logic that connects movement, contact detection, collection state, the displayed count, and the win check. Use actual filenames or event identifiers in your notes. Explain who owns the timer and which reset action restores it. A plausible AI explanation is not enough: check it against the project.
Look for duplicated counters or reset logic spread across unrelated systems. These are questions for review, not automatic proof of bad architecture. The practical goal is to identify where a bonus pickup belongs and which existing behavior must remain unchanged. Record uncertainties before requesting the patch.
4. Add one blue bonus star to the same project
Save the baseline revision, then request this one change. The example deliberately separates the new timer effect from the existing collection count:
Extend this existing game with one blue bonus star. On its first contact during an active round, remove it and add three seconds to the remaining time. It must not increase the normal-star counter or change the five-star win threshold. Restart restores the bonus star. An ended round cannot be revived. Preserve movement, normal stars, timeout, and all original ending rules. Identify the actual affected project files or events before proposing the smallest patch. Do not replace the game or unrelated assets.Review the proposed change before executing it. Record changed files or events, added dependencies, and any restructuring. Ask why an unrelated subsystem changed. A new standalone game with a blue object does not demonstrate continuation of the baseline, even if its preview looks similar. Keep the patch and its explanation together so another reviewer can inspect the same revision.
5. Recheck old behavior, new boundaries, and rollback
Repeat every baseline scenario. Then collect the bonus star once and remain at its former location: time should increase only once and the normal count should not change. Restart, collect it again, and verify the reset. Check contact near timeout and after an ending; the new pickup must not resume a finished round. Record frame-order assumptions if simultaneous events can affect the outcome.
When a check fails, save the failing revision and a short reproduction sequence before asking for another repair. Roll back to the preserved baseline and rerun a baseline scenario. Only after that check can you report that rollback was reproduced. No successful patch, regression-free result, repair duration, or rollback outcome has been established here.
What SEELE can contribute—and what must be verified
SEELE describes a natural-language game-creation workflow involving scenes, assets, and gameplay code. That makes a small generated game a relevant starting point for this test. Supply the compact game brief first, then verify what the current workflow actually hands over: a playable result, an editable project, source files, or another artifact. Those deliverables are not interchangeable.
At the continuation stage, provide the existing project context and the single bonus-star requirement. Inspect the resulting change rather than assuming that a natural-language revision preserves state correctly. Available project access, engine compatibility, and export details need confirmation in the actual account and output. The product description supports trying the workflow; it does not establish this project’s reproducibility, architecture, or maintainability.
The evidence required for a real conclusion
- Original source or editable-project archive, required assets, and a stable baseline revision.
- Actual setup instructions, environment details, command output, and startup errors or repairs.
- Baseline scenario record plus uninterrupted runtime evidence for win, loss, and restart.
- An explanation tied to actual code or events, the exact extension request, and its inspectable patch.
- Before-and-after revisions, regression and boundary-check observations, and a reproduced rollback.
- A conclusion limited to this project and this extension, including unresolved failures.
All of these result-bearing artifacts are currently missing. A successful bonus-star change would support a narrow continuation claim, not a promise about networking, save migrations, or production-scale development. An incomplete handoff should remain visible in the report rather than being replaced by a generic “AI code is editable” conclusion.
Conclusion: Gather the next-change evidence first
Judge continuation by a change that survives review and regression checks. Begin with reproducible project materials, preserve the original rules, and keep the extension small enough that an unexpected edit is visible. The present draft provides that method, not the missing result: a hands-on maintainability verdict remains blocked until the project, patch, and runtime evidence exist. For your next step, use the small star-collector brief in SEELE and retain the actual handoff before requesting the bonus star. Stop at missing source or failed setup, document the blocker, and avoid treating a polished preview as proof that development can continue.
Continuation test: evidence to collect
This matrix organizes the article’s proposed checks. It is not a report of a completed test.
| Check | Expected observation | Evidence to retain |
|---|---|---|
| Baseline setup | The supplied project can be opened and run using its own instructions. | Project revision, setup steps, dependencies, and run notes. |
| Original round | Movement, five collectibles, timer, win, loss, and restart follow the specified fixture. | A repeatable test log and the baseline revision. |
| Bounded extension | The requested bonus-star rule works without changing unrelated behavior. | The change request, patch or revision, and new-rule checks. |
| Regression and rollback | Original tests still pass and the change can be identified and reversed. | Before/after test results and the rollback reference. |
Frequently asked questions
Can a hosted preview prove that a game is maintainable?
No. A hosted preview can demonstrate observable gameplay, but it does not establish source completeness, reproducible setup, or the consequences of a code change. Use it as one part of the record. A continuation claim also needs the editable materials, preserved baseline, inspectable change, and regression checks from the intended runtime.
Do I need a programmer to perform this test?
You can record player-facing scenarios without being a programmer, but reliable source and dependency review needs someone familiar with the project’s language or editor. Separate those responsibilities. Ask a qualified reviewer to verify the actual change rather than treating a confident AI explanation or a working opening screen as an architecture review.
What if the extension works but the setup remains undocumented?
Report a partial success, not a clean handoff. The extension may work in an already configured environment while a new developer still cannot reproduce it. Preserve the successful revision, write down the setup steps actually used, and repeat them from the supplied materials before describing the project as independently reproducible.
