Turn a game idea into a buildable brief.

WHERE IN THE IDE

Ask AI / Create with AI; Game Project Agent for an experimental multi-resource proposal

Before you start

Pick one target: the example uses 48K and the beeper.
Start in a new practice project rather than replacing a working game.
Choose one observable loop: start, play, win or lose, replay.

What the assistant knows

A whole-program request is not a whole-project implementation. The Game Project Agent is a separate experimental path with its own manifest and resource review.

STEP 01

Ask for a plan before a program

Use Ask AI with a minimal valid BASIC source as context. Keep the first request advisory. State inputs, output and the features you are deliberately leaving out.

EXAMPLE REQUEST Adapt to your project before sending

Plan only; do not modify source.
I am making a ZX Spectrum 48K number-guessing game in Sinclair BASIC.
The player guesses an integer from 1 to 20, has five attempts, sees higher/lower feedback, then chooses whether to replay.
No assembly, AY music, disk access or external assets.
Describe the variables, screen states, subroutines and five manual tests. Identify input edge cases. Keep the first playable version small.

STEP 02

Resolve the unanswered rules

Read the plan as a specification. Decide whether an invalid guess consumes an attempt, whether replay resets the score, and how the player quits. Ask a follow-up to settle these choices before generating. Record the final rules in your project notes; a later request should repeat any constraints it must preserve.

STEP 03

Generate the smallest complete program

Open Create with AI and choose a new program rather than silently replacing non-empty source. Paste the agreed rules and request a complete numbered Sinclair BASIC listing.

EXAMPLE REQUEST Adapt to your project before sending

Generate the first playable version for ZX Spectrum 48K.
Use the agreed number-guessing rules: 1–20, five valid attempts, higher/lower hints and replay. Invalid numeric ranges must not consume an attempt.
Use authentic numbered Sinclair BASIC, with LET assignments and a clear main loop. Do not add unsupported commands, assembly, external files or AY sound.
Keep screen messages short. Explain the input limitations and list the exact paths I should test. Do not claim the program has been run.

STEP 04

For a multi-resource idea, review the manifest

If you deliberately use Game Project Agent, select the target in that window and describe required BASIC, ASM, SCREEN$ or UDG resources. Wait for the final project proposal and local validation. Read the resource list, load addresses and tape order before Create New Project. Provider activity is not proof that a valid project has arrived. Keep this experimental route separate from your known-good project.

STEP 05

Build the first milestone yourself

Save the new project, resolve local diagnostics, build the TAP and Run. Play one successful game, exhaust the attempts, try boundary values, replay, and test the stated exit. Take notes on actual behavior before requesting the next feature.

A generated listing or validated project manifest is a starting point. Only the observed runs tell you whether these rules work.

If something goes wrong

The model tries to build the entire game at once: Reduce the request to one loop and one source. Defer animation, music and assembly until the loop works.
The agent is active but no project is available: Read the activity and validation states. Do not treat elapsed time or incoming provider events as a completed manifest; cancel or retry deliberately if needed.
The proposal chooses the wrong machine: Reject it and correct the target. Do not fix a 48K/128K mismatch by merely renaming the project.

READY TO MOVE ON?

Check the result, not just the response.

The brief has explicit target, rules and exclusions.
A small program builds and reaches a playable screen.
You have checked success, failure, invalid input and replay.