velven

Give your AI game idea a brief it can actually build

“Make me a cozy space adventure” leaves an assistant with a lot of decisions to make. It might build a lovely title screen while you're imagining a repair drone hopping between planets. I'd spend ten minutes making those decisions explicit. A short brief saves you from discovering, several prompts later, that you and the assistant were building different games.

A brief you can build: Player action → One obstacle → Win condition → Out of scope. Define the boundaries before asking for code.
Define the boundaries before asking for code.

Begin with what the player does

Try this: “You steer a drone between three stations and deliver a battery before its charge runs out.” Now there's an action, a destination and a little pressure. The cozy atmosphere can arrive through sound, color and pace once the interaction works.

Write the controls in ordinary language. Arrow keys move. Space delivers. R restarts. Then describe success and failure. If you can't explain how a round ends, keep the project smaller until you can. You need enough of a game to test, not a complete fictional universe.

Put the awkward details in the brief

The little rules are where surprises hide. Can you deliver the same battery twice? Does time run while the pause menu is open? Does a restart bring back every station? I would answer those questions before adding another planet.

Add the engine version and the command that runs your existing project. If you have code already, supply the relevant files. “Use my current project” is hard to follow when the assistant has never seen it.

Game: a repair drone delivers batteries to three stations.
Target: desktop browser, one screen.
Controls: arrows to move, Space to deliver.
Win: all three stations receive a battery.
Lose: the charge timer reaches zero.
Restart: restore the drone, timer and all stations.
First milestone: movement and one delivery.
Check: holding Space must not deliver repeatedly.

Make the first request smaller than the brief

A brief describes the destination. Your next prompt describes one step. Ask for movement, test it, then ask for delivery. That gives you an obvious place to look when a change goes wrong.

Keep the brief in the project as a text file. When you change a rule, edit that file instead of burying the correction halfway through a chat. I'd also keep a tiny “later” list for tempting features: a shop, a second vehicle, a bigger map. Writing them down lets you return to the current task without feeling as though you've abandoned every good idea.

After the first playtest, revise the brief around what you learned. Perhaps the timer makes the game stressful and the interesting part is choosing an efficient route. That's a useful change of direction. Make it deliberately, then tell the assistant which old rule it replaces.

Sources & further reading

Made something playable?

Share your game, world or experiment with people exploring what AI can help create.

Add your space to Velven