Start with rules you can explain and results you can check, not a large world or a perfect character. For this first exercise, make Star Sprint: move a blue circle, collect five yellow stars, and finish before a 30-second timer expires. Simple shapes let you concentrate on whether the game works without drawing assets or editing code yourself. You will write one brief, check the first result, request a single visual revision, and repeat the same tests. The prompts and expected behavior below form a complete illustrative follow-along example; no Star Sprint build was generated or tested for this article. Tool output may need repairs, and a correct small prototype is not the same thing as a release-ready game.
Before you start: use one screen and a keyboard
Use a desktop browser and a keyboard. Keep one arena, one blue circle, five yellow stars, and a dark background. The circle moves with arrow keys, stars count once, five stars wins, and timeout loses. Restart restores the player, stars, count, and timer. Different shapes distinguish player and targets without relying on color alone. Save this scope in a note; enemies, sound, levels, accounts, and purchases can wait.
1. Submit the complete Star Sprint brief
Open the available game-creation workflow and provide the following brief. Keep a copy so you can compare the output with the request. It specifies expected behavior, not behavior already verified:
Build Star Sprint, a single-player desktop browser game. Show one arena, a blue circle, five yellow stars, a Stars: 0/5 counter, and a 30-second timer. Use arrow-key movement and keep the player inside the arena. Space the stars apart in reachable places, with none overlapping the start. Start timing on first movement. Touching a star removes it and counts exactly once. Collect five before time expires to win; otherwise display Time up. If the fifth collection and timeout occur in the same update, resolve collection first. Freeze movement after either ending. Show short instructions and a Restart control. Restart restores the initial position, five stars, zero count, and a fresh timer waiting for movement. Use simple shapes. Add no extra mechanics, audio, or levels.2. Check the result from movement to restart
Open the resulting game. If it fails to launch, record the error before requesting a startup fix. Otherwise, press each arrow separately and test every arena edge. Touch one star and remain there: it should disappear and the count should stay at one. Collect the others to inspect victory and frozen movement. Restart, move once, avoid stars until timeout, and inspect the loss. Restart again and check the entire initial state.
3. Fix one failed rule before improving the look
Keep a note with action, expected result, actual result, and requested fix. For example, if one star counts repeatedly, describe the repeated-contact sequence and ask for one-time collection while preserving the other rules. This is a hypothetical fault, not an observed finding. Retest that action and both endings after the fix. Do not combine unrelated changes into “make it better,” and do not replace the original game to hide a faulty rule.
4. Request one visible, bounded revision
Once the rules pass, enlarge the displayed stars without changing collection behavior. Save the current version first. Use this request:
Increase only the displayed size of each yellow star by 25 percent. Preserve each center position and collision area. Keep player size, movement, scoring, timer, win/loss rules, and restart unchanged. Add no effects or mechanics.Compare the same view before and after. Stars should look larger without moving or counting sooner. Repeat the win, timeout, and restart checks. If another rule changed, return to the saved version where possible and request the narrow correction. If version restoration is unavailable, keep the earlier artifact and describe that limitation rather than claiming a successful rollback.
5. Accept the tiny round before adding anything else
Your exercise is complete only when movement stays inside the arena, every star counts once, five stars wins, timeout loses, both endings freeze input, and restart restores the full initial state. The size revision must leave those rules intact. Ask a friend to play without coaching if possible: unclear instructions are a reason to improve the objective text, not add a level. Save expansion ideas separately. No completed acceptance run is claimed for this article.
Using SEELE for the brief and the focused revision
SEELE describes creating game scenes, assets, and gameplay code from natural-language input. In this exercise, the input is the Star Sprint brief; the intended output is the small playable round that you will check. Use the current product’s available creation workflow rather than looking for a button name or interface layout that this tutorial has not verified.
At the revision stage, provide the existing game context and the star-size request, then inspect what changes. A successful-looking response is not acceptance: the browser game must still pass the original checks. Confirm available access, usage limits, and project handoff in the actual account. The exercise shows how to make your request and evaluation concrete; it does not guarantee a first-pass result or a particular export format.
Troubleshoot the symptom you can reproduce
If a star vanishes but the count does not change, report both observations and the action that caused them. If the timer accelerates after repeated restarts, report that sequence and request one active round timer with proper reset. If the character keeps moving after a loss, ask for ended-round input to be disabled. If the tool adds enemies or menus, refer back to the saved scope and remove those additions before retesting. These are possible troubleshooting paths, not source-code diagnoses or observed Star Sprint defects.
Conclusion: Finish a repeatable round, not a feature list
A useful first game has a clear objective, feedback you can understand, and a round you can restart reliably. You do not need finished artwork to reach that milestone, but you do need to check the behavior rather than trust the prompt. Use the Star Sprint brief in SEELE as your next action, preserve the first result, and request only one correction or revision at a time. This remains an illustrative exercise until you run your own build. If the small loop passes, save it before planning another mechanic; if it fails, keep the reproduction steps and repair that failure first.
Frequently asked questions
Do I need to buy or draw artwork before starting?
No. The circle, stars, and arena are enough to evaluate this exercise. They are deliberate prototype assets, not evidence of a finished visual style. Replace them later if the rules work, and check the permissions and applicable tool terms for any downloaded or generated artwork before you share or sell the game.
Can I follow this exact tutorial on my phone?
Not as written: the brief requires arrow-key input and assumes a desktop browser. A phone version needs explicit touch controls, layout decisions, and device checks. Finish the keyboard version first, then treat mobile support as a separate bounded change rather than assuming a browser game automatically works well on a touchscreen.
What should I do when the tool adds features I did not request?
Ask it to return to the saved Star Sprint scope and remove the unwanted additions while preserving the original loop. Extra mechanics create more interactions to check and can hide the cause of a failure. Keep the earlier working artifact when available, then repeat movement, collection, endings, and restart after the correction.
